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

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

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

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

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

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

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

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

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

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

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

Минимальный пример:

fn main() {
    let mut values = vec![10, 20];
    let first = &values[0];
    println!("{}", first);
    values.push(30);
    println!("{}", first);
}

В этом примере push запрещён, поскольку first используется после него. Компилятор не обязан доказывать, что конкретно этот вызов не вызовет перераспределение: контракт операции изменения Vec в общем случае допускает изменение расположения элементов, а правило заимствования должно быть статически надёжным.

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

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

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

Допустим, обработчик читает ссылку на первый элемент очереди, а затем должен добавить в очередь новый элемент. Вариант с одновременным хранением ссылки и вызовом push не компилируется: добавление может изменить буфер, а ссылка должна оставаться валидной.

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

Если требуется стабильный адрес объекта независимо от перемещения элементов контейнера, объект можно поместить в отдельное владеющее выделение, например Box<T>, а в Vec хранить такие указатели. Это уменьшает риск перемещения самого объекта, но добавляет косвенный доступ и стоимость отдельных выделений; кроме того, правила заимствования самого контейнера всё равно нужно учитывать.

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

Вопрос: Достаточно ли вызвать reserve, чтобы затем безопасно изменить Vec при активной ссылке на его элемент?

Ответ: Нет. reserve действительно может обеспечить запас ёмкости, но вызов сам получает изменяемый доступ к Vec. Активная ссылка на элемент сохраняет неизменяемое заимствование его содержимого, поэтому конфликт возникает ещё до рассуждения о фактическом перераспределении.
Вопрос: Почему Rust иногда разрешает push после получения ссылки на элемент, хотя ссылка была создана раньше?

Ответ: Важен не только конец лексического блока, но и последнее фактическое использование ссылки. Благодаря анализу неиспользуемых заимствований компилятор может завершить заимствование сразу после последнего чтения; если после этого ссылка не применяется, изменяемая операция становится допустимой.
Вопрос: Устраняет ли хранение элементов в Box запрет на изменение размера Vec при ссылке на элемент?

Ответ: Не обязательно. Перераспределение Vec перемещает сами значения Box, то есть указатели, а объекты внутри выделений обычно сохраняют адрес. Однако ссылка вида &Box<T> всё равно заимствует элемент вектора, поэтому обычный вызов изменения Vec конфликтует с этим заимствованием; для ссылки непосредственно на T могут оставаться другие ограничения, связанные с тем, как она получена и используется.