Evolving trait hierarchies

[nikomatsakis]

Metadata
Point of contact	@cramertj
Team(s)	compiler, lang, libs-api, types
Goal document	2025h2/evolving-traits

Summary

Unblock the evolution of key trait hierarchies:

• Adding Receiver
  as a supertrait of Deref.
• Allow the tower::Service trait to be split into a non-Sync supertrait and a
  Sync (thread-safe) subtrait.

The design should incorporate the feedback from the
Evolving trait hierarchies
language design meeting. The design should also set the stage for future changes to allow for
the more general case of splitting items out into supertraits.

Tasks and status

• Discussion and moral support (lang )
• Discussion and moral support (compiler )
• Discussion and moral support (types )
• Author RFC (@dingxiangfei2009 with help from @cramertj)
• Implementation (@cramertj)
• Stabilization decision (libs-api )
• Stabilization decision (lang )

[nikomatsakis]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[cramertj]

Current status: there is an RFC for auto impl supertraits that has received some discussion and updates (thank you, @dingxiangfei2009!).

The major open questions currently are:

Syntax

The current RFC proposes:

trait Subtrait: Supertrait {
    auto impl Supertrait {
        // Supertrait items defined in terms of Subtrait items, if any
    }
}

Additionally, there is an open question around the syntax of auto impl for unsafe supertraits. The current proposal is to require unsafe auto impl Supertrait.

Whether to require impls to opt-out of auto impls

The current RFC proposes that

impl Supertrait for MyType {}

impl Subtrait for MyType {
    // Required in order to manually write `Supertrait` for MyType.
    extern impl Supertrait;
}

This makes it explicit via opt-out whether an auto impl is being applied. However, this is in conflict with the goal of allowing auto impls to be added to existing trait hierarchies. The RFC proposes to resolve this via a temporary attribute which triggers a warning. See my comment here.

Note that properly resolving whether or not to apply an auto impl requires coherence-like analysis.