Tracking issue for RFC 2289, "Associated type bounds"

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:

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);         // ??????????

@kennytm

@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. :)

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

@kennytm

@kennytm sounds reasonable. 👍

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)}

@scalexm

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 :)

@Centril

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

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)

@Nemo157

@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.

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.

first design

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

Rollup merge of rust-lang#122055 - compiler-errors:stabilize-atb, r=o…

Auto merge of rust-lang#122055 - compiler-errors:stabilize-atb, r=oli…

Navigation Menu

Repository navigation

Tracking issue for RFC 2289, "Associated type bounds" #52662

43 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for RFC 2289, "Associated type bounds" #52662

Description

Activity

kennytm commented on Jul 24, 2018

Centril commented on Jul 24, 2018

kennytm commented on Jul 24, 2018

Centril commented on Jul 24, 2018

LukasKalbertodt commented on Mar 17, 2019

Centril commented on Mar 17, 2019

LukasKalbertodt commented on Mar 17, 2019

Nemo157 commented on Mar 21, 2019

Centril commented on Mar 21, 2019

43 remaining items

mimoo commented on Oct 11, 2022

clarfonthey commented on Oct 25, 2022

joshtriplett commented on Oct 17, 2023

maia-s commented on Jan 22, 2024

gui1117 commented on Mar 3, 2024

oli-obk commented on Mar 3, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions