-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
Tracking issue for existential lifetimes #60670
Copy link
Copy link
Closed
Labels
A-impl-traitArea: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.A-lifetimesArea: Lifetimes / regionsArea: Lifetimes / regionsA-type-systemArea: Type systemArea: Type systemT-langRelevant to the language teamRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-impl-traitArea: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.A-lifetimesArea: Lifetimes / regionsArea: Lifetimes / regionsA-type-systemArea: Type systemArea: Type systemT-langRelevant to the language teamRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
This is a tracking issue for existential lifetimes.
Description:
Allow hiding a type (via
impl Trait) that is invariant over some lifetime without explicitly mentioning the invariant lifetime.Consider the following:
There is no reason this cannot be legal, although it is not permitted at present. We would want to translate the function signature internally into something like:
Although it be noted there is no need for user-facing
exists<...>syntax; only HIR andtyrepresentations probably. The concrete type corresponding toimpl exists<'x: 'y> Trait<'y>can this be soundly checked by the compiler at use site.Note, we still need to be careful to ban situations like those mentioned by @matthewjasper in #59402. By actually embedding the existential lifetime in the type rather than simply doing a check when resolving the opaque type, we should be able to resolve these issues, however. One can view this solution as a "compiler-internalised" version of the
Capturesmarker trait solution, in some sense.Steps:
impl Trait#57870 and Allow hidden lifetimes inimpl Trait, take 2 #59402, @nikomatsakis for mentoring instructions?)CC @Centril @nikomatsakis @matthewjasper @cramertj