6 ms·

excuse my ignorance, but what exactly does 'lifetime elision' mean?

mbrubeck 12y ago
In cases where a function's input and output have the same lifetime, the lifetime is now inferred. So instead of this: fn f<'a>(x: &'a SomeType) -> &'a OtherType you can now write this: fn f(x: &SomeType) -> &OtherType Same meaning, just more concise syntax.
- untothebreach 12y ago
  ah, got it. thanks!
- thomasahle 12y ago
  Uhm, what if I didn't want `&OtherType` to have the same lifetime? Would I then write: fn f<'a>(x: &'a SomeType) -> &'b OtherType ?
  - kimundi 12y ago
    Yes, though this particular code would not compile because one of the lifetimes is not declared.
  - kibwen 12y ago
    That would be illegal, because it only makes sense to return a reference when that reference is somehow linked to the lifetime of an input parameter. (Or when it has a lifetime of `static`, which means the referent is stored in static memory and thus is alive for the whole program.)
    - thristian 12y ago
      What if you're looking up the input in a temporary cache of some kind, and returning a reference to the cached value? The lifetime of the input and output would not be related in that scenario, but the output would not necessarily be 'static (maybe you build a cache, run some functions, tear it all down, then build a new cache with different values and do it all again).
      - steveklabnik 12y ago
        The lifetime would be matched to the lifetime of the cache, which has to be referred to somehow.
    - thomasahle 12y ago
      Ah cool, I still have a lot to learn about rust :)
  - TD-Linux 12y ago
    You wouldn't use a reference generally, if you're thinking of creating a new independent object you'd just return that. This is for cases when your return object is a reference into your argument, for example
steveklabnik 12y ago
Part of Rust's ownership system are 'lifetimes.' Without getting into the details, they're an annotation you occasionally add to code in certain situations. Like these two: fn get_mut<'a>(&'a mut self) -> &'a mut T; fn print<'a>(s: &'a str); The 'a parts are the lifetime annotations. We used to have a single inference rule for when you didn't need to write the annotation. With RFC 39[1], we added two more. These two extra inference rules removed 87% of the existing annotations, giving you this instead: fn get_mut(&mut self) -> &mut T; fn print(s: &str); This is a pretty huge readability win. 1: https://github.com/rust-lang/rfcs/blob/master/active/0039-lifetime-elision.md https://github.com/rust-lang/rfcs/blob/master/active/0039-li...
- untothebreach 12y ago
  oh ok, thanks. i knew what lifetimes were, but was confused by the 'elision.' Apparently I didn't connect 'elision' with 'elide.' So, new vocab word for today :)
- haberman 12y ago
  What kind of cases do you still need to write explicit lifetimes?
  - steveklabnik 12y ago
    I actually haven't had to since elision was implemented, so I can't give you a good rule of thumb from experience. Here's an overview of how the rules applied to the standard library at the time they were implemented, which is where the percentage came from: https://gist.github.com/aturon/da49a6d00099fdb0e861 https://gist.github.com/aturon/da49a6d00099fdb0e861
  - xKingfisher 12y ago
    The most common case I have run into is storing a reference inside another data structure.
kibwen 12y ago
Basically, after working with lifetimes for so long we realized that a great many functions that take lifetime parameters follow a similar and straightforward pattern. As of this release, we now allow you to omit lifetime parameters entirely for functions that follow this pattern, which is likely the vast majority of functions in your code that previously required such annotations. The detailed release notes have a more, er, detailed explanation: https://github.com/rust-lang/rust/wiki/Doc-detailed-release-notes https://github.com/rust-lang/rust/wiki/Doc-detailed-release-...
- yen223 12y ago
  This is a great change. But to clarify, functions which take 2 or more reference inputs won't benefit from this, since the compiler can't determine which lifetime parameter to use, right? Edit: Never mind, I RTFM. Turns out it can't benefit.

In cases where a function's input and output have the same lifetime, the lifetime is now inferred. So instead of this: fn f<'a>(x: &'a SomeType) -> &'a OtherType you can now write this: fn f(x: &SomeType) -> &OtherType Same meaning, just more concise syntax.

untothebreach 12y ago
ah, got it. thanks!
thomasahle 12y ago
Uhm, what if I didn't want `&OtherType` to have the same lifetime? Would I then write: fn f<'a>(x: &'a SomeType) -> &'b OtherType ?
- kimundi 12y ago
  Yes, though this particular code would not compile because one of the lifetimes is not declared.
- kibwen 12y ago
  That would be illegal, because it only makes sense to return a reference when that reference is somehow linked to the lifetime of an input parameter. (Or when it has a lifetime of `static`, which means the referent is stored in static memory and thus is alive for the whole program.)
  - thristian 12y ago
    What if you're looking up the input in a temporary cache of some kind, and returning a reference to the cached value? The lifetime of the input and output would not be related in that scenario, but the output would not necessarily be 'static (maybe you build a cache, run some functions, tear it all down, then build a new cache with different values and do it all again).
    - steveklabnik 12y ago
      The lifetime would be matched to the lifetime of the cache, which has to be referred to somehow.
  - thomasahle 12y ago
    Ah cool, I still have a lot to learn about rust :)
- TD-Linux 12y ago
  You wouldn't use a reference generally, if you're thinking of creating a new independent object you'd just return that. This is for cases when your return object is a reference into your argument, for example

steveklabnik 12y ago

Part of Rust's ownership system are 'lifetimes.' Without getting into the details, they're an annotation you occasionally add to code in certain situations. Like these two: fn get_mut<'a>(&'a mut self) -> &'a mut T; fn print<'a>(s: &'a str); The 'a parts are the lifetime annotations. We used to have a single inference rule for when you didn't need to write the annotation. With RFC 39[1], we added two more. These two extra inference rules removed 87% of the existing annotations, giving you this instead: fn get_mut(&mut self) -> &mut T; fn print(s: &str); This is a pretty huge readability win. 1: https://github.com/rust-lang/rfcs/blob/master/active/0039-lifetime-elision.md https://github.com/rust-lang/rfcs/blob/master/active/0039-li...

untothebreach 12y ago
oh ok, thanks. i knew what lifetimes were, but was confused by the 'elision.' Apparently I didn't connect 'elision' with 'elide.' So, new vocab word for today :)
haberman 12y ago
What kind of cases do you still need to write explicit lifetimes?
- steveklabnik 12y ago
  I actually haven't had to since elision was implemented, so I can't give you a good rule of thumb from experience. Here's an overview of how the rules applied to the standard library at the time they were implemented, which is where the percentage came from: https://gist.github.com/aturon/da49a6d00099fdb0e861 https://gist.github.com/aturon/da49a6d00099fdb0e861
- xKingfisher 12y ago
  The most common case I have run into is storing a reference inside another data structure.

kibwen 12y ago

Basically, after working with lifetimes for so long we realized that a great many functions that take lifetime parameters follow a similar and straightforward pattern. As of this release, we now allow you to omit lifetime parameters entirely for functions that follow this pattern, which is likely the vast majority of functions in your code that previously required such annotations. The detailed release notes have a more, er, detailed explanation: https://github.com/rust-lang/rust/wiki/Doc-detailed-release-notes https://github.com/rust-lang/rust/wiki/Doc-detailed-release-...

yen223 12y ago
This is a great change. But to clarify, functions which take 2 or more reference inputs won't benefit from this, since the compiler can't determine which lifetime parameter to use, right? Edit: Never mind, I RTFM. Turns out it can't benefit.