rust-lang
Supertrait Auto-impl
We would like to propose auto impl syntax 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.
24/09/2025: revision published with typo fixes and dropping the unsafe qualifier for probe_extern_impl attribute.
Past edit history
21/09/2025: revision published with the following changes. - Address [comments from @cramertj](https://github.com/rust-lang/rfcs/pull/3851#discussion_r2301552062) by including the worked examples mentioned in the [design meeting](https://hackmd.io/@1n2nRkvSTd-QgK8cCPds1w/HkBmeCE7xx). A new proposal is included so that an unsafe attribute may be used to allow compiler to probe further and decide if `auto impl` default implementation would be conflicting. This might need consultation with the types team as its effectiveness and stability depends very much on the capabilities of the trait solver. - Address [comments from @ElchananHaas](https://github.com/rust-lang/rfcs/pull/3851#discussion_r2306004253) and [comments from @N4tus](https://github.com/rust-lang/rfcs/pull/3851#issuecomment-3239334843) on several deficiencies in the worked examples, such as missing superbounds and complexity in the motivating examples. - Address [a comment from @programmerjake](https://github.com/rust-lang/rfcs/pull/3851#discussion_r2302020617) by removing the template text.
The explanation states that the traits need to have a super/sub trait relation. But some examples use traits e.g. MouseEventHandler and Double, that are not in a relation to the trait they provide an auto impl for.
@dingxiangfei2009 Please don't force-push in this repo, that's heavily discouraged. From the README.md:
Specifically, do not squash or rebase commits after they are visible on the pull request.
Quick question for @fmease, should I rename the RFC file from serial 0000-... to 3851-... in this text by ourselves? Or will there be a bot to rename the file?
@dingxiangfei2009 the name won't get updated automatically. We've merged the 2025H2 RFC, forgot to update and had to open a separate PR to fix the name: https://github.com/rust-lang/rfcs/pull/3860.
This is a very interesting proposal!
As maintainer of cargo-semver-checks, I'm thinking about the SemVer implications here. Due to the significant number of edge cases (associated types, associated functions, auto impl, extern impl, etc.), I'm quite sure I would fail if I attempted to enumerate all the possible SemVer hazards myself. At the same time, I think it's very important that SemVer hazards be considered explicitly — especially for a complex language feature like this.
Would you mind adding a ## SemVer hazards section to the doc and enumerating all the new ways to cause a major breaking change introduced here?
@obi1kenobi Yes, I remember that. I will tag you in the "changelog" when I add the SemVer hazard section for your reviews.
November update
- I added a rule to clarify that nesting
auto impls could happen and how the nesting would work. - I added a section on SemVer and explored the consequence from possible edits to traits using this feature. cc @obi1kenobi
- I clarified the name resolution ambiguity when the name can be resolved to two supertrait items.
Update:
- I forgot to mention that we would like to support higher-kinded superbounds, too. The text is now updated with the extension. Extensions in the text would be rolled out gradually as the feature is developed.