`where T::Ty<'_>: Trait` bounds
@sgasho is already working on this.
Since May 5, 2026.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
Currently for
trait SomeTrait {
type SomeType<'a>;
}
#[derive(Clone)]
struct Foo<T: SomeTrait> {
x: for<'a> fn(T::SomeType<'a>),
y: fn(T::SomeType<'_>),
}
the derive produces
#[automatically_derived]
impl<T: ::core::clone::Clone + SomeTrait> ::core::clone::Clone for Foo<T>
where
for<'a> T::SomeType<'a>: ::core::clone::Clone,
T::SomeType<'_>: ::core::clone::Clone {
#[inline]
fn clone(&self) -> Foo<T> {
Foo {
x: ::core::clone::Clone::clone(&self.x),
y: ::core::clone::Clone::clone(&self.y),
}
}
}
The bounds aren't "perfect" (#26925), but one of them (T::SomeType<'_>: Clone) gets rejected by the compiler. This showed up in #143131, where it was attributed to single_use_lifetime giving an invalid suggestion. I, personally, considered it to be more of a derive(Clone) flaw, but now that I think about it, I can't understand why T::SomeType<'_>: Clone is being rejected by the compiler in the first place and isn't expanded into for<'a> T::SomeType<'a>: Clone instead. Is this intentional? Is this just something that needs implementation? And if so, is it planned and tracked somewhere?
I asked on Zulip, but no definitive answer was reached.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.