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

Rust использует нелексические времена жизни (NLL): заимствование обычно считается завершённым не в конце текстовой области видимости ссылки, а после её последнего фактического использования. Поэтому после последнего чтения компилятор может разрешить изменение владельца, даже если переменная-ссылка формально ещё доступна по области видимости.

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

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

Модель владения Rust должна обеспечивать освобождение ресурсов и отсутствие ошибок вроде использования освобождённой памяти или одновременного небезопасного чтения и изменения без сборщика мусора. Для этого компилятор анализирует продолжительность заимствований во время компиляции.

Изначально анализ часто был привязан к лексическим блокам. Такой подход был безопасным, но излишне консервативным: ссылка могла фактически больше не использоваться, однако компилятор продолжал считать заимствование активным до конца блока. NLL сделал анализ точнее, сохранив те же правила безопасного доступа к памяти.

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

Область видимости переменной и время действия заимствования — разные понятия. Переменная-ссылка может оставаться объявленной, но если программа больше не обращается к ней, удерживать заимствование до конца блока нет необходимости.

Если ошибочно считать такое заимствование активным всегда, безопасные последовательности чтения и последующего изменения пришлось бы искусственно разделять дополнительными блоками или копированием. Это ухудшает читаемость и иногда приводит к лишним затратам памяти.

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

Компилятор анализирует использования ссылки и строит область, в течение которой заимствование действительно требуется. Для неизменяемой ссылки эта область включает чтения из значения и заканчивается после последнего использования, если ссылка не должна сохраняться дольше по другим ограничениям.

fn main() {
    let mut text = String::from("Rust");
    let view = &text;
    println!("{}", view);
    text.push('!');
    println!("{}", text);
}

В примере view формально находится в области видимости до конца функции, но последнее обращение к нему происходит в первом вызове println!. После этого заимствование завершено, поэтому text можно изменить.

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

NLL не позволяет одновременно иметь активное неизменяемое чтение и несовместимую изменяющую операцию. Он лишь точнее определяет момент окончания чтения. Владение, правила совместимости ссылок и требование, чтобы ссылка не переживала владельца, сохраняются.

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

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

Возможны три подхода:

Скопировать заголовок — просто рассуждать о времени жизни, но это создаёт лишнее выделение или копирование.
Использовать отдельный внутренний блок — надёжно ограничивает заимствование, но добавляет структурный шум и иногда требует перестройки логики.
Положиться на NLL — не требует копии и сохраняет естественный порядок операций, если ссылка действительно не используется после проверки.

Оптимальным обычно является третий вариант. Если же ссылка нужна в дальнейшем, NLL не поможет: следует либо перенести изменение после последнего использования ссылки, либо явно ограничить её блоком, либо изменить структуру данных и границы владения.

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

Означает ли NLL, что компилятор завершает заимствование сразу после любого последнего на данный момент чтения?

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

Почему сама переменная-ссылка остаётся в области видимости, но уже не блокирует изменение владельца?

Область видимости определяет, где имя можно написать в исходном тексте. Время действия заимствования определяет, как долго компилятор обязан обеспечивать корректность доступа через это имя. После последнего использования ссылка может оставаться формально доступной, но любое новое обращение к ней после конфликтующей записи снова было бы недопустимо; поэтому компилятор не считает неиспользуемое имя активным заимствованием.

Разрешит ли NLL изменение, если неизменяемая ссылка используется внутри условной ветки после потенциальной записи?

Нет, если существует путь выполнения, на котором ссылка реально используется после записи. Анализ учитывает возможные контрольные потоки: заимствование должно оставаться действительным во всех местах, где ссылка может потребоваться. Чтобы разрешить изменение, нужно гарантировать, что все использования ссылки завершены до него, например перестроить порядок операций или ограничить ссылку отдельным блоком.