Lifetime parameters are silently deleted

[djzin]

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]

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]

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]

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

[nikomatsakis]

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.

[nikomatsakis]

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

[nikomatsakis]

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]

triage: P-high