Supertrait Auto-impl

[dingxiangfei2009]

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//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//pull/3851#discussion_r2306004253) and [comments from @N4tus](https://github.com//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//pull/3851#discussion_r2302020617) by removing the template text.

Rendered

[cramertj]

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.

[dingxiangfei2009]

I have updated the document to address this.

We can explore the possibility of introducing relaxation so that for some cases the compiler can check further if auto impl may overlap and bail out by assuming an implicit extern impl statement.

[dingxiangfei2009]

I am also adding the worked example on how the motivating examples from the lang design meeting would work under this RFC in the motivation section.

[programmerjake]

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.

[dingxiangfei2009]

Understood. This was from the template text. It should have been dropped.

[N4tus]

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.

[programmerjake]

what operation is this performing that could produce UB therefore requiring unsafe? if there is none, unsafe should not be used.

[dingxiangfei2009]

Okay, I will drop the unsafe qualifier.

[fmease]

@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.

[dingxiangfei2009]

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?

[tomassedovic]

@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: #3860.

[programmerjake]

you still have unsafe here

[programmerjake]

and here

[programmerjake]

Suggested change

	## Mandatory `external impl` declaration
	## Mandatory `extern impl` declaration

[programmerjake]

so, does this create an unsafe requirement or discharge an existing unsafe requirement? you seem to have it do both which is generally not how Rust uses unsafe anymore, now that we have unsafe_op_in_unsafe_fn enabled by default

[dingxiangfei2009]

I see that this can be confusing.

• Inside a trait Subtrait: .. { .. } block, unsafe auto impl creates an unsafe requirement.
• Inside a impl Subtrait { .. } block, unsafe auto impl discharges the corresponding unsafe requirement.

Should we adjust the "keyword" orders, so that the distinction can be more obvious?

[programmerjake]

that seems less useful than what I would have expected needing unsafe for -- something like:

/// safety: `returns_even` must always return an even integer
// unsafe means we create a requirement that impls must fulfill
pub unsafe Supertrait {
    fn returns_even(&self) -> u8;
}

pub trait Subtrait: Supertrait {
    /// safety: returns_even always returns an even integer
    // unsafe here means we're fulfilling the requirement since this is an impl of Supertrait
    unsafe auto impl Supertrait {
        fn returns_even(&self) -> u8 {
            self.get_int().wrapping_mul(2)
        }
    };
    fn get_int(&self) -> u8;
}

impl Subtrait for u8 {
    fn get_int(&self) -> u8 {
        *self
    }
}

pub struct Even(u8);

impl Subtrait for Even {
    // no unsafe needed here because this isn't fulfilling or creating any safety requirements,
    // the unsafe impl Supertrait below does that,
    // all we're doing here is saying this impl doesn't also impl Supertrait
    extern impl Supertrait;
    fn get_int(&self) -> u8 {
        self.0 / 2
    }
}

// safety: returns_even always returns an even integer because Even contains an even integer
// unsafe here means we're fulfilling the requirement since this is an impl of Supertrait
unsafe impl Supertrait for Even {
    fn returns_even(&self) -> u8 {
        self.0
    }
}