Lifetimes

Let's try to complete the previous exercise by adding an implementation of IntoIterator for &TicketStore, for maximum convenience in for loops.

Let's start by filling in the most "obvious" parts of the implementation:

impl IntoIterator for &TicketStore {
    type Item = &Ticket;
    type IntoIter = // What goes here?

    fn into_iter(self) -> Self::IntoIter {
        self.tickets.iter()
    }
}

What should type IntoIter be set to?
Intuitively, it should be the type returned by self.tickets.iter(), i.e. the type returned by Vec::iter().
If you check the standard library documentation, you'll find that Vec::iter() returns an std::slice::Iter. The definition of Iter is:

pub struct Iter<'a, T> { /* fields omitted */ }

'a is a lifetime parameter.

Lifetime parameters

Lifetimes are labels used by the Rust compiler to keep track of how long a reference (either mutable or immutable) is valid.
The lifetime of a reference is constrained by the scope of the value it refers to. Rust always makes sure, at compile-time, that references are not used after the value they refer to has been dropped, to avoid dangling pointers and use-after-free bugs.

This should sound familiar: we've already seen these concepts in action when we discussed ownership and borrowing. Lifetimes are just a way to name how long a specific reference is valid.

Naming becomes important when you have multiple references and you need to clarify how they relate to each other. Let's look at the signature of Vec::iter():

impl <T> Vec<T> {
    // Slightly simplified
    pub fn iter<'a>(&'a self) -> Iter<'a, T> {
        // [...]
    }
}

Vec::iter() is generic over a lifetime parameter, named 'a.
'a is used to tie together the lifetime of the Vec and the lifetime of the Iter returned by iter(). In plain English: the Iter returned by iter() cannot outlive the Vec reference (&self) it was created from.

This is important because Vec::iter, as we discussed, returns an iterator over references to the Vec's elements. If the Vec is dropped, the references returned by the iterator would be invalid. Rust must make sure this doesn't happen, and lifetimes are the tool it uses to enforce this rule.

Lifetime elision

Rust has a set of rules, called lifetime elision rules, that allow you to omit explicit lifetime annotations in many cases. For example, Vec::iter's definition looks like this in std's source code:

impl <T> Vec<T> {
    pub fn iter(&self) -> Iter<'_, T> {
        // [...]
    }
}

No explicit lifetime parameter is present in the signature of Vec::iter(). Elision rules imply that the lifetime of the Iter returned by iter() is tied to the lifetime of the &self reference. You can think of '_ as a placeholder for the lifetime of the &self reference.

See the References section for a link to the official documentation on lifetime elision.
In most cases, you can rely on the compiler telling you when you need to add explicit lifetime annotations.

References

Exercise

The exercise for this section is located in 06_ticket_management/06_lifetimes