Lifetime Elision Rules

After Lifetime Annotations, you might expect every Rust function that touches references to carry <'a>. In practice most do not, because rustc fills in the missing parameters itself using a fixed, published algorithm called elision. It is not machine learning and it is not inference across function bodies — it is three rules applied in order to the signature alone.

1. Every elided input reference gets its own fresh lifetime parameter. fn f(x: &str, y: &str) becomes fn f<'a, 'b>(x: &'a str, y: &'b str) — two independent parameters, not one.
2. If exactly one lifetime appears in the parameter list — elided or not — it is assigned to every elided output lifetime. The single-input case is so common that this rule alone justifies the feature.
3. If there are multiple input lifetimes and one is the receiver (self, &self, &mut self), the receiver's lifetime is assigned to every elided output. Methods have a natural "primary" argument, so the compiler bets on it.

If the output is a reference and none of these rules produces a unique answer, no guessing happens: you get error[E0106]: missing lifetime specifier exactly as in the previous topic. Here is the algorithm applied to real signatures:

That last row deserves emphasis, because it is the mistake people make when "fixing" E0106: adding an explicit lifetime to an input does not rescue an elided output. The rule counts every lifetime in the parameter list, elided or not. fn f<'a>(x: &'a str, y: &str) -> &str still has two candidate inputs, so the only repair is to annotate the output too: -> &'a str.
| fn f(&self, x: &str) -> &str | output borrows from self | 1 + 3 |

Two details the rules quietly assume. First, the output must be a bare &T; -> Option<&str> and -> (&str, &str) are still elided, because elision looks through those types to the references inside. Second, rule 1 is not decoration: giving each input its own parameter is what lets a function compare or reborrow two arguments independently before rule 2 or 3 picks an output.

Interviewers ask for the rules verbatim surprisingly often. Recite them in order — fresh inputs first, single-input shortcut second, receiver third — and you have answered the question; then apply them to fn longest(x: &str, y: &str) -> &str to show why the shortcut fails when two candidates exist and no receiver is present.

Rule 3 makes methods compile without annotations, and it is also the source of the most common elision surprise: the output binds to self, not to the parameter you returned.

struct Session { id: u64 }

impl Session {
    fn id_str(&self) -> &str {          // elided: fn id_str<'a>(&'a self) -> &'a str
        &self.buf
    }

    fn echo(&self, input: &str) -> &str { // output tied to &self, NOT to input
        input                              // error: returns a value referencing `input`
    }
}

echo looks harmless — you return the parameter, so surely the result borrows input? Elision says otherwise: there are two input lifetimes, one is &self, so rule 3 assigns the output 'a from the receiver. The body returns data with 'b (the parameter's span), the two do not match, and the compiler rejects it. The fix is an explicit annotation that overrides the default:

fn echo<'a>(&self, input: &'a str) -> &'a str { input }

This is the shape interviewers use to test whether you actually understand elision rather than memorizing that "methods don't need annotations". The takeaway is precise: methods don't need annotations when the result borrows from the receiver. The moment a method returns a borrow of a parameter, or ties two independent references together, the default is wrong and you must say so.

&mut self behaves the same and adds the familiar mutability constraint. In fn push(&mut self, s: &str) -> &str, the output is &'a str where 'a comes from the exclusive borrow of self; while the result is held, no other method may touch the session. Returning s instead fails exactly like echo above.

Here is the pattern set worth memorizing, because it covers nearly every method signature you will write:

The mental test is one sentence long: look at what the body returns — if it comes from self, elision's default already matches reality; if it comes from a parameter, override the default. Returning self.buf.as_str() from id_str is legal precisely because the elided output lifetime is self's, so the borrow ends when the session borrow ends and not a moment later.

One more edge worth knowing: associated functions without a receiver fall back to rule 2, and if they take several references they fall straight into E0106.

impl Session {
    fn parse(text: &str, fallback: &str) -> &str { // two inputs, no self -> E0106
        if text.is_empty() { fallback } else { text }
    }
}

Adding <'a>(text: &'a str, fallback: &'a str) -> &'a str fixes it — same function, same body, only the stated relationship changed.

A property that surprises people who expect "compiler inference" is that elision is a single, deterministic pass over one signature. Rules 1–3 run, produce a result or an error, and are never invoked again on that signature. There is no second chance where the compiler notices your annotation was odd and adjusts it, and no propagation of the decision into other functions. What you wrote — or what elision produced — is exactly what every caller is checked against.

That has three practical consequences.

First, mixing explicit and elided lifetimes is legal, but rule 2 counts every lifetime in the parameter list — elided or not. So fn f<'a>(x: &'a str, y: &str) -> &str still fails with E0106: y gets a fresh 'b, there are now two candidate inputs, and no rule picks an output. The repair is explicit on both ends: -> &'a str (or two named parameters with the output naming one). By contrast, fn f<'a>(x: &'a str) -> &str compiles fine — a single parameter lifetime is assigned to the output even when you wrote that lifetime out yourself. And an explicitly written output lifetime (-> &'a str, -> &'static str) switches the elision machinery off for that position completely; the compiler checks it against your annotation rather than any rule. Whenever a signature mixes styles, write the output lifetime too, so no reader has to replay the algorithm to know what was inferred.

Second, '_ says "elide here, but I am spelling the position out". It is identical in effect to omitting the lifetime, but it documents intent and is required in a few positions, such as impl Trait for Struct<'_> and tuple-struct constructors where a bare &T would be rejected:

struct Slice<'a>(&'a [u8]);
let s = Slice(&[1, 2, 3]);        // error: missing lifetime specifier
let s = Slice(&'_ [1, 2, 3]);     // ok: '_ elides in expression position
let s: Slice<'_> = Slice(&[1, 2]); // ok: '_ in type position

Third — and this is the firm line — struct fields are never elided. Elision applies to function and method signatures only. struct Reader { data: &str } is a hard error: a stored borrow outlives any single call, so the definition must name how long it lives with a parameter like struct Reader<'a> { data: &'a str }. The same holds for enum variants, trait objects written inside type definitions, and impl headers — all of them require an explicit parameter, which is exactly the subject of Holding References in Structs.

A fourth place the same machinery runs, and a favorite of interview questions on higher-ranked types: function pointer signatures. Writing let f: fn(&str) -> &str = first_word; elides lifetimes in exactly the same way, and the resolved form is for<'a> fn(&'a str) -> &'a str — a higher-ranked pointer that must work for every lifetime, not just one chosen earlier. Function items coerce to that pointer type when their elided signatures match, which is how you pass functions as arguments without generics:

fn apply(f: fn(&str) -> &str, s: &str) -> &str { f(s) }
fn shout(s: &str) -> &str { s }
let out = apply(shout, "hello");

When closures appear in the same position, rustc often reports the elided form as for<'a> fn(&'a str) -> &'a str in its error notes — reading that notation back as "one lifetime, chosen fresh at each call" is the skill this topic is building.

The complete boundary, then: inside one signature, three rules, one pass, done. Everywhere a borrow is stored in a type, an explicit lifetime parameter, no exceptions. When a signature is short and single-input, let elision work; when it holds two references, a receiver you do not return, or a stored borrow, write the relationship down.