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?

[carllerche]

@phaazon rarely with regards to the service trait. This was not a general statement for when you would want trait aliasing.

Also, the syntax was not meant to be a real proposal. It was only to illustrate what I was talking about.

[hadronized]

I see. Cannot we just use free variables for that? Like, Service<Request = http::Request> implies the free variable used in http::request<_>?

[carllerche]

@phaazon I don't understand this proposal.

[varkor]

@durka: how's the work on the follow-up to #45047 going?

[clarfonthey]

Something I mentioned in the RFC: trait Trait =; is accepted by the proposed grammar and I think that this is a bit weird. Perhaps maybe the proposed _ syntax might be more apt here, because I think that allowing empty trait requirements is useful.

[durka]

We can put a check for that in AST validation. However I suppose it could be useful for code generation if there's no special case, I dunno.

…

On Tue, Feb 27, 2018 at 12:48 PM, Clar Roʒe ***@***.***> wrote: Something I mentioned in the RFC: trait Trait =; is accepted by the proposed grammar and I think that this is a bit weird. Perhaps maybe the proposed _ syntax might be more apt here, because I think that allowing empty trait requirements is useful. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41517 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n3HdG3ZOmbN2PKky7nFnx0WokY7Lks5tZD_fgaJpZM4NGzYc> .

[clarfonthey]

One other thing to note as a general weirdness is macro expansions involving trait bounds. Currently, fn thing<T:>() is valid syntax but perhaps fn thing<T: _>() should be the recommended version.

But then, is _ + Copy or something okay? I'm not sure. I would just suggest Any but that has different guarantees.

[petrochenkov]

Empty bound lists (and other lists) are accepted in other contexts as well, e.g. fn f<T: /*nothing*/>() { ... }, so trait Trait = /*nothing*/; being accepted is more of a rule than an exception.

[clarfonthey]

I think it makes sense being accepted, although I wonder if making it the canonical way to do so outside of macros is the right way to go. We already have been pushing toward '_ for elided lifetimes in generics, for example.

[matzipan]

Trying this unstable feature in 1.66.0 nightly.

For this type:

trait FactoryFunctionType = Fn(u32, &glib::Object) -> gtk::Widget;

It can't seem to be able to infer the type of ::Output type for this function type. It resolves to <dyn FactoryFunctionType as FnOnce<(u32, &Object)>>::Output which seems to be missing the -> gtk::Widget return type.

[Kixunil]

I found it'd be useful to allow impls of certain trait aliases. Consider this code:

Crate A:

pub trait Encode<Strategy> {
    type Encoder: Encoder;

    fn encode(&self) -> Self::Encoder;
}

Crate B:

// Whole crate uses this strategy, so it's repeated everywhere.
pub enum ThisCrateStrategy {}

// To implement the trait in different modules of the crate each must import both `Encode` and `ThisCrateStrategy`.
impl Encode<ThisCrateStrategy> for u32 {
    type Encoder = U32Encoder;

    fn encode(&self) -> Self::Encoder {
        U32Encoder::new(*self)
    }
}

Instead it should be possible to allow this:

pub enum ThisCrateStrategy {}

pub trait ThisCrateEncode = Encode<ThisCrateStrategy>;

impl ThisCrateEncode for u32 {
    type Encoder = U32Encoder;

    fn encode(&self) -> Self::Encoder {
        U32Encoder::new(*self)
    }
}

[Jules-Bertholet]

I found it'd be useful to allow impls of certain trait aliases.

I have an open RFC for this: rust-lang/rfcs#3437

[ms-ati]

Q: Does trait aliases have any projected timeframe to reach stable?

[nikomatsakis]

Not at present but at least some subset of them would be useful for async code, so I'm hoping to get that done this year.

[ilonachan]

Just to make sure you know (bc I don't actually know GitHub very well) I found a (likely) bug and opened #127725 for it.