RFC: Implementable trait aliases

[Jules-Bertholet]

Rendered

Allow writing impl blocks for most trait aliases. Also, allow trait aliases to have bodies.

Prior discussion on Internals

@rustbot label A-traits

[programmerjake]

one benefit of requiring #[implementable] is that it mitigates the confusing aspect of:

#[implementable] // error: must only have one trait on rhs of equal -- generated because of #[implementable]
pub trait Foo = Bar + Baz;
// vs.
#[implementable]
pub trait Foo = Bar
where
    Self: Baz;

[Jules-Bertholet]

I've added some more discussion about this.

[burdges]

As an aside, it'd be nice if type aliases permitted instantiation:

pub struct FooT<T>([T; 32]);
pub type Bar = Foo<u8>;

impl Default for Bar {
    fn default() -> Bar {
        Bar( Default::default() )   // Forbidden right now.
    }
} 

[programmerjake]

As an aside, it'd be nice if type aliases permitted instantiation:

they do, if you use curly braces (except for tuples):
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b95fe39281037ac567cfc8dfa7aba44b

i think it'd also be nice to allow curly brace syntax for tuples for ease of writing proc macros so there's one consistent syntax that works on all struct-like types:

type T<A, B> = (A, B);
let v = T::<_, _> { 0: "abc", 1: 123 };
match v {
    T::<_, _> { 0: a, 1: b } => println!("it works! a={a} b={b}"),
}

[dlight]

they do, if you use curly braces (except for tuples):
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b95fe39281037ac567cfc8dfa7aba44b

Wait, so T { 0: 5 } works but T(5) doesn't? This sounds like a bug.

[Jules-Bertholet]

Wait, so T { 0: 5 } works but T(5) doesn't? This sounds like a bug.

Changing this behavior would be a breaking change, for code like the following:

struct Foo();
type Bar = Foo;
fn Bar() {}

Anyway, this is all a bit off-topic for the RFC 😁

[nielsle]

I think that the RFC should mention #1672 and mutually exclusive traits

rust-lang/rust#20400
https://geo-ant.github.io/blog/2021/mutually-exclusive-traits-rust/
https://stackoverflow.com/questions/57749827/mutually-exclusive-traits

Is this RFC an alternative to #1672 or is it orthogonal?

[Jules-Bertholet]

@nielsle I don't see any relationship between this RFC and that issue.

[tmandry]

I think the summary motivation section should be fleshed out more, ideally with real-world examples (possibly simplified). After looking through the text this does seem useful but it wasn't obvious at all to me what the feature was from those sections.

[Jules-Bertholet]

I've specified that implementable trait aliases also support fully-qualified method call syntax.

[nikomatsakis]

@rustbot +I-lang-nominates +I-types-nominated

I'm nominating this for @rust-lang/lang and @rust-lang/types discussion. I myself am in favor of this RFC. I've seen a lot of demand for a simplified version of trait aliases where--

(A) We only support trait Foo = Bar + Baz format, essentially.
(B) The trait Foo is implementable and, in general, acts like a "normal trait" so that users don't have to know about the more detailed version.

I expect this to be relevant to async fn in traits as well (cc @tmandry) it's quite common to have something like trait Service (which requires Send) and trait LocalService (which does not).

Restricting to point (A) has the advantage of avoiding some complex corner cases. Note though that I do want to support the "inline bound" syntax, so that you could do trait SendIterator = Iterator<Item: Send> (as well as RTN if we adopt that), so that trait aliases can put bounds on associated types.

[nikomatsakis]

I guess that my question to the lang/types teams, respectively, are:

1. Lang: what do people think about the motivation here as well as the more limited proposal? Are there important trait alias use cases not covered there?
2. Types: are there concerns about the limited proposal that I put forward?

[nikomatsakis]

One though -- @Jules-Bertholet -- I'm not sure if the RFC covers it, I didn't have time to read in super detail, but I think that if you are implementing trait Foo = Bar + Baz, that implies "unioning" the methods from Bar and Baz into one impl block. Does the RFC discuss this?

I have, for a long time, wanted the ability to implement a trait and its supertraits together in a single impl block, I wonder if it's worth thinking about that as well, though I'd probably want to separate it out from this RFC.

[Jules-Bertholet]

One though -- @Jules-Bertholet -- I'm not sure if the RFC covers it, I didn't have time to read in super detail, but I think that if you are implementing trait Foo = Bar + Baz, that implies "unioning" the methods from Bar and Baz into one impl block. Does the RFC discuss this?

The RFC does not do any sort of trait unioning like this, I hadn't even considered it as a possibility (I will add it to the alternatives section). Notably, you would need to handle name collisions.

[Jules-Bertholet]

I've added text to the alternatives section addressing @nikomatsakis's "unioning" idea.

[nikomatsakis]

@Jules-Bertholet

Notably, you would need to handle name collisions.

Yes. Presumably that would be an error.

[Jules-Bertholet]

Presumably that would be an error.

That would have backward-compatibility implications, if one of the traits adds a defaulted method that conflicts. Technically "minor" breakage, but still not ideal.

[Jules-Bertholet]

It seems that the lang team wants this RFC to be more broad, so I have gone ahead and done that. You can now implement trait aliases that combine multiple traits. In addition, you can specify bodies for trait aliases, that define additional names for different trait items.

[traviscross]

Thanks @Jules-Bertholet for that. I've proposed a design meeting for us to review this.

• Design meeting: Implementable trait aliases lang-team#322

It's worth mentioning that we're also talking about allowing impls that cover both a subtrait and supertrait, as described here:

• Arbitrary self types v2: stabilize rust#135881 (comment)

Maybe or maybe not that could have some relevance here. It seems at least spiritually related.

[Jules-Bertholet]

It's worth mentioning that we're also talking about allowing impls that cover both a subtrait and supertrait, as described here:

• Arbitrary self types v2: stabilize rust#135881 (comment)

I don't think I agree with doing it in exactly that way, but that is definitely relevant, and I will update the RFC with that example and how my proposal would handle it.

[programmerjake]

It's worth mentioning that we're also talking about allowing impls that cover both a subtrait and supertrait, as described here:

• Arbitrary self types v2: stabilize rust#135881 (comment)

I think that could be achieved with a trait alias (assuming dyn TraitAlias works when the trait alias is NonAutoTrait1 + NonAutoTrait2 -- because the alias is a named item, it can be treated as a normal trait when rustc is figuring out what vtable to generate):

pub trait Receiver {
    type Target: ?Sized;
}

// what Deref resolves to in edition >= 2027
pub trait e2027#Deref: Receiver {
    fn deref(&self) -> &Self::Target;
}

// what Deref resolves to in edition <= 2024
pub trait e2024#Deref = Receiver + e2027#Deref {
    type Target: ?Sized = <Self as Receiver>::Target;
    fn deref = <Self as e2027#Deref>::deref;
}

[Jules-Bertholet]

(assuming dyn TraitAlias works when the trait alias is NonAutoTrait1 + NonAutoTrait2 -- because the alias is a named item, it can be treated as a normal trait when rustc is figuring out what vtable to generate)

I’ve added a section on this. TLDR: no, it does not work in general, but if one of the non-auto traits is a subtrait of all the others then it does (dyn TraitAlias is then just a synonym of dyn Subtrait).

[Jules-Bertholet]

I’ve added a small note to the future possibilities, connecting this to const traits. I will try to discuss target features as well, but need some time to think about that first.

[Jules-Bertholet]

I’ve now realized that this feature is actually sufficient to address the “make LendingIterator a supertrait of Iterator” issue on its own. I’ve moved that out of the future possibilities and into the main body of the RFC.

[traviscross]

I’ve now realized that this feature is actually sufficient to address the “make LendingIterator a supertrait of Iterator” issue on its own. I’ve moved that out of the future possibilities and into the main body of the RFC.

cc @compiler-errors

[Jules-Bertholet]

I will try to discuss target features as well, but need some time to think about that first.

This has now been added to the future possibilities.

[Jules-Bertholet]

I’ve removed the implementability restrictions on type and const alias items. They just added pointless complexity.