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.

[phaazon]

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.

[phaazon]

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.

[Kixunil]

Yes please, make trait aliases also bound aliases. It'd be very practical.

[benjaminmordaunt]

Perhaps I'm misunderstanding this. I want trait aliases to allow something like this, to allow giving more meaningful names to specialised traits:

pub trait Mapper<Tr, Tw> {
    fn read(&self, addr: u16) -> Tr;
    fn write(&mut self, addr: u16, data: u8) -> Result<Tw, String>;
}

pub trait CPUMapper = Mapper<u8, ()>;
pub trait PPUMapper = Mapper<u16, u16>;

impl CPUMapper for CPUMapper000 { /* should == impl Mapper<u8, ()> for CPUMapper000 {
    /* NOT ALLOWED! */
}

But rustc complains that it's looking for a trait, but finding a trait alias... isn't that the point?
I understand this might become an issue when traits are composed together, and you try to impl a set of traits at once. But can't there be a check to see if we're aliasing only a single trait, to allow its use in an impl Trait for T block?

[varkor]

@benjaminmordaunt: this is one of the issues with the current design of the language feature. "Trait aliases" are not really trait aliases: they are bounds aliases (#41517 (comment)). I feel this is strongly misleading (as evidenced by your comment).

[clarfonthey]

Here's a silly idea that (kind of) abuses the impl Trait syntax:

impl Alias = impl One + Two;

This would be a bounds alias, and it essentially clarifies that using impl Alias is the same as using impl One + Two, but doesn't make any specific guarantees about it being a trait in its own right.

For creating proper trait aliases, we could do something like:

impl trait Alias = impl One + Two;

This would essentially say: implement the trait Alias for everything that implements One + Two.

[reuvenpo]

@clarfonthey You can do the latter in stable rust with something like this:

pub trait Alias: One + Two {}

impl<T> Alias for T where T: One + Two {}

It's a little awkward to write because it has a bit of duplication, but it's been working well for me in cases where i needed to alias a bound of the sum of ~10 traits together.

[freemanliu]

@reuvenpo,
Not sure if this trick works with Fn, which is implmented by closure. For an alias below:
pub trait MyF: Fn(i32) -> i32

how to implement it for a closure? Like
fn createMyF() -> MyF {
|i| -> 2*i
}

UPDATE:
switched to nightly rust and trait alias works!

[reuvenpo]

@freemanliu This works in stable:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a41bef6b7ea84bad47461e3834ae7bcc

[clarfonthey]

@clarfonthey You can do the latter in stable rust with something like this:

pub trait Alias: One + Two {}

impl<T> Alias for T where T: One + Two {}

It's a little awkward to write because it has a bit of duplication, but it's been working well for me in cases where i needed to alias a bound of the sum of ~10 traits together.

You are correct, but the suggestion would be to simply make it sugar for that, if such a feature were desired. Right now, the main intent of trait aliases is to act as bounds aliases, but for those who want proper trait aliases, this could be an alternative syntax.

[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)
    }
}