Lifetime Annotations

You write the smallest function that seems to need no explanation:

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

and the compiler answers with an error you will see many times in interviews and in real code:

error[E0106]: missing lifetime specifier
 --> src/lib.rs:1:33
  |
1 | fn longest(x: &str, y: &str) -> &str {
  |               ----     ----     ^ expected named lifetime parameter
  |

Nothing in the body is wrong: both x and y are &str, and returning either one is perfectly legal at run time. What is missing is a relationship. The return value is a reference, but the signature never says where it borrows from. The bare type &str in return position could, in principle, be a borrow of x, a borrow of y, or a reference to a string literal that lives forever. The compiler refuses to guess, because each guess permits different caller code.

This is where lifetime syntax enters. A lifetime is the span during which a reference is valid: from where the reference is created to its last use. Borrow checking already reasons about those spans implicitly for local variables — you met that machinery in Refactoring Borrow Checker Errors. Named annotations do not create lifetimes or make anything live longer. They name the relationship between the lifetimes of the references in a signature so the compiler can check the claim.

The corrected signature is:

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

Read it aloud with precision: for some lifetime 'a, both inputs are borrowed for at least 'a, and the output is borrowed for exactly 'a. The angle brackets after the function name introduce 'a as a parameter of the function — a name the caller and the body share.

Here are the three signatures a programmer might reach for, and what each one promises:

Modern rustc words the diagnostic as expected lifetime parameter with a help: consider introducing a named lifetime parameter note that even suggests the exact edit. Take the suggestion, then check it against the table — the suggested annotation is only correct if the body actually returns data from the annotated inputs.

Note where the error appeared: on the return type, not on the parameters. Input references without annotations are fine in this position; it is the ambiguous output that triggers E0106. That asymmetry is not random — it is the seed of the elision rules you will read in Lifetime Elision Rules, which exist precisely to spare you writing <'a> on signatures like this one. It also explains why fn first_word(&self) -> &str compiles with no annotation at all: when a receiver is present, there is a default answer for the output, so no diagnostic fires. Learn to read the error's caret placement: it points at the reference the compiler cannot connect to any input.

A lifetime parameter is not a duration you choose. You cannot write <'a> and decide it means "long enough for my loop". The annotation is a relation between references, and the actual value of 'a is chosen at each call site by the caller — the compiler unifies it with the lifetimes of the arguments the caller passes.

Consider what happens at a call site:

let name;
let result;
{
    let short = String::from("rust");
    name = String::from("ownership");
    result = longest(short.as_str(), name.as_str());
}   // short dropped here
println!("{}", result);

short dies at the end of the inner block while name lives on. The signature promises the result is borrowed for 'a, so 'a can be no longer than the shorter of the two input borrows — here, the borrow of short. Since result is used after short is dropped, the borrow check rejects the program: borrowed value does not live long enough. The annotation did not lie; you asked for a value that outlived its guarantee.

This is the practical reading of the "long enough" rule: the output borrows at least as long as the shorter input, and never longer. In the common case where both inputs live in the same scope, 'a collapses to that scope and everything compiles without drama. The annotation only becomes visible when the two borrows have different ends.

Three details interviewers probe:

• One parameter can serve many references. x: &'a str, y: &'a str forces both inputs to share one lifetime. If you instead write <'a, 'b> with x: &'a str, y: &'b str, the return type must pick one — -> &'a str says the result follows x's borrow, and the compiler then requires y's borrow to be irrelevant to the result.
• Structs, impls, and methods take the same syntax. impl<'a> Reader<'a> { ... } means "an impl for the reader borrowing for 'a". The angle bracket is the same token everywhere; only where it is declared changes.
• The name is arbitrary. 'a, 'x, 'out, 'input all compile. Descriptive names such as 'input make signatures self-documenting, and 'static (covered in The static Lifetime) is the one name with a fixed meaning.

Bounds can attach too: <'a, 'b: 'a> reads "'b outlives 'a", which you will use when a struct holds two references of different spans.

The same parameter appears wherever a borrow crosses an API boundary:

struct Pair<'a> { left: &'a str, right: &'a str }

impl<'a> Pair<'a> {
    fn longer(&self) -> &'a str {
        if self.left.len() >= self.right.len() { self.left } else { self.right }
    }
}

fn build<'a>(s: &'a str) -> Pair<'a> {
    Pair { left: s, right: "literal" }   // &'static str coerces down to any 'a
}

Notice build: the literal borrow is 'static, and a 'static reference satisfies any 'a the caller picks, so one parameter covers both fields. Mixed spans only become trouble when the output could follow the shorter-lived side — then you either unify everything under one 'a or split into 'a and 'b and commit to one of them.

A useful drill for interviews: for any annotated signature, ask who enforces each half? The caller enforces the input claim by handing over references that really live for 'a; the body enforces the output claim by producing a reference that lives that long. An annotation that satisfies neither side is a wish, and the compiler reports which party failed: a body error names a value that does not live long enough, while a call-site error names an argument whose borrow ends too soon.

The single most common misconception about lifetime annotations is that they affect the running program. They do not. Lifetimes exist only during compilation; rustc erases them before code generation, and a function with three lifetime parameters produces exactly the same machine code as one with none. There is no run-time bookkeeping, no reference counting, no extra register. The annotation's entire effect is on which programs compile.

That gives you a clean way to reason about errors. If you write an annotation that overstates reality, you never get a run-time failure — you get a compile error, and the wording tells you which claim failed:

error: lifetime may not live long enough
 --> src/lib.rs:4:35
  |
4 |     let outer: &'a str = inner.as_str();
  |                           ^^^^^^^^^^^^^^ borrowed value does not live long enough

The two directions of failure look like this:

// Understated: you claimed the output only borrows for 'a,
// but the body returns something that dies sooner.
fn too_short<'a>(x: &'a str, v: &String) -> &'a str {
    v.as_str()   // error: `v` does not live long enough
}

// Overstated: you required both inputs to share 'a, but the
// caller passes a short-lived borrow and a 'static one.
fn requires_unified<'a>(x: &'a str, y: &'a str) -> &'a str { x }
let leaked: &'static str = "literal";
{
    let owned = String::from("temp");
    requires_unified(leaked, &owned); // compiles: 'a shrinks to `owned`'s span
}                                     // then `leaked` is still fine afterwards

The second example shows the key asymmetry: widening a lifetime in a parameter is always safe because the caller simply chooses a smaller 'a. Trouble only starts when the output promises more than an input can deliver.

A compact triage table for the diagnostics you will actually see:

Each message names the exact reference at fault, which is why reading the whole diagnostic — not just the first line — is faster than guessing.

Two habits keep you out of trouble. First, annotate only what the compiler cannot infer — if you must add <'a> to make the signature unambiguous, do it and stop; adding redundant parameters elsewhere just adds names to keep straight. Second, when an error mentions 'a, do not respond by sprinkling 'static to silence it. Promising 'static where you mean "a local borrow" pushes the problem onto every caller and often converts a small fix into a design change.

In code review and on a whiteboard, the expected answer to "what does <'a> do?" is one sentence: it lets the function state how the lifetimes of its reference arguments and its return value relate, so the borrow checker can verify the result is never used after the data it points at is gone. Everything above is the elaboration of that sentence.