RustMiddleTechnical

Что такое lifetimes в Rust и почему компилятор требует их указания?

Lifetime — аннотация о том, как долго reference остаётся валидной. Компилятор требует её когда не может автоматически вывести связь между временем жизни входных и выходных references, чтобы исключить dangling references.

Что такое lifetime

Lifetime — аннотация, описывающая, как долго reference остаётся валидной. Lifetime не управляет временем жизни объекта — это делает ownership. Lifetime только описывает связь между временем жизни references, чтобы компилятор мог проверить отсутствие dangling references.

Зачем компилятор требует lifetime аннотации

// Компилятор не может вывести lifetime без подсказки:
// Которая строка будет жить дольше — x или y?
fn longest(x: &str, y: &str) -> &str {  // ОШИБКА: нужна lifetime аннотация
    if x.len() > y.len() { x } else { y }
}

// С аннотацией: возвращаемая &str живёт не дольше самого короткого из x и y
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

fn main() {
    let s1 = String::from("long string");
    let result;
    {
        let s2 = String::from("xyz");
        result = longest(s1.as_str(), s2.as_str());
        println!("{result}");  // OK: используем result пока s2 живёт
    }  // s2 уничтожается здесь
    // println!("{result}");  // ОШИБКА: result может указывать на s2, которой нет
}

Lifetime в структурах

// Структура хранит reference — должна объявить lifetime
struct ImportantExcerpt<'a> {
    part: &'a str,  // part не может жить дольше строки, из которой взята
}

impl<'a> ImportantExcerpt<'a> {
    fn level(&self) -> i32 { 3 }
    
    fn announce(&self, announcement: &str) -> &str {
        println!("Внимание: {announcement}");
        self.part  // возвращает &'a str (lifetime elision выводит это автоматически)
    }
}

fn main() {
    let novel = String::from("Первое предложение. Второе.");
    let excerpt = {
        let first = novel.split('.').next().unwrap();
        ImportantExcerpt { part: first }  // first заимствует из novel
    };  // блок заканчивается, но excerpt.part всё ещё валидна — она из novel
    println!("{}", excerpt.part);
}  // novel уничтожается здесь, excerpt уничтожается раньше

Lifetime elision — правила автоматического вывода

// Правило 1: каждый input reference получает свой lifetime
fn foo(x: &str) -> &str { x }  // эквивалентно: fn foo<'a>(x: &'a str) -> &'a str

// Правило 2: если один input, output получает его lifetime
fn first_word(s: &str) -> &str {  // &str имплицитно 'a и 'a
    &s[..s.find(' ').unwrap_or(s.len())]
}

// Правило 3: если &self или &mut self, output получает lifetime self
struct Parser { data: String }
impl Parser {
    fn parse(&self) -> &str { &self.data }  // &str живёт 'self
}

Специальный lifetime 'static

// 'static — живёт всё время выполнения программы
let s: &'static str = "hello";  // строковые литералы всегда 'static

// В trait objects для Send через потоки
use std::thread;
fn run_in_thread<F: Fn() + Send + 'static>(f: F) {
    thread::spawn(f);
}
// 'static требует: F не содержит references с конечным lifetime
// (иначе thread мог бы пережить данные, на которые ссылается)

Подводные камни

  • Lifetime аннотации не изменяют время жизни — они только описывают ограничения, которые компилятор проверяет.
  • Higher-Ranked Trait Bounds (for<'a> Fn(&'a T)) нужны для closures, принимающих references с любым lifetime.
  • Invariance vs covariance: &mut T инвариантна по T — нельзя передать &mut &'static str туда, где ожидается &mut &'a str.
  • Self-referential structs (структура содержит reference на себя) невозможны в safe Rust без Pin или arena.
  • Lifetime subtyping: 'a: 'b означает 'a живёт не короче 'b — нужно для сложных generic bounds.
  • Anonymous lifetimes (&'_ str) существуют в Rust 2018+, но могут запутать читателя кода.
  • Lifetime в async fn скрыты: async fn foo(x: &str) -> &str создаёт Future, захватывающий lifetime x, что ограничивает использование.
  • Compiler error messages с lifetime ошибками бывают неточными — важно понять концептуально, где нарушение.

Common mistakes

  • Отвечать определением без production-сценария.
  • Не называть runtime boundary, security boundary или failure mode.
  • Игнорировать версию API, observability и тестовую проверку.

What the interviewer is testing

  • Объясняет механизм своими словами и без выдуманных API.
  • Называет реальные риски, диагностику и критерий корректности.
  • Связывает ответ с текущей документацией и миграционными ограничениями.

Sources

Related topics