Lifetimes in Rust

# CHAPTER 18

Lifetimes in Rust #

1. Chapter Introduction #

2. Learning Objectives #

• Understand what a Lifetime is.

• Use Lifetime Annotations (e.g., 'a).

• Define Lifetimes in function signatures.

• Store references inside Structs safely.

• Understand the 'static lifetime.

3. The Dangling Pointer Problem #

fn main() {
    let r;                // r is declared
    {
        let x = 5;        // x is created
        r = &x;           // r borrows x
    }                     // x goes out of scope and is DROPPED!
    
    // println!("r: {}", r); // ERROR! r is pointing to deleted memory!
}

The compiler blocks this because the *lifetime* of x is shorter than the *lifetime* of r.

4. Lifetime Annotations in Functions #

// ERROR: missing lifetime specifier
// fn longest(x: &str, y: &str) -> &str {
//    if x.len() > y.len() { x } else { y }
// }

Why does this fail? The compiler doesn't know if the returned reference will point to x or y. If y gets deleted early, the returned reference might be dangling! We must annotate the relationships.

Lifetime Annotations ('a) We use a tick ' followed by a lowercase letter (conventionally 'a).

// We define a generic lifetime <'a>
// We tell the compiler: "x, y, and the return value all share the same lifetime 'a"
fn longest<&#039;a>(x: &&#039;a str, y: &&#039;a str) -> &&#039;a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

*Note: Lifetime annotations do NOT change how long data actually lives. They simply explain the relationship between parameters to the compiler so it can do its safety checks.*

5. Lifetimes in Structs #

// The struct holds a lifetime 'a
struct Highlight<&#039;a> {
    part: &&#039;a str, // The reference must live at least as long as 'a
}

fn main() {
    let text = String::from("This is a long sentence.");
    let first_word = text.split(&#039; &#039;).next().unwrap();
    
    // Highlight borrows a slice of 'text'
    let h = Highlight { part: first_word };
    
    println!("Highlighted: {}", h.part);
} // Both text and h go out of scope here safely.

6. Lifetime Elision (Why you don't always need them) #

// You write this:
fn get_word(s: &str) -> &str { ... }

// The compiler secretly expands it to this:
fn get_word<&#039;a>(s: &&#039;a str) -> &&#039;a str { ... }

You only need to write annotations when the compiler encounters ambiguity (like taking *two* references).

7. The 'static Lifetime #

let s: &'static str = "I am compiled directly into the binary.";

8. Common Mistakes #

• Trying to "Extend" Lifetimes: Annotations do not magically make a variable live longer. If you create a String inside a function and try to return a reference to it annotated with 'a, the compiler will still fail. The variable dies at the end of the function regardless of annotations.

• Overcomplicating: Beginners often throw 'a and 'b everywhere when the compiler complains. 90% of the time, an architecture change (like returning an owned String instead of a reference) is the better solution.

9. Best Practices #

• Return Owned Types: If you are struggling with lifetimes in a complex function, just return an owned String or Vec using .clone(). Yes, it costs a little performance, but it saves hours of developer frustration. Optimize for performance later.

10. Exercises #

1. 1. Write a function shortest<'a>(s1: &'a str, s2: &'a str) -> &'a str.

1. 2. Return the shorter of the two strings.

1. 3. Call it in main and print the result.

11. MCQs with Answers #

12. Interview Questions #

• Q: Explain what a Lifetime Annotation is and why the compiler needs it for functions with multiple reference parameters.

• Q: What is the 'static lifetime, and where is it most commonly seen naturally?

13. Summary #

14. Next Chapter Recommendation #