Tracking issue for RFC 2289, "Associated type bounds"

[Centril]

This is a tracking issue for the RFC "Associated type bounds of form MyTrait<AssociatedType: Bounds>" (rust-lang/rfcs#2289). The feature gate is #![feature(associated_type_bounds)].

Steps:

• Implement the RFC - Implementation of RFC 2289 (associated_type_bounds) #57428
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• Does allowing this for dyn trait objects introduce any unforeseen issues? This can be resolved during stabilization.

  • Use for trait objects has been forbidden in Remove support for associated_type_bound nested in dyn types #120719

• Resolve exact desugaring in the context of putting bounds on an associated type of a trait. See discussion in the RFC.

• Consider nested lifetimes, https://gist.github.com/Centril/b0e62d31d4ae1849535c3e506e1fad64.

TODO:

• Extend with tests in Implementation of RFC 2289 (associated_type_bounds) #57428 (comment).

• associated_type_bounds: errors with ambiguous associated type #61752

[kennytm]

Does allowing this for dyn trait objects introduce any unforeseen issues?

😕 How does it work? For instance while dyn Iterator<Item = T> is object-safe, dyn Iterator<Item: Debug> should not since its .next() returns... impl Debug (but dynamic)?

trait Tr {
    type Assoc;
    fn input(&self, assoc: &Self::Assoc);
    fn output(&self) -> Self::Assoc;
}

let a: &Tr<Assoc: Debug> = ...;
let o = a.output();  // ???
a.input(&o);         // ???

let b: &Tr<Assoc: Debug> = ...;
b.input(&o);         // ??????????

[Centril]

@kennytm I think that while dyn Iterator<Item: Debug> make syntactic sense to parse (to keep the parser simpler), it doesn't make much sense semantically for the reasons you've noted. Nicely spotted. :)

[kennytm]

So I suppose we could parse dyn Trait<Assoc: Bound> into AST, but will reject it during HIR lowering or typeck.

[Centril]

@kennytm sounds reasonable. 👍

[LukasKalbertodt]

I haven't found any discussion about this: what about super trait bounds? In particular: whether other code can "rely" on it. Example (current Rust, Playground):

trait Color {
    type Channel;
}

trait CloneColor: Color
where
    Self::Channel: Clone,
{}

fn foo<T: CloneColor>() {
    let f = T::Channel::clone;
}

This errors. While foo can assume that T also implements Color (the direct super trait bound) and thus T::Channel works, foo cannot assume the where bound of the trait to be true, and thus ::clone doesn't work. The compiler says "the trait bound <T as Color>::Channel: std::clone::Clone is not satisfied". I can't quite remember what this is called, but I once heard a term that describes what things other code can rely on and what not (maybe something fancy like "projection"?).

My question is: how would the following code behave?

trait CloneColor: Color<Channel: Clone> {}

Would it behave as the first code example or would other code now be able to deduce T::Channel: Clone from T: CloneColor?

^{(I hope I'm not missing something obvious here)}

[Centril]

This errors.

#44491 will likely change this :) (cc @scalexm)

My question is: how would the following code behave?

Same as:

trait CloneColor where Self: Color, <Self as Color>::Channel: Clone {}

Would it behave as the first code example or would other code now be able to deduce T::Channel: Clone from T: CloneColor?

Depends on whether you have implied bounds or not :)

[LukasKalbertodt]

@Centril Thanks for the quick explanation! I didn't know implied bounds would change this too -- that's great!

[Nemo157]

How does this interact with HRLB? I just discovered that trait aliases allow you to write the constraints required for working with async functions/closures, but could this be another way to do so?

You can currently write:

trait Foo<'a> = FnOnce<(&'a u8,)> where <Self as FnOnce<(&'a u8,)>>::Output: Future<Output = u8> + 'a;

fn foo<F: for<'a> Foo<'a>>(f: F)

and presumably once this is implemented it could be:

trait Foo<'a> = FnOnce<(&'a u8,), Output: Future<Output = u8> + 'a>;

fn foo<F: for<'a> Foo<'a>>(f: F)

but can you go all the way to:

fn foo<F: for<'a> FnOnce<(&'a u8,), Output: Future<Output = u8> + 'a>>(f: F)

[Centril]

@Nemo157 When you write:

where
    Foo: for<'a> Bar<'a, Assoc: Bound>

it should desugar into:

where
    Foo: for<'a> Bar<'a>,
    for<'a> <Foo as Bar<'a>>::Assoc: Bound,

However, rustc is generally unhappy with for<'a> <Foo as Bar<'a>>::Assoc: Bound today as I found out when writing tests for #57428. Chalk will hopefully makes things better in the future and throw out some of the bugs.