Lifetimes of references - Rust for C-Programmers

6.7 Lifetimes: Ensuring Valid References

Lifetimes in Rust guarantee that references never outlive the data they point to. Each reference carries a lifetime, indicating how long it can be safely used.

6.7.1 Understanding Lifetimes

All references in Rust have a lifetime. The compiler checks that no reference outlasts the data it refers to. In many cases, Rust can infer lifetimes automatically. When it cannot, you must add lifetime annotations to show how references relate to each other.

6.7.2 Lifetime Annotations

In simpler code, Rust infers lifetimes transparently. In more complex scenarios, you must explicitly specify them so Rust knows how references interact. Lifetime annotations:

Use an apostrophe followed by a name (e.g., 'a).
Appear after the & symbol in a reference (e.g., &'a str).
Are declared in angle brackets (<'a>) after the function name, much like generic type parameters.

These annotations guide the compiler on how different references’ lifetimes overlap and what constraints are needed to avoid invalid references.

Example: Function Returning a Reference

#![allow(unused)]
fn main() {
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}
}

What 'a means: A placeholder for a lifetime enforced by Rust.
Why 'a appears multiple times: Specifying 'a in the function signature (fn longest<'a>) and in each reference (&'a str) tells the compiler that x, y, and the return value share the same lifetime constraint.
Why 'a is in the return type: This ensures the function never returns a reference that outlives either x or y. If either goes out of scope, Rust forbids using what could otherwise be a dangling reference.

By enforcing explicit lifetime rules in more complex situations, Rust eliminates an entire category of dangerous pointer issues common in lower-level languages.

6.7.3 Invalid Code and Lifetime Misunderstandings

A common error is returning a reference to data that no longer exists:

#![allow(unused)]
fn main() {
fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() { x } else { y }
}
}

The compiler rejects this because it cannot be certain that the reference remains valid without explicit lifetime boundaries.

Example with Inner Scope

fn main() {
    let result;
    {
        let s1 = String::from("hello");
        result = longest(&s1, "world");
    } // s1 is dropped here
    // println!("Longest is {}", result); // Error: result may point to freed memory
}

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

Once s1 goes out of scope, result might refer to invalid memory. Rust stops you from compiling this code.

String Literals and `'static` Lifetime

String literals (e.g., "hello") have the 'static lifetime (they remain valid for the program’s entire duration). If combined with references of shorter lifetimes, Rust ensures no invalid references survive.

Rust for C-Programmers