-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Lifetime parameters are silently deleted #42115
Comments
They become late-bound when not used in bounds or are used only the return type. |
Yeah the current situation is pretty goofy. It'd probably be best if we could report an error when providing lifetimes unless you provide all of them (late and early bound) -- at minimum, for now, we could just make it an error to specify lifetimes if any of them are late bound. Nominating so this doesn't get lost. I'm a bit nervous because of backwards compatibility. (In fact, I already recommended to @jdm a hack that relied on the current behavior.) |
Purpose of nomination is to try and decide how we should handle this and how to prioritize. |
triage: P-medium This situation has been a problem for a long time in various forms, and is a bit obscure, but nonetheless current situation is not great. To some extent this is also a @rust-lang/lang question. |
I'm going to change to T-lang. There are definitely some thorny questions here. |
Discussed in the @rust-lang/lang meeting -- we agree that restricting to 100% early-bound is the right thing here. As proposed in #42492 |
triage: P-high |
@petrochenkov since you agreed to take a stab at that lint, I'm assigning you to the issue for now :) hope that's ok |
Support generic lifetime arguments in method calls Fixes #42403 Fixes #42115 Lifetimes in a method call `x.f::<'a, 'b, T, U>()` are treated exactly like lifetimes in the equivalent UFCS call `X::f::<'a, 'b, T, U>`. In addition, if the method has late bound lifetime parameters (explicit or implicit), then explicitly specifying lifetime arguments is not permitted (guarded by a compatibility lint). [breaking-change] because previously lifetimes in method calls were accepted unconditionally. r? @eddyb
This compiles:
as does this:
but this fails:
The text was updated successfully, but these errors were encountered: