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]

I've rewritten the AFIT example in the motivation section in terms of the trait-variant crate.

[Jules-Bertholet]

There's one issue I hadn't noticed before that limits the applicability of this feature to a degree. Currently, if you have:

pub trait Foo { /* ... */ }
pub trait SendFoo: Foo + Send {}
impl<T: Foo + Send + ?Sized> SendFoo for Foo {}

Then, dyn Foo + Send and dyn SendFoo are distinct types. Migrating to:

pub trait Foo { /* ... */ }
pub trait SendFoo = Foo where Self: Send;

Makes these into the same type, which is a breaking change (trait impls could start overlapping). This isn't a problem for the async Send variant use-case, as traits with async methods aren't (yet) object safe, but it could potentially make migrating from blanket impls to implementable trait aliases a breaking change in some other cases.

[traviscross]

@rustbot labels +I-lang-nominated

We discussed this in the lang planning meeting today, and it looks like there have been updates since we last looked at this, so let's renominate so we can discuss.

[willmtemple]

@Jules-Bertholet I have another use case that I haven't seen mentioned here: I want to be able to hide a trait behind a module using a proc macro. I want to do this to create a sort of RTTI system for tracking which types implement traits dynamically (along with constructing other forms of metadata about the implementation). This is all in service of building a scripting language on top of Rust.

Here's a really simplified example:

#[runtime_trait]
pub trait Foo {
  fn bar(&self) -> i32;
}

would be rewritten to

#[doc(hidden)]
trait __Foo {
  fn bar(&self) -> i32;
}

pub mod Foo {
  pub trait Foo = super::__Foo;
  
  #[::linkme::distributed_slice]
  pub static IMPLEMENTORS: [TypeId];
}

And the impl:

#[runtime_trait_impl]
impl Foo for T {
  fn bar(&self) -> i32 { 3 }
}

would be rewritten to:

// Relies on being able to impl __Foo through the trait alias inside the module.
impl Foo::Foo for T {
  fn bar(&self) -> i32 { 3 }
}

#[::linkme::distributed_slice(Foo::IMPLEMENTORS)]
static __FOO_T: TypeId = TypeId::of<T>();

• The trait itself cannot be declared inside the Foo module, since the module does not inherit scope from the outer module, and that will break the written definition of the trait's constraints and items.
• If I give the module a different name from the trait, the user has to import an "invisible" module generated by the proc macro anywhere they want to use #[protocol_impl], and that would suck.
• I've removed a lot of complexity around handling generic traits, but the general idea could hold for generic traits as well.

TL;DR I think this would be really useful for syntactic manipulations with proc macros and would give macro authors more flexibility in rewriting traits.

[Kixunil]

I have a real-world example as well. My push_decode crate provides an abstraction over both sync/async and std/no_std encoding. This is achieved simply by requiring the implementors to provide an encoder - a state machine that implements the encoding. I'd love to also provide traits that take care of encodable objects. However there are various strategies used to encode things. e.g. u32 can be encoded as littel endian, big endian, varint... So what I want is this:

// Analogous to serde::Serialize
pub trait Encode<Strategy> {
    type Encoder: Encoder;
    // additional things like const MIN_SERIALIZED_LEN: usize
    fn encode(&self) -> Self::Encoder;
    // various helper methods taking advantage of the additional items. E.g. fn encode_to_vec(&self) which reserves MIN_SERIALIZED_LEN
}

Then each protocol can define enum ProtocolName {} and impl Encode<ProtocolName>. However crates with many encodable types will have to write Encode<ProtocolName> everywhere and import ProtocolName. This is annoying and it'd be much nicer to define an alias trait Encode = push_bytes::Encode<ProtocolName> and then just use Encode everywhere.

[traviscross]

@Kixunil: Thanks for the report of the real-world example. That pattern is called "tagged impls". It provides one way to work around the current orphan rules. E.g.:

Playground link

Implementable trait aliases do indeed make this pattern more convenient.

[tmandry]

I'm in favor of this, because while the symmetry with impl blocks is nice I think the symmetry with bounds is ultimately more important (and more confusing to break). If other lang team members agree I think we should go ahead and support it on day 1.

Otherwise, given that this is something we can allow in the future, can it be listed as a future possibility?

[nikomatsakis]

We discussed this RFC in our triage meeting today.

The meeting consensus was that we'd ideally like to have an RFC that lays out a forward looking plan that goes a bit further than the specifics in this RFC:

• It should be possible to implement a trait and its supertraits together
• trait Alias<T..> = Bound.. where WC... should be equivalent to the pair of
  • trait Alias<T..>: Bound.. where WC... {}
  • impl<Self: Bound.., T..> Alias<T..> for Self where WC...
  • If there are no where clauses, this is true today:
    • forall T. T: Alias => T: Bound.. because of the supertraits
    • forall T. T: Bound.. => T: Alias because of the impl
  • I don't think THIS RFC should specify the behavior for WC, only that we want the equivalence to hold. The correct behavior of where-clauses for trait definitions (in particular the implied bounds expansion) can be covered separately.
• Combining these two, impl Alias for Type should work and be equivalent to impl Bound0 for Type ... impl BoundN for Type.

Together (I think) these changes also allow for other transformations. It'd be good to capture these as part of the RFC's motivation. In addition to the "trait alias" = "trait + impl" equivalence above, the other equivalence we had in mind was being able to convert trait Foo { fn a(); fn b(); } into trait Foo: Bar { fn a(); } trait Bar { fn b(); } without breaking existing impls.

Note that just because the RFC includes this content doesn't mean we have to stabilize or even implement all of it at once. I think it'd be useful to identify "tiers" of support. In particular

Trait aliases that include bounds with one primary trait + auto or marker traits but no where-clauses

seems like an important tier that more-or-less works today.

[nikomatsakis]

This wasn't discussed in the meeting, but I personally would go further and say that my ideal is that you can do impl $Bound for Ty for any bound (i.e., anything that could come after a :). That would mean impl Debug + Display for Type etc. Basically, if you can do trait Printable: Debug + Display and then impl Printable for Type and have that cover all 3, why not be able to say it explicitly? (That example is maybe not so great because both traits offer a fmt method, so it may not be covered by the proposal without adding some way to disambiguate...)

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