Lifetimes should be inferred in simple cases

[mhart]

Rust newbie here. This is very probably a dupe, but my GH foo failed me.

The following fails to compile:

fn my_fn<T>(items: T) where T: Iterator<&str> {
    println!("hello")
}

With:

<anon>:5:41: 5:45 error: missing lifetime specifier [E0106]
<anon>:5 fn my_fn<T>(items: T) where T: Iterator<&str> {
                                                 ^~~~

But it's unclear to me why the compiler can't just infer the lifetime here?

Shouldn't this be the default choice?

fn my_fn<'a, T>(items: T) where T: Iterator<&'a str> {
    println!("hello")
}

Edit: So it could also be 'static, but I wouldn't have thought that would be the default (or encouraged) case. If you did want it to be static, then you could declare it explicitly. Similar to how variables are immutable by default (without needing an explicit declaration), yet if you want them to be mutable you declare it.

[zwarich]

It could also be 'static.

[mhart]

@zwarich – ok, but could one make a case that if you wanted that then you'd make it explicit? I wouldn't have thought 'static would be the default choice.

[zwarich]

@mhart There's no default choice here.

[mhart]

@zwarich Can you explain that a little more?

[pythonesque]

As @zwarich said, there's no default choice that's right enough of the time. For example, you could require the lifetime of the string to be bound to the lifetime on a struct (I have done this in the past).

In general, even the current rules for lifetime inference are not always right, and they are quite conservative. I'm not sure how you could do it properly in a case like this without it becoming confusing.

[mhart]

Can you show me what you mean with being bound to the lifetime on a struct in this example? There's no struct involved, so I'm a bit confused. Saying "I have done this in the past" actually makes it sound as though it's a rare thing to do still.

In my mind it's analogous to having default immutability for a variable vs the times when you need to explicitly declare it as mutable.

I'm struggling to understand the actual problem with assuming the lifetime in the example given. Is there some way that things would become unsafe that the compiler wouldn't catch?

This actually started from the IRC channel when I posed the question and got this:

hichaelmart Hi all, a question about lifetime specifiers – can someone explain why the compiler doesn't just automatically create these in the simple cases? ie: fn my_fn<T>(items: T) -> String where T: Iterator<&str>
eddyb hichaelmart: long standing issue
eddyb it's something that should be done IMO

So I'm not alone in thinking this is something that should be done.

Can someone talk through the problems that would occur (that the compiler wouldn't catch) if it were to assume the lifetimes in the example I gave?

I just worry that simple things like this will turn off newcomers – and if they can be fixed, then it will really help the adoption of the language.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#762