Every lifetime you'll meet

Formal. A lifetime is a region of the program during which a reference must be valid. Names like 'a in a signature state relationships between the regions of inputs and outputs, and the compiler checks every call against them. They never change when any value is dropped: a value still lives exactly until the end of its owner's scope (or until it is moved or consumed), and a reference that would outlive it is rejected (E0597, E0515) no matter how it is annotated.

In plain English. A lifetime label is a promise written on a reference, "this stays good at least as long as that," and the compiler checks the promise. Writing the label can't make anything last longer, the way writing a later date on a carton doesn't keep the milk fresh.

Example. fn shorter<'a>(x: &'a str, y: &'a str) -> &'a str says the result is valid only while both arguments are. Calling it with a string that is dropped at the end of an inner block and then using the result after that block is error E0597.

Why this rule exists. Annotations let the compiler check each function on its own, from its signature, without looking into the bodies of the functions it calls.

Formal. Every reference must remain within the lifetime of its referent; code in which a reference could be used after its referent is dropped does not compile (E0597, "borrowed value does not live long enough"). A function can't return a reference to one of its own local variables.

In plain English. You can't hold on to a pointer to something that has already been cleaned up. Rust checks this before the program runs.

Example. let r; { let x = 5; r = &x; } println!("{r}"); is E0597: x is dropped at the inner closing brace while r still refers to it.

Why this rule exists. Using memory after it has been freed is one of the most dangerous bugs in systems code. Rust makes it a compile error.

Formal. The compiler considers a reference alive from where it is created to the last place it is used, not to the end of the enclosing block. A conflicting borrow that starts after that last use is allowed.

In plain English. Once you've finished using a reference, Rust treats it as returned, even if its name is still in scope.

Example. let r = &v; println!("{r:?}"); v.push(4); compiles: r's last use is the println!, so the mutable borrow for push doesn't overlap it. Moving the println! after push makes it E0502.

Why this rule exists. Tying borrows to actual use rather than to braces lets many correct programs compile without contortions, while still rejecting every real overlap.

Formal. In a function signature, a reference type written without a lifetime gets one by three rules, which look only at the signature: (1) each elided lifetime in the parameters becomes its own distinct lifetime parameter; (2) if there is exactly one input lifetime, it is assigned to every elided output lifetime; (3) if there are several input lifetimes but one of them is &self or &mut self, self's lifetime is assigned to every elided output lifetime. If an output lifetime is still unassigned, the signature is error E0106 and must be annotated.

In plain English. Most of the time Rust can guess how a returned reference is tied to the inputs: one reference in, so the result must come from it; a method, so the result probably comes from the object. When there's more than one possibility, you have to say which.

Example. fn first_word(s: &str) -> &str means fn first_word<'a>(s: &'a str) -> &'a str (rule 2). fn pick(x: &str, y: &str) -> &str is E0106: two inputs, no self.

Why this rule exists. Writing lifetimes out every time is noise for the common cases, which the rules cover, while ambiguous cases still have to be spelled out, so no guess is ever silently wrong.