RFC: Associated traits

[sandersaares]

Allow traits to declare associated traits — named trait constraints that are defined abstractly in a trait and given concrete values in implementations. Just as associated types let a trait abstract over which type is used, associated traits let a trait abstract over which constraints are imposed. This is the trait-level analog of associated types.

#![feature(associated_traits)]

// 1. Declare an associated trait in a trait definition.
trait Container {
    trait Elem;
    fn process<T: Self::Elem>(&self, item: T);
}

// 2. Each impl chooses the concrete constraints.
impl Container for MyContainer {
    trait Elem = Send + Clone;
    fn process<T: Self::Elem>(&self, item: T) { /* ... */ }
}

// 3. Generic code outside the impl uses `C::Elem` as a bound.
//    This is the primary use case: the caller is generic over
//    the constraints without knowing what they are.
fn process_item<C: Container, T: C::Elem>(container: &C, item: T) {
    container.process(item);
}

// 4. Fully-qualified syntax also works.
fn process_qualified<C: Container, T: <C as Container>::Elem>(container: &C, item: T) {
    container.process(item);
}

Previous discussion in #2190.

Prototype implementation: https://github.com/sandersaares/rust/tree/associated-traits

Rendered

Important

When responding to RFCs, try to use inline review comments (it is possible to leave an inline review comment for the entire file at the top) instead of direct comments for normal comments and keep normal comments for procedural matters like starting FCPs.

This keeps the discussion more organized.

[Nashenas88]

I'm curious whether this intends to support "no additional bounds". For example https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c5774b6a2c62aa4352b5f87ac941f3d0 where the two functions show you can have a where clause with an empty bound. See the where clause section in the reference https://doc.rust-lang.org/reference/items/generics.html#grammar-WhereClause . The syntax you supplied does not consider the Bound optional. Maybe it's helpful to add a dedicated grammar section here too?

It seems less useful to me in the example I provided, but I can imagine wanting to write a test-only trait impl without any additional bounds on the associated trait.

[sandersaares]

Oh, neat! I did not realize this possibility existed. Sure, supporting an empty bound sounds reasonable.

[theemathas]

It's not clear to me what C::Elem: Debug means. Here are some possible interpretations:

• The list of traits in the trait Elem = .... declaration in the impl, must literally contain Debug in the list.
• The list of traits (same as above), must contain Debug, or contain a subtrait of Debug.
• If the impl has a trait Elem = ..... Then, the compiler checks whether X: .... would imply X: Debug for all types X. This might hold if, say, we have a blanket impl<X: ....> Debug for X.

[theemathas]

Also, it's not clear to me why we would want only this direction of constraints. For example, why wouldn't we want to write something like where Trait: C::Elem? Such a bound would, for example, maybe allow something like:

trait Consumer {
    trait Requirements;
    fn consume<T: Self::Requirements>(&self, value: T);
}

fn consume_debug<C: Consumer>(c: C)
where
    Debug: C::Requirements
{
    // c can consume anything that implements Debug
    c.consume(1);
    c.consume("abc");
}

[theemathas]

Should something like dyn Container<Elem = Debug> be allowed?

[Jules-Bertholet]

To what degree can HRTB/non_lifetime_binders replace this feature? E.g.

trait Plugin<T> {
    fn run(&self, task: T);
}

trait SendPlugin = for<T: Send + 'static> Plugin<T>;
trait LocalPlugin = for<T: 'static> Plugin<T>;

[kennytm]

I think this is similar to how HRTB can simulate #1598 (GATs). "... a hacky attempt to work around the limitation".