In Part 3, we covered what lifetime annotations mean and how to write them. But if you look at most Rust code in the wild, you rarely see explicit lifetime annotations outside of struct definitions and a handful of functions. Yet the code compiles and is memory safe.
That is lifetime elision at work. The compiler fills in lifetime annotations automatically in cases where the relationship is unambiguous. Understanding the elision rules tells you two things: when you can omit annotations safely, and why the compiler asks for them when it does.
What Lifetime Elision Is
Lifetime elision is a set of deterministic rules the Rust compiler applies to function signatures and method definitions when you leave out lifetime annotations. If the rules uniquely determine the lifetimes, the compiler fills them in silently. If they do not, the compiler asks you to be explicit.
The rules were introduced because the same patterns appeared so frequently in idiomatic Rust that requiring annotations for them was pure boilerplate. They are not magic – they are documented, predictable, and finite.
The Three Elision Rules
There are exactly three rules. They are applied in order. If after applying all three the lifetimes are still not fully determined, the compiler emits an error.
flowchart TD
A[Function signature with references] --> B[Rule 1: Each input reference\ngets its own lifetime parameter]
B --> C[Rule 2: If exactly one input lifetime,\nassign it to all output lifetimes]
C --> D[Rule 3: If one input is &self or &mut self,\nassign its lifetime to all output lifetimes]
D --> E{All output lifetimes assigned?}
E -->|Yes| F[Compiles - no annotation needed]
E -->|No| G[Compiler error - explicit annotation required]
style F fill:#27ae60,color:#fff
style G fill:#c0392b,color:#fff
Rule 1: Each Input Reference Gets Its Own Lifetime
Every reference parameter in a function signature is assigned a distinct lifetime parameter. This happens automatically before the other rules are applied.
// What you write:
fn foo(x: &i32, y: &str) -> usize { 0 }
// What the compiler sees after Rule 1:
fn foo<'a, 'b>(x: &'a i32, y: &'b str) -> usize { 0 }Note that the output has no lifetime here – that is fine because it does not involve a reference. Rule 1 only affects input lifetimes.
Rule 2: Single Input Lifetime Flows to All Outputs
If after Rule 1 there is exactly one input lifetime parameter, that lifetime is assigned to every output reference.
// What you write:
fn first_word(s: &str) -> &str {
s.split_whitespace().next().unwrap_or("")
}
// After Rule 1: one input lifetime 'a
// After Rule 2: 'a assigned to output
fn first_word<'a>(s: &'a str) -> &'a str {
s.split_whitespace().next().unwrap_or("")
}
// Compiles with no annotation neededThis is the most common case. A function takes one reference and returns a reference derived from it. Rule 2 handles this entirely.
Rule 3: Methods With Self Get Self’s Lifetime on Output
If one of the input parameters is &self or &mut self, its lifetime is assigned to all output references. This is why method return values almost never need lifetime annotations.
struct Config {
host: String,
port: u16,
}
impl Config {
// What you write:
fn host(&self) -> &str {
&self.host
}
// What the compiler sees:
fn host<'a>(&'a self) -> &'a str {
&self.host
}
// Rule 3 applies: self's lifetime goes to the output
}This is why you almost never write lifetime annotations on getter methods. Rule 3 covers the overwhelmingly common pattern of returning a reference to data inside self.
Walking Through Examples Step by Step
Let us trace through the rules on a few real-world signatures to build the habit of reading elision automatically.
Example 1: Compiles Without Annotations
fn trim_prefix(s: &str, prefix: &str) -> &str {
s.strip_prefix(prefix).unwrap_or(s)
}Apply Rule 1: two input references get two lifetimes – 'a for s, 'b for prefix. Apply Rule 2: two input lifetimes, so Rule 2 does not apply. Apply Rule 3: no self, so Rule 3 does not apply. Output lifetime is still unresolved. The compiler cannot determine which input the output comes from. This requires an explicit annotation.
// The output comes from s, not prefix - we must say so
fn trim_prefix<'a>(s: &'a str, prefix: &str) -> &'a str {
s.strip_prefix(prefix).unwrap_or(s)
}Example 2: Method That Returns a Reference – No Annotation Needed
struct Cache {
entries: Vec,
}
impl Cache {
fn get(&self, index: usize) -> Option<&str> {
self.entries.get(index).map(String::as_str)
}
}
// Rule 1: &self gets 'a, index is not a reference - no lifetime
// Rule 3: self has a lifetime - assign to output
// Resolved: fn get<'a>(&'a self, index: usize) -> Option<&'a str> Example 3: Method With Extra Reference Parameter
impl Cache {
// Does this need an annotation?
fn find(&self, query: &str) -> Option<&str> {
self.entries.iter()
.find(|e| e.contains(query))
.map(String::as_str)
}
}
// Rule 1: &self gets 'a, &str gets 'b
// Rule 3: self has a lifetime 'a - assign to output
// Resolved: fn find<'a, 'b>(&'a self, query: &'b str) -> Option<&'a str>
// The output comes from self, not query - Rule 3 captures this correctlyThis one is interesting. There are two input references, but Rule 3 still applies because one of them is &self. The output is tied to self‘s lifetime, which is correct – the return value comes from self.entries, not from query.
When Elision Gets It Wrong
The elision rules are correct for the common cases, but sometimes they infer a lifetime that does not match what you actually intend. The compiler will not always catch this – if the inferred lifetimes are valid, the code compiles even if the constraints are more restrictive than necessary.
struct Parser<'a> {
input: &'a str,
position: usize,
}
impl<'a> Parser<'a> {
// What happens when a method has two reference outputs?
fn peek_and_advance(&mut self) -> (&str, &str) {
let current = &self.input[self.position..self.position + 1];
self.position += 1;
let next = &self.input[self.position..self.position + 1];
(current, next)
}
}
// Both outputs are tied to self's lifetime via Rule 3
// This is correct here - both come from self.inputNow consider a case where you might want the output tied to a different input:
impl<'a> Parser<'a> {
// You want to return a reference to the provided default, not to self
// But Rule 3 would tie the output to self
fn current_or_default<'b>(&self, default: &'b str) -> &'b str {
if self.position < self.input.len() {
// ERROR: returning self.input would have lifetime 'a, not 'b
// So we must return default here
default
} else {
default
}
}
}When the elided lifetime does not match your intent, you need to be explicit. The compiler's inference is sound but conservative - it cannot read your mind about which input the output comes from.
Lifetime Elision in Impl Blocks
When you implement methods on a struct that holds a lifetime, the lifetime parameter must appear in the impl header:
struct Important<'a> {
content: &'a str,
}
// 'a must be declared on impl and on the type
impl<'a> Important<'a> {
fn content(&self) -> &str {
self.content
// Rule 3 applies: output lifetime = self's lifetime
// Which is tied to 'a through the struct definition
}
fn announce(&self, announcement: &str) -> &str {
println!("Attention: {}", announcement);
self.content
// Again Rule 3: output tied to self, which holds 'a
}
}The impl<'a> Important<'a> syntax is required because the struct type includes a lifetime parameter. The methods inside can then use elision normally.
The Hidden Lifetime in String Slices
One place where elision is invisible but always present is &str. Every &str is really &'_ str where '_ is the anonymous lifetime. Understanding this helps explain some otherwise puzzling errors:
// These are identical:
fn process(s: &str) -> usize { s.len() }
fn process<'a>(s: &'a str) -> usize { s.len() }
// The anonymous lifetime syntax makes elision visible:
fn process(s: &'_ str) -> usize { s.len() }
// Useful when you want to be explicit without naming the lifetime:
struct Wrapper<'a> {
value: &'a str,
}
impl Wrapper<'_> {
// '_ says "there is a lifetime here but I do not need to name it"
fn len(&self) -> usize {
self.value.len()
}
}The anonymous lifetime '_ is useful when you need to acknowledge that a lifetime exists but do not need to reference it by name. It appears in impl blocks for types with lifetime parameters when you do not need the lifetime parameter in the method bodies.
Elision in Type Aliases and Where Clauses
Elision applies in function signatures but not in type definitions. If you write a type alias involving references, you must be explicit:
// This does NOT compile - elision does not apply in type aliases
// type StrRef = &str; // ERROR
// You must be explicit:
type StrRef<'a> = &'a str;
// Or use the anonymous lifetime (Rust 2018+):
type StrRef<'_> = &'_ str;Similarly in where clauses you must be explicit about lifetimes when they matter for the bounds:
use std::fmt::Display;
fn print_if_long<'a, T>(value: &'a T, threshold: usize)
where
T: Display,
'a: 'static, // 'a must outlive 'static - a very strict bound
{
if format!("{}", value).len() > threshold {
println!("{}", value);
}
}A Decision Tree for Lifetime Annotations
Here is the mental process to follow when you are unsure whether you need an annotation:
- Does the function return a reference? If not, you almost certainly do not need annotations.
- Does the function take exactly one reference input? If yes, Rule 2 handles it - no annotation needed.
- Is this a method with
&selfor&mut self? If the return value comes fromself, Rule 3 handles it. - Does the return value come from a specific input that is not
self? Annotate that input and the output with the same lifetime. - Could the return value come from more than one input? Annotate all candidate inputs and the output with the same lifetime.
Common Elision Mistakes
Mistake 1: Assuming Elision Works in Struct Fields
// DOES NOT COMPILE - elision does not apply to struct fields
struct Excerpt {
text: &str, // ERROR: missing lifetime specifier
}
// You must be explicit:
struct Excerpt<'a> {
text: &'a str,
}Mistake 2: Forgetting That Rule 3 Ties Output to Self
struct Buffer {
data: Vec,
}
impl Buffer {
// You want to return a reference to the input, not to self
// But if you write this, Rule 3 ties output to self
fn validate_and_return<'b>(&self, input: &'b [u8]) -> &'b [u8] {
// Explicit 'b annotation is required here
// Without it, output would be tied to self's lifetime
input
}
} Mistake 3: Over-annotating When Elision Suffices
// Unnecessary - elision handles this
fn get_name<'a>(person: &'a Person) -> &'a str {
&person.name
}
// Idiomatic - let elision do its job
fn get_name(person: &Person) -> &str {
&person.name
}Over-annotating is not wrong, but it adds noise. It also makes it harder to spot the cases where annotations are genuinely necessary. Save explicit annotations for cases where elision cannot resolve the lifetimes, and your function signatures will communicate clearly.
What Comes Next
With elision rules in hand, you now have a complete picture of how lifetimes work in function signatures. The next step is applying that knowledge to structs and enums - data types that hold references as fields. That introduces a new set of constraints and patterns that are essential for building non-trivial data structures in Rust.
Part 5 covers lifetimes in structs and enums: how to annotate them, what the constraints mean, and the patterns that let you build data structures that safely hold references to external data.
References
- The Rust Reference - "Lifetime Elision" (https://doc.rust-lang.org/reference/lifetime-elision.html)
- The Rust Programming Language - "Validating References with Lifetimes" (https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html)
- The Rustonomicon - "Lifetime Elision" (https://doc.rust-lang.org/nomicon/lifetime-elision.html)
- Rust Blog - "Rust 2018 Edition" (https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-the-2018-edition.html)
- Rust by Example - "Lifetime Elision" (https://doc.rust-lang.org/stable/rust-by-example/scope/lifetime/elision.html)
