View all comments

This is a tracking issue for the feature trait aliases (originally specified in RFC 1733).
The feature gate for the issue is #![feature(trait_alias)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the feature (MVP)
• Bringing a trait alias into scope doesn't allow calling methods from its component traits #56485 — Bringing a trait alias into scope doesn't allow calling methods from its component traits (done in resolve: collect trait aliases along with traits #59166)
• ICE with trait aliases and use items #56488 — ICE with trait aliases and use items
• Nightly Type Alias Compiler panic unexpected definition: TraitAlias #57023 — Nightly Type Alias Compiler panic unexpected definition: TraitAlias
• INCOHERENT_AUTO_TRAIT_OBJECTS future-compatibility warning #57059 — INCOHERENT_AUTO_TRAIT_OBJECTS future-compatibility warning (superseded by add coherence future-compat warnings for marker-only trait objects #56481)
• Document
• Stabilize

Unresolved questions

• Should we really imply bounds on generic parameters other than the self type Self? Or rather, should we really imply bounds whose self type isn't Self or a projection thereof?
  • Right now, we imply all bounds without any restrictions; that means for example that A: TraitAlias<B> (where trait TraitAlias<T: Bound> = Bound where X: From<Self>, Y: From<T>;) doesn't just imply A: Bound and X: From<A> but also B: Bound and Y: From<B>.
  • See also: Trait aliases: Also imply default trait bounds on type params other than Self #152688 (comment)
  • Historical note: The question used to read "Are bounds on other input types than the receiver enforced or implied?"
• Should we keep the current behaviour of "shallow-banning" ?Sized bounds in trait objects, ban them "deeply" (through trait alias expansion), or permit them everywhere with no effect?
  • NOTE(fmease): The phrasing of that question is imprecise & confusing.
    1. First of all, ?Sized bounds in trait alias bounds makes no sense whatsoever since we don't perform Sized elaboration there (i.e., we don't implicitly add a Sized bound to trait aliases). For that reason PR RUST-147734 made them a hard error.
    2. Second of all, regarding "deep v shallow": Relaxed bounds like ?Sized don't get "inherited"; Sized elaboration happens in the relevant places without regard for any supertrait bounds
    3. Last of all, I wonder if that question actually meant to say "Should dyn EmptyTraitAlias be legal where trait EmptyTraitAlias =;?" In the current implementation, trait aliases get eagerly expanded inside trait object types and thus dyn EmptyTraitAlias ends up getting rejected just like dyn (sic!). I guess it could behave like trait EmptyTrait {} instead and thus get accepted. It's unclear if that's how one should interpret that question but it doesn't seem implausible.
• Insufficient flexibility
• Inconvenient syntax
• Misleading naming
• Which of constraint/bound/type aliases are desirable

Implementation history

See #55628 instead.