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

early- vs late-bound lifetimes #71

Open
nikomatsakis opened this issue Jun 25, 2022 · 0 comments
Open

early- vs late-bound lifetimes #71

nikomatsakis opened this issue Jun 25, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@nikomatsakis
Copy link
Contributor

We have to figure out how to model early- vs late-bound lifetimes.

I believe that we should be able to erase the distinction in a-mir-formality (and, hopefully, eventually in rustc as well). The idea would be that all parameters can become late-bound, because we can now support types that are fully quantified over types and lifetimes. I think this is the basic approach we should take.

However, to maintain compatibility with rustc, we want to make it so that, at MIR time, some set of those parameters become "fixed". Consider a case like this, which compiles in rustc today...

fn foo<T>(t: T) { }
fn main() {
    let f = foo; // f: foo<?T>
    f(None); // ?T = Option<?U>
    f(Some(22)); // ?U = i32
}

...under the model I'm proposing, each call to f would be independent, and so the f(None) call would need to be written f(None::<i32>). I think that we should write an RFC that changes rust's behavior to match (perhaps in Rust 2024) but in the meantime I'd like to be able to model both variants in a-mir-formality.

Anyway, this is a bit of an "open-ended" issue without a clear path to solution--- we're not ready to tackle this yet. Some other considerations:

@nikomatsakis nikomatsakis added the enhancement New feature or request label Jun 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant