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

Lifetime parameters are silently deleted #42115

Closed
djzin opened this issue May 20, 2017 · 8 comments
Closed

Lifetime parameters are silently deleted #42115

djzin opened this issue May 20, 2017 · 8 comments
Assignees
Labels
P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@djzin
Copy link
Contributor

djzin commented May 20, 2017

This compiles:

fn lifetime<'a>()
    where &'a (): 'a
{
    /* do nothing */
}

fn main() {
    lifetime::<'static>()
}

as does this:

fn lifetime<'a>() {} 
fn main() {
    lifetime();
}

but this fails:

fn lifetime<'a>() {}
fn main() {
    lifetime::<'static>();
}
rustc 1.19.0-nightly (5dfcd85fd 2017-05-19)
error[E0088]: too many lifetime parameters provided: expected at most 0 lifetime parameters, found 1 lifetime parameter
 --> <anon>:3:5
  |
3 |     lifetime::<'static>();
  |     ^^^^^^^^^^^^^^^^^^^ expected 0 lifetime parameters

error: aborting due to previous error
@eddyb
Copy link
Member

eddyb commented Jun 7, 2017

They become late-bound when not used in bounds or are used only the return type.
cc @nikomatsakis We should really do something about this.

@nikomatsakis
Copy link
Contributor

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.)

@nikomatsakis nikomatsakis added I-nominated T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 7, 2017
@nikomatsakis
Copy link
Contributor

Purpose of nomination is to try and decide how we should handle this and how to prioritize.

@nikomatsakis
Copy link
Contributor

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.

@rust-highfive rust-highfive added P-medium Medium priority and removed I-nominated labels Jun 8, 2017
@nikomatsakis
Copy link
Contributor

I'm going to change to T-lang. There are definitely some thorny questions here.

@nikomatsakis nikomatsakis added T-lang Relevant to the language team, which will review and decide on the PR/issue. I-nominated and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 8, 2017
@nikomatsakis
Copy link
Contributor

Discussed in the @rust-lang/lang meeting -- we agree that restricting to 100% early-bound is the right thing here. As proposed in #42492

@nikomatsakis
Copy link
Contributor

triage: P-high

@rust-highfive rust-highfive added P-high High priority and removed P-medium Medium priority labels Jun 15, 2017
@nikomatsakis nikomatsakis added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 15, 2017
@nikomatsakis
Copy link
Contributor

@petrochenkov since you agreed to take a stab at that lint, I'm assigning you to the issue for now :) hope that's ok

@nikomatsakis nikomatsakis removed the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Jun 15, 2017
bors added a commit that referenced this issue Jul 18, 2017
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants