Understanding Lifetimes and References • Mehdi Mehdikhani

Lifetimes are probably the most confusing part of Rust when you’re starting out. I spent way too much time fighting the borrow checker before I understood what lifetimes actually represent.

What Lifetimes Actually Are

Lifetimes aren’t about memory management - they’re about validity. They tell the compiler how long references remain valid:

fn main() {
    let r;                // r's lifetime starts here
    {
        let x = 5;        // x's lifetime starts here
        r = &x;           // Error! x's lifetime ends at }
    }                     // x's lifetime ends here
    println!("{}", r);    // r would be a dangling pointer here
}                         // r's lifetime ends here

The compiler prevents you from using r because it would point to deallocated memory.

Lifetime Annotations

Most of the time, Rust infers lifetimes. But sometimes you need to be explicit:

// Without lifetime annotations - compiler can't infer
fn longest(x: &str, y: &str) -> &str {  // Error! Which lifetime?
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

// With lifetime annotations - now it's clear
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

The 'a means “the returned reference lives as long as the shorter of the two input references.”

When I Actually Need Lifetime Annotations

Most of the time, I encounter lifetimes when:

Functions returning references: When the return depends on multiple inputs:

struct Config {
    database_url: String,
    redis_url: String,
}

impl Config {
    // No lifetime needed - returning reference to self
    fn get_database_url(&self) -> &str {
        &self.database_url
    }

    // Lifetime needed - returning one of multiple inputs
    fn get_primary_url<'a>(&'a self, use_redis: bool) -> &'a str {
        if use_redis {
            &self.redis_url
        } else {
            &self.database_url
        }
    }
}

Structs holding references: When you want to avoid cloning data:

// This struct holds a reference instead of owning the data
struct Parser<'a> {
    input: &'a str,
    position: usize,
}

impl<'a> Parser<'a> {
    fn new(input: &'a str) -> Self {
        Self { input, position: 0 }
    }

    fn peek(&self) -> Option<char> {
        self.input.chars().nth(self.position)
    }

    fn advance(&mut self) -> Option<char> {
        let ch = self.peek()?;
        self.position += 1;
        Some(ch)
    }

    fn parse_word(&mut self) -> Option<&'a str> {
        let start = self.position;

        while let Some(ch) = self.peek() {
            if ch.is_alphanumeric() {
                self.advance();
            } else {
                break;
            }
        }

        if start < self.position {
            Some(&self.input[start..self.position])
        } else {
            None
        }
    }
}

// Usage
let text = "hello world rust";
let mut parser = Parser::new(text);

while let Some(word) = parser.parse_word() {
    println!("Word: {}", word);  // word is a slice of the original text
    parser.advance(); // Skip whitespace
}

Iterator implementations: When yielding references to internal data:

struct LineIterator<'a> {
    remaining: &'a str,
}

impl<'a> LineIterator<'a> {
    fn new(text: &'a str) -> Self {
        Self { remaining: text }
    }
}

impl<'a> Iterator for LineIterator<'a> {
    type Item = &'a str;

    fn next(&mut self) -> Option<Self::Item> {
        if self.remaining.is_empty() {
            return None;
        }

        if let Some(pos) = self.remaining.find('\n') {
            let line = &self.remaining[..pos];
            self.remaining = &self.remaining[pos + 1..];
            Some(line)
        } else {
            let line = self.remaining;
            self.remaining = "";
            Some(line)
        }
    }
}

// Usage
let text = "line 1\nline 2\nline 3";
let iterator = LineIterator::new(text);

for line in iterator {
    println!("Line: {}", line);  // Each line is a slice of original text
}

Cache-like structures: Avoiding expensive clones:

use std::collections::HashMap;

struct StringCache<'a> {
    cache: HashMap<&'a str, String>,
}

impl<'a> StringCache<'a> {
    fn new() -> Self {
        Self { cache: HashMap::new() }
    }

    fn get_or_process(&mut self, input: &'a str) -> &str {
        if !self.cache.contains_key(input) {
            let processed = input.to_uppercase().replace(" ", "_");
            self.cache.insert(input, processed);
        }

        &self.cache[input]
    }
}

// The cache can hold references to strings that live at least as long as 'a

Multiple Lifetimes

Sometimes you need multiple lifetime parameters:

struct Context<'a> {
    name: &'a str,
}

struct Request<'a, 'b> {
    context: &'a Context<'a>,
    body: &'b str,
}

impl<'a, 'b> Request<'a, 'b> {
    fn process(&self) -> String {
        format!("Processing request for {} with body: {}",
                self.context.name,
                self.body)
    }
}

// Usage shows how lifetimes work together
fn handle_request() {
    let name = "user123";                    // Lives for entire function
    let context = Context { name };          // References name

    {
        let body = "request data";           // Lives for this block only
        let request = Request { context: &context, body };
        println!("{}", request.process());
    }   // body and request die here, but context continues

    // context still usable here because name is still alive
    println!("Context name: {}", context.name);
}

Real World Example

Here’s a text processing system I built using lifetimes to avoid copying strings:

#[derive(Debug)]
struct Token<'a> {
    kind: TokenKind,
    text: &'a str,
    line: usize,
    column: usize,
}

#[derive(Debug, PartialEq)]
enum TokenKind {
    Word,
    Number,
    Punctuation,
    Whitespace,
}

struct Tokenizer<'a> {
    input: &'a str,
    position: usize,
    line: usize,
    column: usize,
}

impl<'a> Tokenizer<'a> {
    fn new(input: &'a str) -> Self {
        Self {
            input,
            position: 0,
            line: 1,
            column: 1,
        }
    }

    fn current_char(&self) -> Option<char> {
        self.input.chars().nth(self.position)
    }

    fn advance(&mut self) -> Option<char> {
        if let Some(ch) = self.current_char() {
            self.position += 1;
            if ch == '\n' {
                self.line += 1;
                self.column = 1;
            } else {
                self.column += 1;
            }
            Some(ch)
        } else {
            None
        }
    }

    fn skip_while<F>(&mut self, predicate: F) where F: Fn(char) -> bool {
        while let Some(ch) = self.current_char() {
            if predicate(ch) {
                self.advance();
            } else {
                break;
            }
        }
    }

    fn next_token(&mut self) -> Option<Token<'a>> {
        let start_pos = self.position;
        let start_line = self.line;
        let start_column = self.column;

        let ch = self.advance()?;

        let kind = if ch.is_alphabetic() {
            self.skip_while(|c| c.is_alphanumeric());
            TokenKind::Word
        } else if ch.is_numeric() {
            self.skip_while(|c| c.is_numeric() || c == '.');
            TokenKind::Number
        } else if ch.is_whitespace() {
            self.skip_while(|c| c.is_whitespace());
            TokenKind::Whitespace
        } else {
            TokenKind::Punctuation
        };

        let text = &self.input[start_pos..self.position];

        Some(Token {
            kind,
            text,
            line: start_line,
            column: start_column,
        })
    }
}

impl<'a> Iterator for Tokenizer<'a> {
    type Item = Token<'a>;

    fn next(&mut self) -> Option<Self::Item> {
        self.next_token()
    }
}

// Analysis phase - still using references to original text
fn analyze_tokens(tokens: &[Token]) {
    let mut word_count = 0;
    let mut number_count = 0;

    for token in tokens {
        match token.kind {
            TokenKind::Word => {
                word_count += 1;
                if token.text.len() > 10 {
                    println!("Long word at {}:{}: {}", token.line, token.column, token.text);
                }
            },
            TokenKind::Number => {
                number_count += 1;
                if let Ok(num) = token.text.parse::<f64>() {
                    if num > 1000.0 {
                        println!("Large number at {}:{}: {}", token.line, token.column, token.text);
                    }
                }
            },
            _ => {}
        }
    }

    println!("Found {} words and {} numbers", word_count, number_count);
}

// Usage
fn process_text() {
    let text = "The quick brown fox jumps over 1234 lazy dogs.";
    let tokenizer = Tokenizer::new(text);

    let tokens: Vec<Token> = tokenizer
        .filter(|token| token.kind != TokenKind::Whitespace)
        .collect();

    analyze_tokens(&tokens);

    // All tokens still reference the original text - no copying.
    for token in &tokens {
        println!("{:?}: '{}'", token.kind, token.text);
    }
}

Static Lifetime

The 'static lifetime means “lives for the entire duration of the program”:

// String literals have static lifetime
let s: &'static str = "Hello, world!";

// Functions can require static lifetime
fn store_reference(r: &'static str) -> &'static str {
    r  // Can return it because it lives forever
}

// But be careful - most things aren't static
fn example() {
    let string = String::from("temporary");
    // store_reference(&string);  // Error! string doesn't live long enough

    store_reference("literal");  // OK - literals are static
}

The Pattern I Follow

I think about lifetimes as:

How long does the data I’m borrowing need to live?
What’s the shortest lifetime I can get away with?
Can I restructure to avoid complex lifetime relationships?

Most of the time, Rust’s lifetime elision means I don’t write explicit lifetimes. When I do need them, I start with the simplest annotation and let the compiler guide me to the correct solution.

The key insight is that lifetimes are about expressing relationships between references, not about managing memory. Once that clicked, the borrow checker became a helpful tool instead of an obstacle.