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

• #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.

PR history

• #45047 by @durka
• #55101 by @alexreg

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.