Lifetime Analysis

The usual complaint is reasonable: the compiler can see the whole function, so why must anything be written down? The answer is that it cannot see the whole *program*, and it has deliberately chosen not to try. Borrow checking is modular — each function is checked against the signatures of the functions it calls, never against their bodies. That is what makes the check scale, what makes it incremental, and what makes it work across a library boundary where the body may not be available at all.

So consider fn pick(a: &str, b: &str) -> &str. To check a caller, the checker must know how long the returned reference is valid. Is it tied to a, to b, or to both? The body knows. The signature does not, and the caller is only allowed to look at the signature. The annotation supplies exactly the missing fact and nothing more: fn pick<'a>(a: &'a str, b: &'a str) -> &'a str says the result is valid for as long as both inputs are.

This is the same argument as [[separate-compilation]] and [[interface-files]] make everywhere else in the domain. A signature is a contract precisely so that consumers need not read implementations, and any fact a consumer needs must be in the contract. Lifetimes are simply a fact that C-family signatures never carried and that a borrow checker requires.

The elision rules exist because most signatures have only one plausible answer. One input reference and one output reference: the output must come from the input. A method with &self: the output almost always comes from self. The compiler applies these rules and only asks when the answer is genuinely ambiguous, which is why most Rust code has no explicit lifetimes and the ones you do write are usually at the interesting boundaries.

The word "lifetime" is misleading and has caused a great deal of confusion. A lifetime in this system is not a duration, not a scope, and not the lifetime of the referent. It is a region: a set of points in the control-flow graph over which the reference must be usable. That reframing is the whole content of non-lexical lifetimes, and everything that used to be surprising becomes obvious once it lands.

Under the original, lexical rule, a borrow lasted from its creation to the end of the enclosing block, because a scope was the only thing the checker knew how to talk about. That rejected an enormous number of obviously fine programs — take a reference, use it, then mutate the collection three lines later, still inside the same block, with the reference dead. The reference is not used again; the human sees no conflict; the checker saw a borrow that was still lexically in scope.

Non-lexical lifetimes replaced scopes with liveness over the CFG. A borrow's region is now the set of points where the reference may still be used — computed by the same liveness analysis described in [[liveness-analysis]], applied to references. Once the last use is passed, the region ends, and a conflicting borrow after that point is fine.

This is why the rules suddenly matched intuition: programmers were reasoning about last use all along, and the compiler had been reasoning about closing braces. Aligning the two was not a relaxation of the safety rule — the exclusivity invariant is unchanged — it was a more precise computation of when the rule applies.

NLL removed most of the false positives but not all of them, and the remaining cases are instructive because they show exactly where the analysis is weaker than the reasoning it approximates.

The famous one is the conditional-return borrow: a function that looks up a key, returns the borrow if it is present, and otherwise inserts and returns a borrow of the new entry. Every path is fine. The current checker rejects it, because the borrow taken for the lookup is considered live along the path where the lookup failed — the analysis is location-sensitive but not path-sensitive enough to see that the failing path cannot use it. This is precisely the class Polonius is designed to accept.

The second is self-referential structures: a struct holding both a buffer and a reference into that buffer. There is no lifetime that expresses "a region tied to another field of the same struct", because the struct can be moved and the reference would not follow. This is not a weakness of the analysis; it is a genuine unsoundness the rules correctly forbid, and the workaround — index instead of reference, or pin the value — is real work.

The third is that regions are inferred within a body and declared at boundaries, so a signature can be too weak even when the body is fine. A function returning a reference tied to one argument, called in a context needing it tied to another, fails at the signature. Widening the signature is the fix, and it is a public API change.

The general shape of these is worth stating: a borrow checker is a static approximation of a dynamic property, so it has false positives and no false negatives. Every rejection of a correct program is a place the approximation was coarser than the truth, and the history of the feature is a sequence of making it less coarse without ever making it unsound.

Three clarifications remove most remaining confusion, and they are all corollaries of "a lifetime is a region, not a duration".

A lifetime annotation does not change how long anything lives. It is a constraint the checker must satisfy, not an instruction it carries out. Writing a longer lifetime does not extend anything; it merely makes a claim that must be justified elsewhere, and if it cannot be, the error moves rather than disappearing.

A lifetime is not the lifetime of the value. It is a property of the *reference*, describing the region over which the reference must be valid, which is generally shorter than the value's existence. Reading 'a as "how long the data lives" makes the elision rules and the variance rules incomprehensible.

And lifetimes are erased before code generation. They exist for the borrow checker and are gone by the time MIR is lowered — there is no runtime representation, no cost, and nothing a debugger can show you. This puts them in the same category as everything in [[type-erasure]]: a compile-time fact with no runtime residue, which is why the entire mechanism is free at run time and expensive only at build time and in the effort of writing it.