Lifetime elision rules in Rust - Step-by-Step Execution

Concept Flow - Lifetime elision rules

Start: Function with references

↓

Check input lifetimes

↓

Apply Rule 1: One input ref?

| Yes↓

Output lifetime = input lifetime

No↓

Apply Rule 2: Multiple input refs, one &self or &mut self?

| Yes↓

Output lifetime = self's lifetime

No↓

Apply Rule 3: Multiple input refs, no self

↓

Output lifetime = anonymous, compiler error if ambiguous

↓

End

The compiler applies three rules to assign lifetimes to references in functions without explicit annotations, simplifying code while ensuring safety.

Execution Sample

Rust

fn first_word(s: &str) -> &str {
    &s[0..1]
}

A function taking one reference input and returning a reference with the same lifetime, using Rule 1.

Execution Table

Step	Input References	Rule Applied	Output Lifetime	Explanation
1	&str s	Rule 1	Same as s	One input reference, output lifetime matches input
2	&self, &str s	Rule 2	Same as self	Multiple inputs including &self, output lifetime matches self
3	&str s1, &str s2	Rule 3	Compiler error if ambiguous	Multiple inputs, no self, output lifetime ambiguous
4	No references	No rule	No lifetime needed	No references, no lifetime elision needed

💡 Lifetime elision rules stop after applying the first matching rule or error if ambiguous

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Input references	None	&str s	&self, &str s	&str s1, &str s2	N/A
Output lifetime	None	Same as s	Same as self	Ambiguous/Error	N/A

Key Moments - 3 Insights

Why does the compiler assign the output lifetime to the input reference's lifetime when there is only one input reference?

Because Rule 1 states that if there is exactly one input lifetime, the output lifetime is assumed to be the same, simplifying annotations as shown in execution_table row 1.

What happens if a function has multiple input references but none is &self or &mut self?

Rule 3 applies, and the compiler cannot infer which input lifetime to assign to the output, causing an error unless lifetimes are explicitly annotated, as shown in execution_table row 3.

Why does the presence of &self or &mut self affect lifetime elision?

Rule 2 gives priority to &self or &mut self lifetimes for output references when multiple inputs exist, assuming the output borrows from self, as shown in execution_table row 2.

Visual Quiz - 3 Questions

Look at the execution table, what output lifetime is assigned when the function has one input reference &str s?

A Compiler error

B Same as s

C Same as self

D No lifetime needed

💡 Hint

Refer to execution_table row 1 where Rule 1 applies for one input reference

At which step does the compiler produce an error due to ambiguous lifetimes?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Check execution_table row 3 where multiple inputs without self cause ambiguity

If a function has inputs &self and &str s, which lifetime does the output borrow from?

A From self

B From s

C Compiler error

D No lifetime needed

💡 Hint

See execution_table row 2 where Rule 2 applies with &self present

Concept Snapshot

Lifetime Elision Rules in Rust:
1. One input reference: output borrows from it.
2. Multiple inputs with &self: output borrows from self.
3. Multiple inputs without &self: compiler error if ambiguous.
Simplifies lifetime annotations in function signatures.

Full Transcript

Lifetime elision rules in Rust help the compiler guess lifetimes in function signatures without explicit annotations. When a function has exactly one input reference, the output lifetime is assumed to be the same as that input (Rule 1). If there are multiple input references and one is &self or &mut self, the output lifetime is assumed to be the lifetime of self (Rule 2). If there are multiple input references but none is self, the compiler cannot decide which lifetime to assign to the output, resulting in an error unless lifetimes are explicitly annotated (Rule 3). These rules make writing safe code easier by reducing the need for verbose lifetime annotations.