On 19/05/14 20:52, Brian Anderson wrote:
On 05/15/2014 09:30 PM, Tommi wrote:
On 2014-05-16, at 7:14, Daniel Micay <danielmi...@gmail.com> wrote:

On 16/05/14 12:10 AM, Tommi wrote:
I was just wondering, why do we have to explicitly specify the lifetimes of references returned from functions? Couldn't the compiler figure those lifetimes out by itself by analyzing the code in the function?

Type inference is local to functions, so it couldn't do that. It would
be impossible to have libraries if inference needed to be global across
the entire program, and the errors would be *signicantly* harder to
understand as they would span across countless functions.

I'm sorry, but for some reason I completely fail to understand your explanation.

My thinking of how the compiler would work is that whenever it compiles a function, it would analyze it and in some sense "write in" the named lifetimes for that function. The named lifetimes would still be explicitly part of the signature of the function in the compiler's internal representation of the function, but not be visible in the source code.


I believe the compiler does this anylisis when the lifetimes in a signature are wrong - but just for the error message. It tries to suggest lifetimes that will work, but the analysis is not foolproof and can't be done automatically generally (idk why, ask niko).
Lately I've been thinking that it might be nice if one could omit the lifetimes from the list of generic parameters, as in:

fn foo<T>(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint)

instead of

fn foo<'a, 'b, T>(x: &'a T, y: &'b MyStruct) -> (&'b int, &'a uint)

Especially for otherwise non-generic functions, having to explicitly list lifetimes seems a bit redundant, as they are unambiguously defined in the function signature anyway (as opposed to type parameters, which don't have the special `'` marker).

Maybe this is worth writing up an RFC for...

-Michael
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to