Практическая ситуация: объясните, почему одна передача удовлетворяет ограничению T: 'static, а другая — нет...

fn accept<T: 'static>(_: T) {}

fn main() {
    {
        let text = String::from("hello");
        accept(text);
    }
    {
        let text = String::from("hello");
        accept(&text); // ошибка компиляции
    }
}

Краткий ответ

T: 'static означает, что тип T не содержит ссылок с временем жизни короче 'static; это не означает, что само значение обязано жить до завершения программы. Поэтому принадлежащий вызывающему коду String подходит: он владеет своими данными. &text не подходит, потому что это ссылка на локальную переменную, которая гарантированно станет недействительной после выхода из блока.

Исторический контекст

В Rust время жизни используется как статическое ограничение безопасности: компилятор должен доказать, что ни одна ссылка не переживёт данные, на которые она указывает. Ограничение T: 'static позволяет обобщённому коду принимать значение без необходимости знать конкретный срок жизни содержащихся в нём ссылок.

Такой подход особенно важен для API, которые могут сохранить значение надолго или передать его в другой поток. Вместо ручного управления временем жизни вызывающий код передаёт либо владеющее значение, либо тип, внутри которого нет краткоживущих заимствований.

Постановка проблемы

У типа String данные находятся во владении самого значения. После вызова accept(text) значение перемещается в функцию, поэтому внутри accept нет ссылки на локальную переменную вызывающего кода.

У типа &String другое устройство: это заимствованная ссылка, указывающая на text. Её срок действия ограничен блоком, в котором создана text. Если разрешить такой аргумент для T: 'static, функция получила бы возможность сохранить ссылку дольше существования исходной переменной.

Подробное решение

Запись T: 'static проверяет не фактическую длительность жизни конкретного значения, а его типовое свойство: значение типа T не должно содержать ссылок, которым требуется срок короче 'static. 'static здесь означает «может быть корректно использован на протяжении всей программы», а не обязательное размещение в статической памяти.

String удовлетворяет этому ограничению, потому что его тип владеет буфером. Сам объект String можно создать и уничтожить внутри блока, но в нём нет ссылки на локальные данные, которая могла бы стать висячей.

&text имеет тип примерно &'локальная_жизнь String. Эта ссылка не удовлетворяет 'static, поскольку 'локальная_жизнь заканчивается при выходе из блока. Аннотация или ограничение T: 'static не продлевает жизнь text и не превращает заимствование во владение.

Ограничение также допускает типы с действительно статическими данными, например &'static str, полученный из строкового литерала. Однако для обобщённого параметра T: 'static обычно предпочтительнее передавать владеющие значения, если API может сохранить их.

Важно отличать T: 'static от типа &'static T. Первое говорит об отсутствии короткоживущих ссылок внутри T; второе описывает конкретную ссылку, которая сама действительно должна быть действительна весь срок 'static.

fn accept<T: 'static>(_: T) {}

fn main() {
    let owned = String::from("hello");
    accept(owned); // корректно: String владеет данными

    let borrowed = String::from("hello");
    // accept(&borrowed); // ошибка: ссылка короче 'static
}

Компромисс состоит в том, что T: 'static делает API менее гибким для заимствованных данных, зато позволяет безопасно хранить значение или передавать его туда, где срок хранения заранее не ограничен. Если сохранение не требуется, более слабое ограничение часто будет лучше.

Ситуация из практики

Предположим, обработчик передаётся в новый поток. Поток может продолжать работу после возврата текущей функции, поэтому замыкание не должно содержать ссылок на локальные переменные этой функции.

Можно передать ссылку с ограниченным сроком жизни, но такой вариант не проходит проверку: поток потенциально переживёт данные. Можно применить move и переместить во владение потока String; это безопасно и обычно является выбранным решением. Недостаток — исходный код больше не владеет перемещённым значением и должен заранее продумать передачу владения.

Третий вариант — использовать разделяемое владение, например Arc<String>. Он позволяет нескольким потокам владеть данными одновременно, но добавляет стоимость атомарного подсчёта ссылок и требует учитывать ограничения Send и Sync. Выбор move с String предпочтителен, когда владельцем должен стать только новый поток; Arc нужен при реальном совместном владении.

Что кандидаты часто упускают

1. Вопрос: Обязано ли значение типа T: 'static жить до завершения программы?

   Ответ: Нет. 'static относится к допустимым заимствованиям внутри типа, а не к фактическому сроку существования значения. Локальный String удовлетворяет T: 'static и может быть уничтожен сразу после выхода из области видимости.

2. Вопрос: Почему String удовлетворяет T: 'static, а &String — нет, хотя оба значения могут находиться на стеке?

   Ответ: Место размещения значения не определяет это ограничение. String содержит владение буфером и не заимствует локальные данные, тогда как &String содержит ссылку с конкретным ограниченным сроком жизни. Именно возможность пережить исходный объект, а не стек или куча, является существенной.

3. Вопрос: Можно ли передать ссылку в функцию с T: 'static, если сделать ссылку move?

   Ответ: Нет. move меняет способ захвата или передачи владения, но не продлевает срок жизни заимствованных данных. Замыкание move всё ещё не удовлетворит T: 'static, если внутри него находится ссылка на локальную переменную; нужно переместить сами данные либо использовать владельший контейнер, например String или подходящий Arc.