Skip to content

where T::Ty<'_>: Trait bounds #155446

@GrigorenkoPV

Description

@GrigorenkoPV

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.

Metadata

Metadata

Assignees

Labels

A-lifetimesArea: Lifetimes / regionsC-feature-requestCategory: A feature request, i.e: not implemented / a PR.T-langRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions