[This comment is outdated, I discussed this with the author and he improved the post :)]
I feel this post confuses two different notions of lifetime. And also mixes concrete lifetimes with lifetime parameters.
There's the CS notion of liveness, and then there's the lifetime notation in Rust.
> To know when to deallocate objects
This is handled by the CS notion of liveness. Well, an approximation to it. "Things are live until they are used, or until they can no longer be used".
The deallocation comes from Rust's affine type system.
In fact, Box<T> and other self-deallocating things don't have an associated "lifetime" in the Rust sense of the word, at least not one that dictates their deallocation.
The lifetime syntax is basically a form of generics which lets one put constraints on the allowed liveness of &-pointers and their ilk.
> example_function<'a> names the lifetime defined by this function, called 'a.
This isn't true. There does exist an anonymous inner lifetime for the scope of the function. It's not `'a`
What's happening here is that we're saying, "For any lifetime `'a`, we can have a version of example_function which returns a pointer which can live that long.". This doesn't compile, because the compiler knows that this function can only return pointers which live as long as its scope or less, not "any" lifetime. (Which is impossible to return from anyway).
This becomes clearer when you have a function like `fn foo<'a> (x: &'a [u8]) -> &'a u8 { &x[0] }` (FWIW if you omit the lifetimes Rust will elide them and internally produce the same function). Here, what we're saying is, "For any lifetime 'a, foo can take a slice that lives as long as 'a and return a pointer that lives as long as 'a". This compiles, because the compiler can see that a reference to x will live as long as x itself.
Similarly, with structs:
> Sheep<'c> instead of Sheep
>
> This is not doing anything concrete. It's just giving a name to the lifetime that Sheep structs can last for.
This is wrong, too. It's giving a _parameter_ to Sheep, saying "Every Sheep has an associated lifetime 'c, which is the lifetime of its inner reference".
In fact, it is possible to define the body of sheep in such a way that Sheep is guaranteed to live _longer_ than `'c` (instead of shorter, as in the example above). This is explained in the Rustonomicon (http://doc.rust-lang.org/stable/nomicon/subtyping.html). But it's an advanced topic, doesn't crop up often in actual Rust programming.
> Here, what we're saying is, "For any lifetime 'a, foo can take a slice that lives as long as 'a and return a pointer that lives as long as 'a".
Another way to phrase it is: the return value of the function is guaranteed to be valid for at least as long as the argument (but may borrow from it, and hence mutations of the argument need to be outlawed as long as the return value is held).
Well, my rephrasing was meant to be more than just s/validity/liveness/: I find that removing quantifiers (like for-all) often improves my understanding, as it usually gives more obvious context/motivation for what the goal is. It is then easier to understand the more formal version once I know approximately what it is trying to do.
I feel this post confuses two different notions of lifetime. And also mixes concrete lifetimes with lifetime parameters.
There's the CS notion of liveness, and then there's the lifetime notation in Rust.
> To know when to deallocate objects
This is handled by the CS notion of liveness. Well, an approximation to it. "Things are live until they are used, or until they can no longer be used".
The deallocation comes from Rust's affine type system.
In fact, Box<T> and other self-deallocating things don't have an associated "lifetime" in the Rust sense of the word, at least not one that dictates their deallocation.
The lifetime syntax is basically a form of generics which lets one put constraints on the allowed liveness of &-pointers and their ilk.
> example_function<'a> names the lifetime defined by this function, called 'a.
This isn't true. There does exist an anonymous inner lifetime for the scope of the function. It's not `'a`
What's happening here is that we're saying, "For any lifetime `'a`, we can have a version of example_function which returns a pointer which can live that long.". This doesn't compile, because the compiler knows that this function can only return pointers which live as long as its scope or less, not "any" lifetime. (Which is impossible to return from anyway).
This becomes clearer when you have a function like `fn foo<'a> (x: &'a [u8]) -> &'a u8 { &x[0] }` (FWIW if you omit the lifetimes Rust will elide them and internally produce the same function). Here, what we're saying is, "For any lifetime 'a, foo can take a slice that lives as long as 'a and return a pointer that lives as long as 'a". This compiles, because the compiler can see that a reference to x will live as long as x itself.
Similarly, with structs:
> Sheep<'c> instead of Sheep > > This is not doing anything concrete. It's just giving a name to the lifetime that Sheep structs can last for.
This is wrong, too. It's giving a _parameter_ to Sheep, saying "Every Sheep has an associated lifetime 'c, which is the lifetime of its inner reference".
In fact, it is possible to define the body of sheep in such a way that Sheep is guaranteed to live _longer_ than `'c` (instead of shorter, as in the example above). This is explained in the Rustonomicon (http://doc.rust-lang.org/stable/nomicon/subtyping.html). But it's an advanced topic, doesn't crop up often in actual Rust programming.