Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for existential lifetimes #60670

Open
3 tasks
alexreg opened this issue May 9, 2019 · 3 comments
Open
3 tasks

Tracking issue for existential lifetimes #60670

alexreg opened this issue May 9, 2019 · 3 comments
Labels
A-impl-trait Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch. A-lifetimes Area: Lifetimes / regions A-type-system Area: Type system T-lang Relevant to the language team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@alexreg
Copy link
Contributor

alexreg commented May 9, 2019

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:

impl Trait<'b> for Cell<&'a u32> { }

fn foo(x: Cell<&'x u32>) -> impl Trait<'y> where 'x: 'y { x }

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:

fn foo(x: Cell<&'x u32>) -> impl exists<'x: 'y> Trait<'y> where 'x: 'y { x }

Although it be noted there is no need for user-facing exists<...> syntax; only HIR and ty representations probably. The concrete type corresponding to impl 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 Captures marker trait solution, in some sense.

Steps:

CC @Centril @nikomatsakis @matthewjasper @cramertj

@Centril Centril added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue. A-impl-trait Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch. A-type-system Area: Type system A-lifetimes Area: Lifetimes / regions labels May 9, 2019
Centril added a commit to Centril/rust that referenced this issue May 28, 2019
…s, r=nikomatsakis

Add better tests for hidden lifetimes in impl trait

cc rust-lang#60670
Centril added a commit to Centril/rust that referenced this issue May 28, 2019
…s, r=nikomatsakis

Add better tests for hidden lifetimes in impl trait

cc rust-lang#60670
Centril added a commit to Centril/rust that referenced this issue May 28, 2019
…s, r=nikomatsakis

Add better tests for hidden lifetimes in impl trait

cc rust-lang#60670
@alexreg
Copy link
Contributor Author

alexreg commented Jun 5, 2019

I think @nikomatsakis is talking about a different issue there?

@steveklabnik
Copy link
Member

Triage: not aware of any changes

@joshtriplett joshtriplett added T-types Relevant to the types team, which will review and decide on the PR/issue. and removed C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Jun 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-impl-trait Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch. A-lifetimes Area: Lifetimes / regions A-type-system Area: Type system T-lang Relevant to the language team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants