rust-lang / rust-lang/rust

`where T::Ty<'_>: Trait` bounds

Open
#155,446 1 comment 0 reactions 1 assignee View on GitHub

@sgasho is already working on this.

Since May 5, 2026.

A-lifetimes C-feature-request T-lang T-types
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.