Lifetime Annotation

Lifetime annotations are explicit, compile-time generic parameters that describe the relationship between the scopes of multiple references. They do not alter the runtime duration of a value; rather, they instruct the Rust borrow checker on how to validate that references remain valid for a required duration, ensuring memory safety by preventing dangling pointers.

Because lifetimes are a type of generic parameter, they must be declared inside angle brackets <> before they can be used. The syntax utilizes an apostrophe (') followed by a lowercase identifier.

&i32        // A reference with an implicit (elided) lifetime
&'a i32     // A reference with an explicit lifetime 'a
&'a mut i32 // A mutable reference with an explicit lifetime 'a

Function Signatures

When a function takes or returns references, lifetime annotations map the input lifetimes to the output lifetimes.

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

In this signature, <'a> declares the lifetime. By applying 'a to both parameters and the return type, the annotation dictates a strict contract: the returned reference will be valid only for the length of the shortest scope among the inputs x and y.

Struct Definitions

If a struct holds a reference, the struct itself must be annotated with a lifetime. This enforces that the struct instance cannot outlive the data it references.

struct Context<'a> {
    config: &'a str,
}

Implementation Blocks

When implementing methods for a struct that contains lifetime annotations, the lifetimes must be declared on the impl block so they can be used in the struct type and its methods.

impl<'a> Context<'a> {
    fn get_config(&self) -> &'a str {
        self.config
    }
}

Lifetime Elision Rules

To reduce boilerplate, the Rust compiler applies three deterministic rules (Lifetime Elision) to infer lifetimes automatically. If the compiler cannot resolve all lifetimes after applying these rules, it throws a compilation error requiring explicit annotations.

1. Input Rule: Each elided lifetime in input parameters becomes a distinct lifetime parameter.

   (e.g., fn foo(x: &i32, y: &i32) becomes fn foo<'a, 'b>(x: &'a i32, y: &'b i32))

2. Single Input Rule: If there is exactly one input lifetime parameter, that lifetime is assigned to all elided output lifetimes.

   (e.g., fn foo(x: &i32) -> &i32 becomes fn foo<'a>(x: &'a i32) -> &'a i32)

3. Method Rule: If there are multiple input lifetime parameters, but one of them is &self or &mut self, the lifetime of self is assigned to all elided output lifetimes.

Lifetime Bounds (Subtyping)

Lifetimes can be constrained relative to one another using bounds, similar to trait bounds. This is known as lifetime subtyping.

struct Parser<'c, 's: 'c> {
    context: &'c Context<'s>,
}

The syntax 's: 'c is read as “lifetime 's outlives 'c”. It guarantees to the compiler that the reference to the data ('s) will live at least as long as the context ('c) holding it.

Special Lifetimes

• 'static: Denotes a reference that can live for the entire duration of the program. String literals (&'static str) possess this lifetime inherently because their data is stored directly in the binary’s read-only data segment.
• '_: The anonymous lifetime. It is used to explicitly tell the compiler to infer the lifetime using elision rules, or to indicate in a trait implementation that a lifetime is present but its specific identifier is irrelevant to the current scope.

Master Rust with Deep Grasping Methodology!

Learn More