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

При передаче &mut T в функцию Rust обычно создаёт временное повторное заимствование — reborrow, а не окончательно перемещает саму ссылку. Это временное заимствование действует на время вызова, после чего исходную изменяемую ссылку можно использовать снова.

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

В системах с ручным управлением памятью независимое существование ссылок на изменяемые данные может привести к use-after-free, гонкам и несогласованным значениям. Rust решает эту проблему статически: владение, время жизни и совместимость доступа проверяются компилятором без сборщика мусора.

Для этого Rust различает совместимые режимы доступа: множество общих ссылок либо одну изменяемую ссылку. Механизм reborrow позволяет временно передать доступ другой функции, не нарушая исходную модель владения.

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

Тип &mut T сам по себе не реализует Copy, поэтому буквальное перемещение значения такой ссылки сделало бы исходную переменную недоступной. Однако обычная передача изменяемой ссылки в функцию должна позволять последовательно вызывать несколько операций над одними данными.

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

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

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

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

fn add_one(value: &mut i32) {
    *value += 1;
}

fn main() {
    let mut number = 0;
    let reference = &mut number;

    add_one(reference);
    add_one(reference);
    *reference += 1;
}

В примере reference не перемещается окончательно: вызовы используют временные повторные заимствования. При этом во время каждого вызова нельзя одновременно использовать reference для другого доступа к тому же значению.

Это поведение зависит от контекста. Если ссылку передают параметру обобщённой функции, принимающему произвольный тип T, компилятор может переместить саму ссылку как значение T, потому что ожидаемый тип уже не задаёт &mut-параметр для повторного заимствования.

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

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

Представим обработчик буфера, который последовательно вызывает несколько этапов обработки. Каждый этап принимает &mut Vec<u8>, поэтому обработчик должен передавать один и тот же буфер нескольким функциям.

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

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

Выбранный вариант — принимать &mut Vec<u8> в каждом этапе. Rust создаёт отдельное короткое повторное заимствование на каждый вызов, поэтому этапы выполняются последовательно, не получают одновременный доступ и не требуют передачи владения.

Результат — безопасный интерфейс без копирования буфера. Если один этап должен вернуть ссылку, сохранить её или передать в долгоживший объект, границу времени жизни нужно анализировать отдельно: тогда следующий этап может стать недоступен до завершения этого заимствования.

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

Почему Rust не делает &mut T копируемым, если повторное заимствование всё равно позволяет использовать исходную ссылку?

&mut T не реализует Copy, потому что копирование создало бы две независимые изменяемые ссылки на один объект. Это нарушило бы гарантию единственности доступа. Reborrow не копирует ссылку без ограничений: он создаёт временный доступ с контролируемым временем жизни, а исходная ссылка на этот период блокируется.
Когда исходная изменяемая ссылка всё-таки остаётся недоступной после вызова?

Это происходит, если заимствование продолжается после вызова. Например, функция может вернуть ссылку, связанную с входным заимствованием, или полученная ссылка может быть сохранена в объекте, который живёт дольше. Пока такое повторное заимствование активно, использование исходной ссылки конфликтовало бы с эксклюзивным доступом и отклоняется компилятором.
Почему передача той же ссылки в функцию с параметром произвольного типа может привести к перемещению?

Для параметра вида T компилятор не обязан трактовать аргумент как &mut-параметр, требующий reborrow. Значение ссылки может быть передано как обычное значение типа T, а поскольку &mut T не является Copy, исходная переменная после этого перемещения недоступна. Поэтому сигнатура функции влияет не только на тип аргумента, но и на выбранный семантический механизм передачи.