Chapter 1: Ownership Deep Dive & Lifetimes

You've mastered the basics of ownership and borrowing in Rust. Now it's time to dive deep into the advanced patterns, edge cases, and lifetime mechanisms that make Rust's memory safety guarantees work. This chapter will transform your understanding from "I know the rules" to "I understand why these rules exist and how to use them effectively."

1.1 Advanced Ownership Patterns

Ownership isn't just about preventing bugs—it's about expressing intent and designing APIs that are impossible to misuse.

The Builder Pattern with Ownership

The builder pattern in Rust can leverage ownership to create type-safe, fluent APIs:

pub struct RequestBuilder {
    url: String,
    method: String,
    headers: Vec<(String, String)>,
    body: Option<String>,
}

impl RequestBuilder {
    pub fn new(url: impl Into<String>) -> Self {
        Self {
            url: url.into(),
            method: "GET".to_string(),
            headers: Vec::new(),
            body: None,
        }
    }

    // Take ownership and return ownership (fluent API)
    pub fn method(mut self, method: impl Into<String>) -> Self {
        self.method = method.into();
        self
    }

    pub fn header(mut self, key: impl Into<String>, value: impl Into<String>) -> Self {
        self.headers.push((key.into(), value.into()));
        self
    }

    pub fn body(mut self, body: impl Into<String>) -> Self {
        self.body = Some(body.into());
        self
    }

    // Consume self to build the final Request
    pub fn build(self) -> Request {
        Request {
            url: self.url,
            method: self.method,
            headers: self.headers,
            body: self.body,
        }
    }
}

// Usage:
let request = RequestBuilder::new("https://api.example.com")
    .method("POST")
    .header("Content-Type", "application/json")
    .body(r#"{"key": "value"}"#)
    .build();

Interior Mutability: Cell and RefCell

Sometimes you need mutability even when you only have an immutable reference. Rust provides safe interior mutability through Cell<T> and RefCell<T>:

use std::cell::{Cell, RefCell};

struct Stats {
    views: Cell<u32>,
    cache: RefCell<Vec<String>>,
}

impl Stats {
    fn new() -> Self {
        Self {
            views: Cell::new(0),
            cache: RefCell::new(Vec::new()),
        }
    }

    // Can increment views even with &self
    fn record_view(&self) {
        let current = self.views.get();
        self.views.set(current + 1);
    }

    // Can mutate cache even with &self
    fn add_to_cache(&self, item: String) {
        self.cache.borrow_mut().push(item);
    }

    fn get_cache(&self) -> Vec<String> {
        self.cache.borrow().clone()
    }
}

1.2 Lifetime Fundamentals Revisited

Lifetimes are Rust's way of ensuring that references are always valid. Let's explore the mechanics that make this work.

Lifetime Elision Rules

The compiler can infer lifetimes in many cases. Here are the three lifetime elision rules:

// Rule 1: Each input reference gets its own lifetime
fn print(s: &str) {
    // Desugars to: fn print<'a>(s: &'a str)
    println!("{}", s);
}

// Rule 2: If there's exactly one input lifetime,
// it's assigned to all output lifetimes
fn first_word(s: &str) -> &str {
    // Desugars to: fn first_word<'a>(s: &'a str) -> &'a str
    s.split_whitespace().next().unwrap_or("")
}

// Rule 3: If there's a &self or &mut self,
// its lifetime is assigned to all output lifetimes
impl MyStruct {
    fn get_data(&self) -> &String {
        // Desugars to: fn get_data<'a>(&'a self) -> &'a String
        &self.data
    }
}

Multiple Lifetimes

When you have multiple input references, you often need to specify their relationships explicitly:

// Return the longest of two string slices
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

// This says: "The returned reference will live as long as
// the shorter of the two input lifetimes"
fn main() {
    let string1 = String::from("long string");
    let result;
    {
        let string2 = String::from("short");
        result = longest(&string1, &string2);
        println!("Longest: {}", result); // OK: result used here
    }
    // println!("{}", result); // ERROR: string2 dropped
}

Lifetime Bounds

You can specify that a type must outlive a certain lifetime:

// T must contain only references that live at least as long as 'a
struct ImportantExcerpt<'a> {
    part: &'a str,
}

// The returned reference lives as long as self
impl<'a> ImportantExcerpt<'a> {
    fn level(&self) -> i32 {
        3
    }

    fn announce_and_return_part(&self, announcement: &str) -> &str {
        println!("Attention: {}", announcement);
        self.part
    }
}

// Generic type with lifetime bound
fn print_ref<'a, T>(data: &'a T)
where
    T: std::fmt::Display + 'a,
{
    println!("{}", data);
}

1.3 Advanced Lifetime Patterns

The 'static Lifetime

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

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

// Not the same as owned data!
let owned = String::from("I'm owned");
let slice: &'static str = "I'm static";

// Thread spawning often requires 'static
use std::thread;

fn spawn_example() {
    let data = "thread data".to_string();

    // ERROR: data doesn't live long enough
    // thread::spawn(|| {
    //     println!("{}", data);
    // });

    // Solution: move ownership
    thread::spawn(move || {
        println!("{}", data);
    });
}

Higher-Ranked Trait Bounds (HRTB)

Sometimes you need to express "for any lifetime." This is where HRTBs come in:

// A closure that can work with references of any lifetime
fn apply<F>(f: F, data: &str)
where
    F: for<'a> Fn(&'a str) -> &'a str,
{
    println!("{}", f(data));
}

fn main() {
    apply(|s| s, "hello");
}

// Common in trait definitions
trait Processor {
    fn process<'a>(&self, input: &'a str) -> &'a str;
}

// HRTB version
fn use_processor<P>(p: P, data: &str)
where
    P: for<'a> Fn(&'a str) -> &'a str,
{
    println!("{}", p(data));
}

Lifetime Subtyping and Variance

Lifetimes have a subtyping relationship: a longer lifetime is a subtype of a shorter lifetime:

// 'static is a subtype of any other lifetime
fn coerce<'a>() {
    let s: &'static str = "hello";
    let t: &'a str = s; // OK: 'static outlives 'a
}

// Variance in action
struct Container<'a, T> {
    data: &'a T,
}

// Container is covariant over both 'a and T
fn variance_example() {
    let long_lived = String::from("long");
    let container: Container<'static, String>;

    {
        let short_lived = String::from("short");
        // Can use longer lifetime where shorter is expected
        let _: Container<'_, String> = Container { data: &long_lived };
    }
}

1.4 Practical Lifetime Patterns

Struct with Multiple Lifetime Parameters

struct Context<'s, 'c> {
    source: &'s str,
    config: &'c Config,
}

struct Config {
    max_len: usize,
}

impl<'s, 'c> Context<'s, 'c> {
    fn process(&self) -> Result<String, String> {
        if self.source.len() > self.config.max_len {
            Err("Source too long".to_string())
        } else {
            Ok(self.source.to_uppercase())
        }
    }
}

fn main() {
    let config = Config { max_len: 100 };
    let source = "hello world";

    let ctx = Context {
        source: &source,
        config: &config,
    };

    println!("{:?}", ctx.process());
}

Self-Referential Structs (The Problem)

One thing you cannot do in safe Rust is create truly self-referential structs:

// This doesn't compile!
// struct SelfRef<'a> {
//     data: String,
//     slice: &'a str,  // Can't reference data in same struct
// }

// Solution 1: Use indices instead of references
struct SafeSelfRef {
    data: String,
    slice_start: usize,
    slice_end: usize,
}

impl SafeSelfRef {
    fn get_slice(&self) -> &str {
        &self.data[self.slice_start..self.slice_end]
    }
}

// Solution 2: Use Pin and unsafe (advanced)
use std::pin::Pin;

// For complex cases, use the `pin-project` crate

1.5 Lifetime Optimization Techniques

Avoiding Lifetime Pollution

Sometimes you can design APIs to avoid exposing lifetimes to callers:

// Before: Lifetime leaks into public API
pub struct Parser<'a> {
    input: &'a str,
    pos: usize,
}

impl<'a> Parser<'a> {
    pub fn parse(&mut self) -> Result<&'a str, String> {
        // parsing logic
        Ok(&self.input[self.pos..])
    }
}

// After: Return owned data to avoid lifetime
pub struct BetterParser {
    input: String,
    pos: usize,
}

impl BetterParser {
    pub fn parse(&mut self) -> Result<String, String> {
        // Return owned String instead of reference
        Ok(self.input[self.pos..].to_string())
    }
}

// Or use Cow for best of both worlds
use std::borrow::Cow;

pub fn process(input: &str) -> Cow<str> {
    if input.contains("special") {
        // Need to modify: return owned
        Cow::Owned(input.replace("special", "SPECIAL"))
    } else {
        // No modification: return borrowed
        Cow::Borrowed(input)
    }
}

1.6 Chapter Summary