Tracking issue for `trait alias` implementation (RFC 1733)

[nikomatsakis]

This is the tracking issue for implementing (not discussing the design) RFC rust-lang/rfcs#1733. It is a subissue of #41517.

Current status

Once #55101 lands, many aspects of trait aliases will be implemented. However, some known limitations remain. These are mostly pre-existing limitations of the trait checker that we intend to lift more generally (see each case below for notes).

Well-formedness requirements. We currently require the trait alias to be well-formed. So, for example, trait Foo<T: Send> { } trait Bar<T> = Foo<T> is an error. We intend to modify this behavior as part of implementing the implied bounds RFC (#44491).

Trait object associated types. If you have trait Foo = Iterator<Item =u32>, you cannot use the trait object type dyn Foo. This is a duplicate of #24010.

Trait object equality. If you have trait Foo { } and trait Bar = Foo, we do not currently consider dyn Foo and dyn Bar to be the same type. Tracking issue #55629.

Pending issues to resolve

• Compiler panic with trait aliases #56006 - ICE when used in a library crate

Deviations and/or clarifications from the RFC

This section is for us to collect notes on deviations from the RFC text, or clarifications to unresolved questions.

Implementation history

FIXME: This is most likely incomplete.

• trait alias infrastructure #45047
• Implement trait aliases (RFC 1733) #55101
• make trait-aliases work across crates #57502
• Add trait alias support in rustdoc #58243
• Disallow auto trait alias syntax #58387
• rustc: fix ICE when trait alias has bare Self #59118
• resolve: collect trait aliases along with traits #59166
• Ban multi-trait objects via trait aliases #59445
• Do not ICE on trait aliases with missing obligations #66392
• Fix trait alias inherent impl resolution #72556
• Add a suggestion when using a type alias instead of trait alias #83729
• Lint against non-CamelCase trait alias names #85732
• Generalize trait object generic param check to aliases. #100247
• Do not bring trait alias supertraits into scope #107803
• Do not ICE on unmet trait alias bounds #108115
• Don't require specifying unrelated assoc types when trait alias is in dyn type #122123
• Don't record trait aliases as marker traits #128174
• Rework dyn trait lowering to stop being so intertwined with trait alias expansion #133830
• Use trait definition cycle detection for trait alias definitions, too #134504
• rustdoc: Support inlined cross-crate re-exported trait aliases #139943
• Constify trait aliases #144291
• Further tighten up relaxed bounds #147734
• Fix bound var resolution for trait aliases #152309
• Trait aliases: Also imply default trait bounds on type params other than Self #152688

Other links

• Test scenarios drawn up by @nikomatsakis from the RFC: gist

[alexreg]

Good summary. Thanks for writing this up.

[eddyb]

Have we considered blocking stabilization on lazy normalization?
That is, I'm worried that these are equivalent problems:

trait Foo<X> {}

type Bar<X: ExtraBound> = dyn Foo<X>;
fn bad<X>(_: &Bar<X>) {}

trait Foo2<X: ExtraBound> = Foo<X>;
fn bad2<X>(_: &dyn Foo2<X>) {}

The alternative, to consider Foo2 its own trait, has its own issues, IMO.

[alexreg]

@eddyb Actually, they're not, under the current implementation, which is nice. The X: ExtraBound bound is enforced. Example.

[alexreg]

@nikomatsakis I just realised you never got around to factoring out the part of my old PR #55994 that banned multi-trait objects via trait aliases... did you still want to tackle that?