Tracking issue for trait aliases

[withoutboats]

This is a tracking issue for trait aliases (rust-lang/rfcs#1733).

TODO:

• Implement: tracking issue
• 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:

• 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?
• Insufficient flexibility
• Inconvenient syntax
• Misleading naming
• Which of constraint/bound/type aliases are desirable

[durka]

I think #24010 (allowing aliases to set associated types) should be mentioned here.

[durka]

I'd like to take a crack at this (starting with parsing).

[carllerche]

I read the RFC and I saw a call out to Service, but I am not sure if the RFC actually solves the Service problem.

Specifically, the "alias" needs to provide some additional associated types:

See this snippet: https://gist.github.com/carllerche/76605b9f7c724a61a11224a36d29e023

Basically, you rarely want to just alias HttpService to Service<Request = http::Request> You really want to do something like this (while making up syntax):

trait HttpService = Service<http::Request<Self::RequestBody>> {
    type RequestBody;
}

In other words, the trait alias introduces a new associated type.

The reason why you can't do: trait HttpService<B> = Service<http::Request<B>> is that then you end up getting into the "the type parameter B is not constrained by the impl trait, self type, or predicates" problem.

[hadronized]

Basically, you rarely want to just alias HttpService to Service<Request = http::Request>

Rarely? How do you define that?

The syntax you suggest seems a bit complex to me and non-intuitive. I don’t get why we couldn’t make an exception in the way the “problem” shows up. Cannot we just hack around that rule you expressed? It’s not a “real trait”, it should be possible… right?