Rust E0106 — Missing Lifetime Specifier — What It Means & How to Fix It

What Does This Error Mean?

E0106 means a reference in your function signature is missing a lifetime annotation. In Rust, references can only exist as long as the data they point to is alive. Lifetime annotations (written as 'a, 'b) tell Rust how long a reference lives. When you have a reference in a function's return type or struct, Rust often needs you to specify which input lifetime it is connected to.

Affected Models

Rust 1.0 and later
All Rust editions

Common Causes

A struct or enum has a reference field but no lifetime parameter on the struct definition
A function returns a reference but Rust cannot figure out which input's lifetime the reference is borrowed from
A function signature has multiple reference parameters and a reference return type with no lifetime annotations
An impl block has reference types without lifetime annotations
A type alias for a reference type is missing a lifetime parameter

How to Fix It

For a struct with a reference field, add a lifetime parameter to the struct definition: struct MyStruct<'a> { name: &'a str }

The 'a is a lifetime name — it means 'name cannot outlive the data it borrows'. This is a promise to Rust's borrow checker.
For a function that returns a reference, add lifetime annotations to show which input the output borrows from: fn first<'a>(x: &'a str, y: &'a str) -> &'a str

This tells Rust: the returned reference lives as long as both x and y. The 'a ties the output lifetime to the input lifetimes.
Try lifetime elision first — Rust can infer lifetimes in simple cases. If there is only one reference input parameter, Rust automatically applies it to the output reference.

fn get_name(s: &str) -> &str — Rust automatically infers that the returned &str borrows from s. You do not need explicit annotations here.
Read the compiler's error message carefully — Rust's error messages for lifetime issues are very detailed and usually suggest exactly what annotations to add.

Rust's compiler is famous for giving helpful, specific suggestions. Copy the suggested fix from the error message and try it.
If lifetimes are too complex for your use case, consider using owned types (String instead of &str, Vec<T> instead of &[T]) to avoid the need for lifetimes altogether.

Owned types do not have lifetime issues. The trade-off is a small performance cost from cloning/allocating. For most applications this is acceptable.

When to Call a Professional

Lifetime errors are unique to Rust and can be confusing for beginners. Start with simple cases and use Rust's helpful error messages — they often suggest the exact fix. The Rust Book chapter on lifetimes is the best resource for learning this system.

Frequently Asked Questions

What is a lifetime in Rust?

A lifetime is how long a reference is valid — how long the data it points to remains in memory. Rust tracks lifetimes at compile time to guarantee that a reference never points to freed memory. Lifetime annotations like 'a are labels that connect the lifetime of an output reference to the lifetime of an input. Think of it like a contract: 'this output reference is valid as long as this input reference is valid'.

What is lifetime elision?

Lifetime elision is Rust's ability to infer lifetime annotations automatically in common situations. For example, if a function has exactly one reference parameter and returns a reference, Rust assumes the output borrows from that one input. Elision rules mean you often do not need to write lifetime annotations for simple functions. When elision cannot determine the lifetimes (like when there are multiple reference inputs), you must write them explicitly.

Is the 'static lifetime special?

Yes — 'static means the reference lives for the entire duration of the program. String literals like 'hello' have type &'static str because they are stored in the program's binary and live forever. 'static is sometimes suggested by the compiler but is not always the right fix — it means the data must live forever, which is a strong requirement. Only use 'static when you genuinely mean 'this reference is valid for the whole program'.