Lifetimes

What it is and why it exists

Every Rust reference has a lifetime: a region of the program where that reference can be used safely. The borrow checker verifies that a reference still points to valid data at every use and that shared and exclusive access do not overlap illegally. This analysis happens at compile time; there is no runtime lifetime timer.

Lifetimes solve the dangling-reference problem. If a reference remained usable after its owner was destroyed, reading it could access memory that had been freed or repurposed. Rust refuses to defer that risk to runtime, so a borrow whose source cannot be proven valid causes a compilation error.

Most lifetimes are implicit in source code. The compiler derives valid regions from owners, reference creation, control flow, and actual reference uses; non-lexical lifetimes (NLL) mean a borrow can usually end after its last use instead of continuing to the closing brace.

An explicit lifetime annotation starts with an apostrophe, as in 'a or 'input. It names a relationship among references so the function caller and implementation obey the same type contract. An annotation describes an existing relationship; it does not change when a value is destroyed, allocate memory, or copy data.

Functions returning input slices, structs with borrowed fields, trait objects, closures, and cross-thread tasks all expose lifetime boundaries. When a parameter is only read during a call, &T is often enough; relationships more often need to be written when a reference is returned, stored, or hidden behind a generic interface.

Lifetimes are an ownership-design question before they are a syntax question. If a function creates new data, returning String or another owned value is usually natural. If the result is genuinely part of an input, returning a reference avoids a copy and preserves its origin relationship in the type.

How it works

Regions follow actual uses

The compiler finds a valid region for each borrow that satisfies every constraint. That region must cover every use of the reference, cannot cross the source data’s validity, and cannot overlap a conflicting access. It is often shorter than the lexical block containing the reference variable.

The flow below shows when an ordinary shared borrow can end. If the reference is never read after its last use, a later operation that needs exclusive access can begin.

The end of a borrow does not destroy its owner. The owner may continue to exist and be borrowed again, and the old reference variable may even remain in lexical scope as long as it is not used later. To diagnose a conflict, locate reference creation, the conflicting access, and the last use that keeps the earlier borrow active.

Annotations constrain inputs and outputs

The signature fn choose<'a>(x: &'a str, y: &'a str) -> &'a str declares one lifetime parameter and places both inputs and the output in the same relationship. The caller must supply a region in which both input borrows are valid, and the returned reference can only be used within that common region.

A shared 'a does not mean the owners must live equally long. The compiler can shorten the longer borrow to their common usable region. Because the implementation may return either input, the caller must conservatively keep both inputs valid for the result’s use.

If a function can only return its first input, the second parameter should not restrict the result. fn prefix<'text>(text: &'text str, delimiter: &str) -> &'text str states precisely that the result comes from text while delimiter is used only during the call. Independent relationships admit more valid calls and show reviewers where the data originates.

The caller chooses lifetime parameters at each call site, and the implementation must work for every legal choice. It cannot disguise a slice of a local String as an arbitrary returned 'a, because the local owner is destroyed at function exit and cannot satisfy the region a caller may request.

Elision follows deterministic rules

Lifetime elision is a fixed set of signature-completion rules, not a guess based on the function body. Each elided reference parameter first gets a distinct input lifetime; if there is exactly one input lifetime, elided output lifetimes use it; if a method has multiple input lifetimes, the lifetime of &self or &mut self is assigned to elided outputs.

Consequently, fn first(text: &str) -> &str can omit annotations, while fn choose(x: &str, y: &str) -> &str cannot use elision to decide the output’s origin. The output of fn name(&self, fallback: &str) -> &str defaults to borrowing from self; the rule does not change automatically if the implementation returns fallback.

The placeholder lifetime '_ asks the compiler to infer a lifetime at that position, as in View<'_>. It is useful in type paths to make the lifetime parameter visible, but it neither creates a relationship nor bypasses checking. When elision works, repeating 'a solely to look explicit usually adds noise.

Borrowed fields carry constraints into types

A struct that stores a reference must carry a lifetime in its type, as in struct View<'a> { text: &'a str }. This says no use of a View<'a> may cross the valid region of text. The constraint follows that type into return values, containers, and other struct fields.

impl<'a> View<'a> means the implementation applies to any 'a. A method returning -> &'a str can inherit the field source’s lifetime directly; with -> &str, receiver elision usually limits the result to the current &self borrow. Both signatures may compile, but they expose different public contracts.

Independent borrowed fields do not need to share one parameter. Giving source data and a temporary buffer the same 'a makes the entire struct obey the shorter input. Using 'source and 'buffer separately, or owning the temporary buffer, is usually more precise.

'static appears in two common positions

The static lifetime is written 'static. &'static str says the referent remains valid for the whole program; string literals and static items are typical sources. A reference to a local String does not become static because an annotation is added.

The type bound T: 'static means something different: T cannot contain a borrow shorter than the program. An owned String satisfies this bound but can still be destroyed at an ordinary scope boundary. The bound describes how long it could safely be retained, not how long it will actually remain.

Threads and stored callbacks often require T: 'static because the caller cannot guarantee when the task ends. The right response is usually to move owned data or an appropriate shared-ownership pointer. A move closure that captures a short-lived reference still does not satisfy 'static.

Examples

These four examples progress through last use, a common region, a precise source, and a higher-ranked bound. Every output below came from compiling and running the corresponding file with the local Rust compiler.

Last use ends a borrow

The last use of first occurs before push(), so the shared borrow can end first. The variable remains in the same block, but it does not prevent a later mutable borrow of the vector.

Moving println!("first: {first}") after push() makes the code fail. push() may reallocate the vector buffer, while the later use would require the old element reference to remain valid. The last use, not the distance from declaration to closing brace, determines the conflict.

Choose a common region for two sources

choose() may return either input, so all three positions share 'a. The inner string is valid only within the inner block, and the result is used only there.

fn choose<'a>(primary: &'a str, fallback: &'a str, healthy: bool) -> &'a str {
    if healthy {
        primary
    } else {
        fallback
    }
}

fn main() {
    let stable = String::from("stable");

    {
        let temporary = String::from("temporary");
        let selected = choose(&stable, &temporary, true);
        println!("selected: {selected}");
    }

    println!("owner remains: {stable}");
}

selected: stable
owner remains: stable

Although the runtime branch selects stable, the public signature still permits the implementation to return temporary. The compiler does not create a conditional lifetime for the result from the boolean value, so the caller must use selected where both inputs remain valid.

Separate the data source from an auxiliary parameter

parse_field() returns a struct borrowed from record, while delimiter only participates in the search. The result remains usable after the delimiter is destroyed at the end of the inner block because the return type is not tied to it.

struct Field<'a> {
    name: &'a str,
    value: &'a str,
}

fn parse_field<'record>(record: &'record str, delimiter: &str) -> Option<Field<'record>> {
    let (name, value) = record.split_once(delimiter)?;
    Some(Field { name, value })
}

fn main() {
    let record = String::from("region=eu-west");
    let field;

    {
        let delimiter = String::from("=");
        field = parse_field(&record, &delimiter).expect("valid field");
    }

    println!("{} -> {}", field.name, field.value);
}

region -> eu-west

If delimiter also used 'record, callers would have to keep a temporary delimiter alive until the last use of field. Safety does not require that constraint; it is over-constraining. The precise lifetime lets the auxiliary input end sooner.

Require a function to accept any borrow

print_views() borrows a different String on each loop iteration. The for<'a> bound requires view to preserve the same input-output relationship for every suitable input lifetime.

fn first_word(input: &str) -> &str {
    input.split_whitespace().next().unwrap_or("")
}

fn print_views<F>(records: &[String], view: F)
where
    F: for<'a> Fn(&'a str) -> &'a str,
{
    for record in records {
        println!("{}", view(record));
    }
}

fn main() {
    let records = vec![
        String::from("alpha ready"),
        String::from("beta waiting"),
    ];

    print_views(&records, first_word);
}

alpha
beta

An ordinary function parameter can get this input-output relationship through elision, but the generic bound needs to express that each inner call chooses its lifetime. The higher-ranked bound does not lengthen a reference; it prevents the callable from working for only one lifetime fixed by the outer context.

Pitfalls

Treating an annotation as a lifetime extension

Fix: Return an owned value when the function creates the data. When returning a reference, trace its source to an input, struct field, string literal, or static item. Do not use more annotations to hide the lack of a valid source.

Giving independent inputs one name

Fix: Mark the source of every possible return path. Give auxiliary references independent or elided lifetimes; connect multiple inputs to the output only when the implementation may return any of them.

Equating move with 'static

Fix: Inspect whether each captured value contains a borrow. When the task must be independent, move a String, Vec<T>, Arc<T>, or another value that fits the ownership boundary, then review shared mutation and thread safety separately.

Guessing a borrow’s end with extra blocks

Fix: Read the compiler diagnostic as a timeline of borrow creation, conflict, and later use. Remove or finish the last use earlier, or reorganize ownership. Add a block only when it expresses a real resource or variable boundary.

Leaking data to bypass a 'static error

Fix: Prefer moving owned data into the task or using Arc for shared ownership. Consider an intentional leak only when the data is designed to remain for the rest of the process and growth has a clear bound.

Further reading

• The Rust Programming Language - Validating References with Lifetimes
• The Rust Reference - Lifetime elision
• The Rust Reference - Trait and lifetime bounds
• The Rustonomicon - Subtyping and Variance
• The Rustonomicon - Higher-Rank Trait Bounds