You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
...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:
in rustc, impls can have more/different late-bound lifetimes vs the trait (check that fn decls in impls/traits match #70 requires that the have precisely the same lifetime parameters).
The text was updated successfully, but these errors were encountered:
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...
...under the model I'm proposing, each call to
f
would be independent, and so thef(None)
call would need to be writtenf(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:
The text was updated successfully, but these errors were encountered: