You wrote a function that returns a reference. The compiler screamed.
You write a function that takes two string slices and returns the longer one. The logic is straightforward: compare the lengths, return the winner. You hit compile, and the terminal explodes with E0106: missing lifetime specifier. The code looks perfectly reasonable. The compiler is being difficult. It isn't. The compiler is protecting you from dangling references, but it needs you to tell it how the output relates to the inputs.
Rust tracks how long references are valid. This tracking is called lifetime analysis. When a function returns a reference, the compiler must know which input the output is tied to. If the function returns x, the output lives as long as x. If it returns y, the output lives as long as y. The compiler cannot look inside the function body to decide this. It needs the signature to declare the relationship upfront. E0106 is the compiler asking for that declaration.
Lifetimes are contracts, not clocks
A lifetime is a promise about validity. It tells the compiler that a reference will not dangle. Think of a lifetime like a lease on an apartment. The reference is the key. The lifetime is the duration of the lease. If the lease expires because the data is dropped, the key becomes useless. Rust forbids using a key after the lease ends.
When you write &str, you're using a reference with an anonymous lifetime. The compiler assigns a unique, invisible lifetime to each reference. This works fine when references are passed around within a single scope. The compiler can see the whole scope and verify the keys are used before the leases expire.
Functions break this visibility. A function signature is a black box. The caller doesn't see the body. The caller only sees the inputs and outputs. If the function returns a reference, the caller needs to know how long that reference is valid. The signature must specify whether the output is tied to an input or to something else entirely.
Lifetimes do not measure time. They do not pause execution. They are compile-time annotations that define relationships between references. The compiler checks these relationships against the scopes in your code. If the relationships hold, the code compiles. If they don't, you get an error.
The minimal fix
The fix for E0106 is to add a lifetime parameter to the function signature. This parameter links the lifetimes of the inputs and outputs.
/// Returns the longer of two string slices.
/// The output lives as long as the shorter of the two inputs.
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
// 'a ties the output to both inputs.
// The compiler now knows the return value is valid
// as long as both x and y are valid.
if x.len() > y.len() { x } else { y }
}
The syntax <'a> declares a lifetime parameter named 'a. The annotation &'a str means "a string slice that lives at least as long as 'a." The signature reads: "Give me two strings that both live at least as long as 'a, and I'll give you back a string that also lives at least as long as 'a."
The compiler enforces this contract. When you call longest, the compiler checks that the returned reference is used only within a scope where both inputs are still alive. If you try to use the result after one input drops, the compiler rejects the code.
This prevents dangling references. If the function returned a reference to a local variable, that variable would die when the function ends. Its lifetime would be shorter than 'a. The compiler would catch this mismatch.
Why the compiler won't guess
Rust could theoretically infer lifetimes by analyzing the function body. If the body only returns x, the compiler could deduce that the output lifetime equals the lifetime of x. Rust chooses not to do this for a specific reason.
Function signatures are part of the public API. Callers depend on the signature. If the compiler inferred lifetimes from the body, changing the implementation could change the API requirements without updating the signature. This would break callers silently or cause confusing errors.
Explicit lifetimes make the API contract stable. The signature declares the requirements. The body must satisfy them. If you change the body to return a different reference, you must update the signature to match. This keeps the API clear and predictable.
Convention aside: The community names lifetimes 'a, 'b, 'c for simple cases. For complex signatures, descriptive names like 'input or 'output improve readability. Pick names that help the human reader, not just the compiler.
Lifetime elision: The compiler's shortcut
Writing lifetimes everywhere is verbose. Rust includes lifetime elision rules to make common patterns ergonomic. The compiler applies these rules automatically when you omit lifetime annotations.
The rules are simple:
- Each input reference gets its own lifetime parameter.
- If there is exactly one input lifetime, that lifetime is assigned to all output references.
- If
&selfis present, the lifetime ofselfis assigned to all output references.
These rules cover most methods and simple functions.
/// Returns the first word of a string.
/// Elision rule 2 applies: one input, so output gets that lifetime.
fn first_word(s: &str) -> &str {
let bytes = s.as_bytes();
for (i, &item) in bytes.iter().enumerate() {
if item == b' ' {
return &s[..i];
}
}
s
}
This function compiles without explicit lifetimes. There is one input reference s. The compiler assigns it a lifetime 'a. The output gets 'a. The signature is effectively fn first_word<'a>(s: &'a str) -> &'a str.
Elision fails when there are multiple inputs and the compiler cannot decide which one the output borrows from.
// E0106: missing lifetime specifier.
// Two inputs. The compiler doesn't know if the output
// is tied to x, y, or both.
fn longest(x: &str, y: &str) -> &str {
if x.len() > y.len() { x } else { y }
}
Here, the compiler stops. It cannot guess. You must add the lifetime annotation.
Trust the elision rules for simple cases, but don't rely on them to hide complex relationships. When the signature gets complicated, write the lifetimes explicitly. It's documentation for the human reading the code.
Structs and the leash
Structs that hold references also need lifetime parameters. The struct cannot outlive the data it points to. The lifetime parameter acts as a leash. The struct can never outwalk the data.
/// A struct that holds a reference to a string slice.
/// The struct is tied to the lifetime of the data.
struct ImportantExcerpt<'a> {
// The struct borrows data, so it needs a lifetime parameter.
// This struct cannot outlive the string it references.
part: &'a str,
}
// Methods on the struct must declare the lifetime too.
impl<'a> ImportantExcerpt<'a> {
/// Returns a level indicator.
/// This method returns an owned value, so no lifetime on the output.
fn level(&self) -> i32 {
3
}
}
The struct definition includes <'a>. The field part uses &'a str. This means the struct is valid only as long as the string slice is valid.
The impl block also needs <'a>. This ties the methods to the struct's lifetime. Methods that return references from the struct must respect this lifetime.
impl<'a> ImportantExcerpt<'a> {
/// Returns the excerpt itself.
/// The output borrows from self, so it gets 'a.
fn get_part(&self) -> &'a str {
self.part
}
}
This method compiles. The output borrows from self. self has lifetime 'a. The output gets 'a. The contract holds.
If the method tried to return a reference to a local variable, the compiler would reject it. The local variable dies when the method ends. Its lifetime is shorter than 'a. The signature promises 'a. The mismatch triggers an error.
Treat the lifetime on a struct as a leash. The struct can never outwalk the data it points to.
Realistic scenario: A config parser
Real code often mixes borrowed and owned data. A config parser might read from a file and return references to sections, or it might construct new strings.
/// A parser that holds a reference to the raw config text.
struct ConfigParser<'a> {
raw: &'a str,
}
impl<'a> ConfigParser<'a> {
/// Creates a new parser from a borrowed string.
fn new(raw: &'a str) -> Self {
ConfigParser { raw }
}
/// Returns a reference to a section.
/// The output lives as long as the input data.
fn get_section(&self, name: &str) -> Option<&'a str> {
// Search for the section header.
// If found, return a slice of the raw data.
// The slice borrows from self.raw, which has lifetime 'a.
if let Some(start) = self.raw.find(&format!("[{}]", name)) {
let section_start = start + name.len() + 3;
if let Some(end) = self.raw[section_start..].find('\n') {
return Some(&self.raw[section_start..section_start + end]);
}
}
None
}
/// Returns a computed value.
/// This returns an owned String, so no lifetime issues.
fn get_version(&self) -> String {
// Search for version line.
// Return a new String.
if let Some(line) = self.raw.lines().find(|l| l.starts_with("version")) {
return line.trim().to_string();
}
"unknown".to_string()
}
}
The struct ConfigParser holds &'a str. The method get_section returns &'a str. The output borrows from the raw data. The lifetime is preserved. The caller gets a reference that lives as long as the original config text.
The method get_version returns String. This is an owned type. It allocates new memory. The lifetime of the parser doesn't matter. The caller owns the result. This is a common pattern: return references when you can, return owned types when you must.
When in doubt, return an owned value. It's always correct, even if it costs a heap allocation.
Pitfalls and error codes
Lifetimes introduce specific pitfalls. Recognizing these patterns saves debugging time.
Returning a reference to a local variable. This is the most common error. The function creates a local value and returns a reference to it. The local dies when the function ends. The reference dangles.
fn dangerous() -> &str {
let s = String::from("hello");
&s
}
The compiler rejects this with E0515: cannot return value referencing local variable. The lifetime of s is shorter than the return lifetime. The fix is to return an owned String instead.
Mismatched lifetimes. You promise a lifetime in the signature but return a reference with a shorter lifetime.
fn longest<'a>(x: &str, y: &'a str) -> &'a str {
if x.len() > y.len() { x } else { y }
}
This compiles with a warning or error depending on context. The return type promises 'a. The branch returning x provides a reference with an anonymous lifetime. That lifetime might be shorter than 'a. The compiler rejects this with E0597: borrowed value does not live long enough. You promised the output lives as long as 'a, but x might die sooner. The fix is to add 'a to x as well, or change the logic.
Over-constraining. You add lifetimes that are stricter than necessary. This compiles but reduces flexibility.
fn first_word<'a>(s: &'a str) -> &'a str {
// ...
}
This works, but it forces the input to live as long as 'a. The elision rule would assign the input's lifetime to the output automatically. Adding 'a explicitly ties them together. In this case, it's harmless. In complex cases, over-constraining can prevent valid uses. Use the minimal lifetimes required. If elision works, let it work.
Confusing 'static. The lifetime 'static means the data lives for the entire program. String literals have 'static lifetime.
fn get_greeting() -> &'static str {
"Hello"
}
This compiles. The string literal is embedded in the binary. It never drops. The reference is valid forever. Do not confuse 'static with "allocated on the stack". It means "valid for the duration of the program". Using 'static incorrectly can cause the compiler to reject valid code where the data is shorter-lived.
Write the lifetime. It's documentation for the human reading the code. If you can't explain the lifetime, you don't understand the contract.
Decision: Lifetimes vs ownership
Choosing between lifetimes and ownership is a core design decision. Lifetimes avoid allocations but add complexity. Ownership is simple but costs memory.
Use lifetime annotations when the function returns a reference and the compiler cannot infer which input the output is tied to. Use lifetime parameters on structs when the struct holds a reference to external data. Use lifetime elision when there is exactly one input reference and the output borrows from it; the compiler handles this automatically. Use owned types like String instead of references when the function creates new data or needs to return data that outlives the inputs. Use Cow<str> when you want to accept either borrowed or owned data and return a unified type without forcing the caller to allocate.
Reach for plain references when lifetimes are simple; the unsafe alternative is rarely worth it. Reach for owned types when the data flow is complex; the allocation cost is usually negligible compared to the cognitive load of managing lifetimes.
Counter-intuitive but true: the more lifetimes you add, the harder the rest of your code becomes to reason about. Simplify the data flow before reaching for lifetime gymnastics.