zeljic.com

Understanding Rust Lifetimes: A Beginner's Guide

Lifetimes are one of Rust’s most talked-about features, and they often intimidate newcomers. But once you understand why they exist, they become much less scary. Let’s demystify them.

What Problem Do Lifetimes Solve?

Consider this C code:

char* get_greeting() {
    char greeting[] = "Hello";
    return greeting;  // BUG: returning pointer to local variable
}

This is a classic use-after-free bug. The greeting array lives on the stack and is deallocated when the function returns. The caller gets a pointer to garbage.

Rust’s lifetimes prevent this entire class of bugs at compile time.

References Have Lifetimes

Every reference in Rust has a lifetime - the scope during which that reference is valid. Most of the time, lifetimes are inferred automatically:

fn main() {
    let x = 5;          // x's lifetime starts
    let r = &x;         // r borrows x, r's lifetime starts
    println!("{}", r);  // r is used
}                       // x and r go out of scope

The compiler sees that r (a reference to x) doesn’t outlive x, so everything is fine. No annotations needed.

When You Need Explicit Lifetimes

Problems arise when the compiler can’t figure out the relationship between references. Consider this function:

fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

This won’t compile! The error:

error[E0106]: missing lifetime specifier
 --> src/main.rs:1:33
  |
1 | fn longest(x: &str, y: &str) -> &str {
  |               ----     ----     ^ expected named lifetime parameter

The compiler is asking: “The return value is a reference, but is it connected to x or y? How long should it live?”

Adding Lifetime Annotations

Lifetime annotations tell the compiler how references relate to each other:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

Let’s break this down:

  • <'a> declares a lifetime parameter (pronounced “tick a” or “lifetime a”)
  • x: &'a str means “x is a reference that lives at least as long as ‘a”
  • y: &'a str means “y also lives at least as long as ‘a”
  • -> &'a str means “the return value lives at least as long as ‘a”

In practice, 'a will be the shorter of the two input lifetimes. The compiler ensures the returned reference is valid for that duration.

How the Compiler Uses This

fn main() {
    let string1 = String::from("long string");
    
    {
        let string2 = String::from("xyz");
        let result = longest(&string1, &string2);
        println!("Longest: {}", result);  // Works!
    }
    // string2 is dropped here
}

The compiler sees that result is only used inside the inner block where both string1 and string2 are valid.

But this won’t compile:

fn main() {
    let string1 = String::from("long string");
    let result;
    
    {
        let string2 = String::from("xyz");
        result = longest(&string1, &string2);
    }
    // string2 is dropped here, but result might reference it!
    
    println!("Longest: {}", result);  // Error!
}

The error:

error[E0597]: `string2` does not live long enough

This is exactly what lifetimes prevent - a dangling reference.

Lifetime Elision Rules

You might wonder: if lifetimes are so important, why don’t we write them everywhere? Rust has elision rules that let the compiler infer lifetimes in common cases.

The rules are:

  1. Each input reference gets its own lifetime parameter
  2. If there’s exactly one input lifetime, it’s assigned to all output lifetimes
  3. If there’s a &self or &mut self, that lifetime is assigned to outputs

Examples of Elision

// What you write:
fn first_word(s: &str) -> &str { ... }

// What the compiler sees (Rule 1 & 2):
fn first_word<'a>(s: &'a str) -> &'a str { ... }
// What you write:
fn get_name(&self) -> &str { ... }

// What the compiler sees (Rule 3):
fn get_name<'a>(&'a self) -> &'a str { ... }

The longest function needs explicit lifetimes because it has two input references and the compiler can’t know which one the output relates to.

Lifetimes in Structs

When a struct holds a reference, you must specify its lifetime:

struct Excerpt<'a> {
    part: &'a str,
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.').next().unwrap();
    
    let excerpt = Excerpt {
        part: first_sentence,
    };
    
    println!("{}", excerpt.part);
}

This annotation means: “An Excerpt cannot outlive the reference it holds.”

If we tried to use excerpt after novel is dropped, the compiler would catch it.

The ‘static Lifetime

There’s one special lifetime: 'static. It means the reference can live for the entire program duration.

// String literals have 'static lifetime
let s: &'static str = "I live forever";

String literals are stored in the program’s binary, so they’re always available. But be careful - 'static doesn’t mean “use this to make lifetime errors go away.” It has specific semantics.

Common Patterns

Pattern 1: Return References from Input

fn first_element<'a>(slice: &'a [i32]) -> &'a i32 {
    &slice[0]
}

Pattern 2: Store References in Structs

struct Parser<'a> {
    input: &'a str,
    position: usize,
}

impl<'a> Parser<'a> {
    fn new(input: &'a str) -> Parser<'a> {
        Parser { input, position: 0 }
    }
    
    fn current_char(&self) -> Option<char> {
        self.input.chars().nth(self.position)
    }
}

Pattern 3: Multiple Lifetime Parameters

Sometimes you need different lifetimes:

fn split_at_char<'a, 'b>(s: &'a str, delimiter: &'b str) -> &'a str {
    // Returns part of 's', not 'delimiter'
    s.split(delimiter).next().unwrap_or(s)
}

Here, the return value’s lifetime is tied to s, not delimiter.

Troubleshooting Lifetime Errors

When you get a lifetime error:

  1. Identify what the compiler is protecting you from. Usually it’s preventing a dangling reference.

  2. Check if you’re trying to return a reference to local data. You might need to return an owned value instead.

  3. Verify your lifetime annotations match your intent. If you say two inputs have the same lifetime, the compiler enforces that.

  4. Consider if you actually need a reference. Sometimes cloning or using owned types is simpler.

Example Fix

// This won't work - returning reference to local data
fn create_greeting(name: &str) -> &str {
    let greeting = format!("Hello, {}!", name);
    &greeting  // Error: greeting is dropped!
}

// Fix: return owned String
fn create_greeting(name: &str) -> String {
    format!("Hello, {}!", name)
}

Final Thoughts

Lifetimes aren’t about making your life harder. They’re the compiler’s way of ensuring every reference points to valid data. Once you internalize this, lifetime annotations become a tool for expressing your intent, not an obstacle.

Key takeaways:

  • Lifetimes prevent dangling references at compile time
  • Most lifetimes are inferred - you only annotate when the compiler needs help
  • Annotations describe relationships - they don’t change how long data lives
  • When in doubt, consider if you actually need a reference

Start with the compiler’s suggestions. Most lifetime errors have clear fixes, and the error messages are quite helpful. With practice, you’ll develop an intuition for when and where lifetime annotations are needed.