Is there a syntax/RFC for implied impl trait bounds in trait impls?

Hi! Sorry if the topic sounds confusing. I'm not sure how this could be better described. The words "impl" and "trait" are really being overloaded here.

Basically, while using the type_alias_impl_trait nightly feature with associated types, I'm encountering many cases where I have to repeat long generic bounds at multiple impl sites:

// foo.rs
trait Foo {
    type SomeIter<'a>: Iterator<Item = &'a SomeStuff<Long, Generic, Types>> + Clone + Whatever<ItIsLong> + 'a
    where
        Self: 'a;
}

// Then, in many other separate files where I have to implement Foo
impl Foo for A {
    type SomeIter<'a>
    where
        Self: 'a
    // Here, the whole long trait bound repeated in another file.
    = impl Iterator<Item = &'a SomeStuff<Long, Generic, Types>> + Clone + Whatever<ItIsLong> + 'a;
}

impl Foo for B {
    type SomeIter<'a>
    where
        Self: 'a
    // ...and again
    = impl Iterator<Item = &'a SomeStuff<Long, Generic, Types>> + Clone + Whatever<ItIsLong> + 'a;
}

impl Foo for C {
    type SomeIter<'a>
    where
        Self: 'a
    // ...and again
    = impl Iterator<Item = &'a SomeStuff<Long, Generic, Types>> + Clone + Whatever<ItIsLong> + 'a;
}

This could be made a bit less painful with a "trait alias" and a blanket impl, but still, the whole repetition feels rather unnecessary. It would be great if we could just say something like:

impl Foo for A {
    type SomeIter<'a> where Self: 'a = impl;
}

...and have the compiler infer the appropriate bounds from the trait declaration. Is this already a thing and I'm just out of the loop, or is there an existing proposal for something like this? Might there be any technical problems that make this impossible to have somehow?

Thanks for your time!

I suppose there’s this draft containing a relevant section:

impl-trait-goals/0000-impl-trait-in-traits.md at impl-trait-in-traits · cramertj/impl-trait-goals · GitHub → “Return Position: Associated Type Inference”

It suggests a different approach which should probably have the desired effect; extending it to the GAT case, I suppose you’d still need to write the trait bound once per impl though; it rather skips the need to mention the “Self::SomeIter” type explicitly, provided there’s a (single (?)) method that uses it.

For reference, I found this via this page which links to this page which links to it.


Note that what you suggest might be problematic, because it conflates the minimum requirements from the trait definition of what should be known about the associated type with the actual information provided for the opaque impl … type it’s being instantiated with. The latter could offer additional bounds.

To avoid boilerplate here, it seems like trait aliases might be useful?

1 Like

Wow. There was absolutely no chance I'd have stumbled on anything relevant myself. That's a helpful link. Thanks a lot!

Ahhh I see. Indeed that would be problematic. I was mainly thinking about using the associated types through the trait, but separating the two could perhaps be very useful if/once Rust supports HRTBs over type parameters. That would alleviate another huge pain point working with GATs currently. I suppose that might be chalk territory, though?

Seems that trait aliases are the way to go, then!

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.