When the compiler can't guess the lease
You write a function that takes two strings and returns the longer one. The logic is straightforward. You compare lengths and return a reference to the winner. You hit compile, and Rust throws E0106: missing lifetime specifier. The error points to the return type. You stare at the signature. The return value clearly comes from one of the inputs. Why does Rust need more information?
Rust tracks how long references are valid to prevent dangling pointers. When a function returns a reference, the compiler must verify that the data behind that reference will stay alive for as long as the caller uses it. The compiler tries to infer this connection automatically using lifetime elision rules. When those rules don't apply, the compiler stops and asks you to specify the relationship explicitly. The "missing lifetime specifier" error means the compiler cannot determine which input lifetime bounds the output lifetime. You have to draw the line.
How lifetime elision works
Rust includes a set of elision rules that let you omit lifetime annotations in common cases. The compiler applies these rules in order. If none of them match, you get E0106.
The first rule handles the simplest case. If a function has exactly one input reference, the compiler assigns that input's lifetime to all output references. This covers functions like first_word that take a single string slice and return a slice of it.
/// Returns a slice of the string up to the first space.
/// Elision applies here: one input reference, so the output gets the same lifetime.
fn first_word(s: &str) -> &str {
let bytes = s.as_bytes();
for (i, &item) in bytes.iter().enumerate() {
if item == b' ' {
return &s[0..i];
}
}
&s[..]
}
The second rule handles methods. If a function has multiple input references but one of them is &self or &mut self, the compiler assigns the lifetime of self to all output references. This makes method signatures clean. You rarely need explicit lifetimes in impl blocks unless the return value depends on an argument rather than self.
struct Rectangle {
width: u32,
height: u32,
}
impl Rectangle {
/// Returns the larger dimension.
/// Elision applies: `&self` is present, so the output lifetime ties to `self`.
fn largest_dimension(&self) -> &u32 {
if self.width > self.height {
&self.width
} else {
&self.height
}
}
}
The third rule is the fallback. If there are multiple input references and none of them is &self, elision fails. The compiler cannot guess which input the output is tied to. It refuses to assume. You must add explicit lifetime parameters.
Fixing the error with explicit lifetimes
When elision fails, you introduce a lifetime parameter to link the inputs and outputs. The syntax mirrors generic type parameters. You add <'a> after the function name, then attach 'a to the references that share the same lifetime.
Consider a function that returns the longer of two strings. There are two inputs. The output could be either. The compiler needs to know that the output lives at least as long as the shorter of the two inputs. By giving both inputs and the output the same lifetime name, you enforce that constraint.
/// Returns the longer of two string slices.
/// Both inputs share lifetime `'a`, and the output also has `'a`.
/// This ensures the return value is valid as long as both inputs are valid.
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
if x.len() > y.len() {
x
} else {
y
}
}
The lifetime name 'a is arbitrary. It acts as a label. The compiler checks that all references labeled 'a satisfy the same duration constraints. The name itself has no meaning to the compiler; it only groups references together. The convention is to use 'a for the first lifetime, 'b for a second independent lifetime, and so on. If you have a lifetime that represents a specific concept, like a database connection or a file handle, you can use a descriptive name like 'conn to improve readability for humans.
Adding the lifetime parameter changes the function's contract. You are telling the compiler: "The output reference is valid for lifetime 'a. The input references are also valid for lifetime 'a. Therefore, the output cannot outlive the inputs." The compiler uses this information to reject code that would create a dangling reference.
What happens at compile time
When you annotate lifetimes, the compiler performs a unification check. It collects all the lifetime constraints from the function signature and the call site. If the caller tries to use the result longer than the inputs allow, the compiler rejects the code with E0597: borrowed value does not live long enough.
The lifetime parameter does not extend the life of the data. It only describes the relationship. You cannot use lifetimes to make a local variable live longer. If you try to return a reference to a local variable, the compiler will reject you with E0515: cannot return reference to local variable, regardless of how many lifetime annotations you add. Lifetimes are a description of reality, not a magic wand.
/// This function fails to compile.
/// The lifetime annotation cannot save a reference to a local variable.
fn dangerous<'a>() -> &'a str {
let s = String::from("hello");
&s // Error E0515: `s` is dropped at the end of the function.
}
The compiler enforces that the data behind a reference must outlive the reference itself. Lifetime annotations help the compiler verify this rule across function boundaries. Without them, the compiler would have to guess, and guessing leads to unsafe code.
Pitfalls and common mistakes
The most common mistake is over-constraining. If you force multiple inputs to share a lifetime when only one is relevant to the output, you make the function harder to use. The caller must ensure all inputs live as long as the result, even if some inputs are irrelevant. This can cause unnecessary borrow checker errors at the call site.
/// This signature is too restrictive.
/// The output only depends on `x`, but the signature forces `y` to live as long as the result.
fn longest_strict<'a>(x: &'a str, y: &'a str) -> &'a str {
x
}
In this case, the function always returns x. The lifetime of y does not matter. A better signature uses separate lifetimes for inputs that are independent.
/// This signature is more flexible.
/// The output lifetime `'a` is tied only to `x`.
/// `y` can have any lifetime `'b`, as long as it lives long enough for the function body.
fn longest_flexible<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
x
}
Another pitfall is ignoring the error message. E0106 often includes a note suggesting the fix. The compiler might suggest adding <'a> or using 'static. Reading the suggestion can save time. If the suggestion doesn't make sense, it usually means the function logic is flawed. For example, if the compiler suggests 'static but you're returning a reference to heap data, the suggestion is a hint that you might need to return an owned type instead.
Decision matrix
Use explicit lifetime annotations when a function returns a reference and elision rules do not apply. Use explicit lifetime annotations when a function takes multiple references and returns a reference derived from one of them, and you need to specify which input bounds the output. Use separate lifetime parameters when inputs are independent and only one affects the output lifetime. Rely on lifetime elision when a function has a single input reference and returns a reference; the compiler automatically links them. Rely on lifetime elision when a method returns a reference and the output is derived from self; the compiler ties the output to self's lifetime. Use the 'static lifetime when the data lives for the entire duration of the program, such as string literals or static variables. Return an owned type like String when the data must outlive the inputs or when the function creates new data.
Lifetimes describe reality. You can't annotate your way out of a dangling reference.