Lifetimes and References

In Rust, every reference has a lifetime, which corresponds to the scope within which that reference is valid. Most of the time, lifetimes are implicit and inferred by the compiler thanks to lifetime elision rules. However, when the relationship between the lifetimes of different references is ambiguous, we must annotate them explicitly.

The main objective of lifetimes is to prevent dangling references (references to data that has already been deallocated from memory).

Lifetime Annotation Syntax

Lifetime names start with an apostrophe (') and are usually short lowercase letters (like 'a). Lifetime annotations do not change the actual lifetime of variables, but they indicate to the compiler the relationship between the validity of inputs and outputs.

For example, if a function takes two string reference parameters and returns a string reference, and we want the returned reference to be valid as long as both input parameters are valid, we use:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

Lifetimes in Data Structures

If a structure contains a field that is a reference, we must explicitly annotate the lifetime on that reference to ensure that the struct instance cannot outlive the data it refers to:

struct ImportantExcerpt<'a> {
    part: &'a str,
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.').next().unwrap();
    let i = ImportantExcerpt {
        part: first_sentence,
    };
}

The Static Lifetime

The 'static lifetime is a special lifetime that lasts for the entire duration of the program. All string literals (&str) implicitly have a 'static lifetime because they are stored directly inside the binary executable.

let s: &'static str = "I have a static lifetime.";

Try it yourself

Exercise 1: The longest function

Exercise 2: Structs with References

Exercise 3: Static References