RFC: Give anonymous lifetimes names based on their parameter

[lilyball]

When a function has parameters that are of type &T, they are given an anonymous lifetime. I propose that they should be given a lifetime named the same as the parameter, except in such cases where this shadows an already-declared lifetime.

This allows for less typing in common cases. For example,

fn foo<'a>(a: &'a [u8]) -> &'a [u8];

can be simplified to

fn foo(a: &[u8]) -> &'a [u8];

I also propose that lifetimes be allowed to use keywords as lifetime names again, so that 'self is valid, as this allows

fn foo(&self) -> &'self uint;

My only concern with this proposal is potential confusion if a defaulted lifetime name would have shadowed a declared name (and therefore the lifetime remains anonymous). I think this can be clarified with an appropriate note on the error. If I have something like

impl<'a> Foo<'a> {
    fn foo(&self, a: &[u8]) -> &'a [u8];
}

and I get a lifetime error, the compile could put a note telling me that the parameter a has an anonymous lifetime because the lifetime 'a was already in-scope. This note would only show up when a lifetime error occurs relating to a declared lifetime that is blocking a defaulted lifetime name.

[nikomatsakis]

This (or a variation of it) was recently proposed on rust-dev as well. I see the appeal, but I am wary of introducing a kind of "second system" of lifetime parameters. I am particularly wary of the ambiguity around shadowing that you raise at the end.

[lilyball]

@nikomatsakis I would love to do some sort of survey of the existing codebase to see a) how many existing functions could benefit from this, and b) how many would run afoul of the shadowing issue. My expectation right now is that a) is "a fair number", and b) is "almost none".

[nikomatsakis]

(That said, I do think there is room for improvement in our current scheme.)

[nikomatsakis]

I crave data, yes.

[vadimcn]

+1 on this proposal from me, obviously.

Though in fn foo(a: &[u8]) -> &'a [u8] a is the reference to [u8], so taken at the face value, 'a would be the lifetime of the local reference var, not of the array.
On the other hand, fn foo(a: [u8]) -> &'a [u8] is impossible, so there is no ambiguity here.

I think that Rust is very much in need of reduction of verbosity around usage of lifetimes, so I'll settle for a little magic.

[lilyball]

@vadimcn fn foo(a: &[u8]) -> &'a [u8] with this proposal is identical to fn foo<'a>(a: &'a [u8]) -> &'a [u8].

[vadimcn]

@kballard: Yes, but it's a bit subtle. The natural inclination would be to say "'a is the lifetime of a", which obviously isn't true. It's rather "'a is the lifetime of whatever a points to".

This has been partially addressed by lifetime elision but if such a change is still desired it should be proposed as an RFC. Can we close this?

[pcwalton]

Closing.