Supertrait Auto-impl #3851
Supertrait Auto-impl #3851
Conversation
Signed-off-by: Xiangfei Ding <dingxiangfei2009@protonmail.ch>
ehuss
added
T-lang
|
|
||
| Impl blocks using auto implementations are simply a short-hand for multiple impl blocks with all of the consequences that implies. | ||
|
|
||
| When a trait has an `auto impl` entry, all impl blocks for the trait that do not use `extern impl` to opt-out of the auto implementation become equivalent to two impl blocks, one for the sub-trait and one for the super-trait. They are generated according to these rules: |
There was a problem hiding this comment.
When a trait has an auto impl entry, all impl blocks for the trait that do not use extern impl to opt-out of the auto implementation become equivalent to two impl blocks, one for the sub-trait and one for the super-trait.
AFAICT, this rule makes it backwards-incompatible to add auto impls for existing traits with existing supertraits, correct? That is, we would not be able to add an auto impl PartialOrd { ... } in Ord without breaking existing users, as existing impls would have to have specified extern impl PartialOrd;. I think it would be helpful for the RFC to step through some of the example use-cases (the ones discussed in the lang design meeting) and describe how they would look under this RFC.
| # Unresolved questions | ||
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| - What parts of the design do you expect to resolve through the RFC process before this gets merged? |
There was a problem hiding this comment.
the idea is for you as the RFC writer to answer these questions by writing your own list of questions instead of these, if you have none then you can just write "None so far." or something.
traviscross
added
the
I-lang-radar
| } | ||
| } | ||
| ``` | ||
| And then `MyStruct` automatically implements `Serialize` by creating a `MyStructProxy` instance and serializing the proxy. So for example `MyStruct { name: "a", int: 42 }` is serialized into json as `{"name":"a","tens":4,"digit":2}`. |
There was a problem hiding this comment.
This example is incomplete. How does MyStruct automatically implement Serialize?
| type Type1; | ||
| type Type2; | ||
| } | ||
| trait Subtrait: Supertrait1 + Supertrait2 { |
There was a problem hiding this comment.
This is already a bit complex, perhaps it would be better to start with an example with a single supertrait?
|
|
||
| For some traits, it's difficult to implement the trait directly because the "raw" interface that the trait exposes is complex. If the trait is unsafe, this may be even worse as the end-user may not wish to write any unsafe code. This feature makes it easy to provide utilities for more easily implementing the trait. | ||
|
|
||
| ### Example: Serde |
There was a problem hiding this comment.
It would be better to use an example of an existing trait and trait evolution since that is the primary purpose of Supertrait auto impl.
|
The explanation states that the traits need to have a super/sub trait relation. But some examples use traits e.g. |
We would like to propose
auto implsyntax for supertraits for a few language enhancement, to ultimately facilitate easier trait evolution and refactoring and easier trait authoring when trait hierarchy is in consideration.Rendered