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.

[Centril]

A fix to #61752 landed in #61919.

[Centril]

#63350 by @iluuu1994 & reviewed by @Centril fixed #61738. The standard library now uses ATBs in some places. This is further enhanced in #63584.

[clarfonthey]

I assume that fully implementing this feature isn't very high priority, but what do people think in terms of marking this flag as incomplete, given the comment I posted earlier this year?

I would offer to help with this but I'm not sure I'm aware of what's involved to do this. I'm also not sure where this is on the road map, but my assumption is it's lower than other planned features and no one's going to be working ensure this doesn't ambiguify (?) the existing trait behaviour for a while.

[oli-obk]

Tracking issues are impractical for discussions. I'm locking this issue. Please open new issues for problems and discuss the feature on zulip instead