Lifetimes

When you have to write them

1fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {2    if x.len() >= y.len() { x } else { y }3}4 5struct Parser<'src> {6    input: &'src str, // a Parser cannot outlive the text it points into7}8 9impl<'src> Parser<'src> {10    fn first_word(&self) -> &'src str {11        self.input.split_whitespace().next().unwrap_or("")12    }13}14 15fn first_char(s: &str) -> &str { // elided: same as fn first_char<'a>(s: &'a str) -> &'a str16    &s[..1]17}18 19fn main() {20    let a = String::from("ownership");21    let w;22    {23        let b = String::from("borrow");24        println!("{}", longest(&a, &b)); // fine: used while both are alive25        let p = Parser { input: &a };26        w = p.first_word(); // tied to a, not to p27    }28    println!("{w} {}", first_char("rust"));29}

It prints ownership, then ownership r. Without the annotations, longest fails with:

1error[E0106]: missing lifetime specifier2  |31 | fn longest(x: &str, y: &str) -> &str {4  |               ----     ----     ^ expected named lifetime parameter5  |6  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`

With 'a on both inputs, the result is valid for the region where both are valid. The caller can't keep the result after either string is dropped.

first_word returns &'src str, not a borrow of self. That is why w stays valid after p is gone: it points into a, which is still alive. Choosing which lifetime an output carries is real API design.

Elision rules

Most signatures need no annotations because of three elision rules:

1. Each elided lifetime in the inputs gets its own parameter.
2. If there is exactly one input lifetime, it is used for every elided output lifetime.
3. If one input is &self or &mut self, its lifetime is used for elided outputs.

If the rules don't settle an output's lifetime, you must write it. Since Rust 1.89 a lint, mismatched_lifetime_syntaxes, warns when a signature hides a lifetime in one place but shows it in another, such as fn make(s: &str) -> Thing where Thing secretly borrows from s; writing -> Thing<'_> makes the borrow visible.

'static

'static means the data lives until the program ends. String literals are &'static str. As a bound, T: 'static means the type holds no borrowed data that could expire. Owned types like String satisfy it. That is why std::thread::spawn and tokio::spawn require it: the new thread or task may outlive the caller's stack.

When lifetimes fight you

If a struct needs several lifetime parameters, or you keep reaching for 'static to make errors go away, the data probably wants to be owned: store a String, or share it with Rc or Arc. Borrowing structs work best for short-lived views such as parsers, iterators and guards.