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

Локальные переменные с реализацией Drop уничтожаются в обратном порядке объявления: последняя объявленная переменная уничтожается первой. При этом вложенная область видимости завершается раньше внешней, а явный вызов drop может уничтожить значение до естественного выхода из области.

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

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

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

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

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

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

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

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

Для локальных переменных порядок определяется их drop scope. При выходе из области видимости Rust уничтожает переменные в обратном порядке объявления внутри этой области. Сначала завершаются вложенные области, затем уничтожаются переменные внешней области.

Если значение передано в std::mem::drop, оно уничтожается в точке этого вызова, потому что владение им передано функции drop. После этого переменная больше не содержит доступного значения и повторное использование перемещённого значения запрещено.

struct Marker(&'static str);

impl Drop for Marker {
    fn drop(&mut self) {
        println!("drop {}", self.0);
    }
}

fn main() {
    let first = Marker("first");
    let second = Marker("second");
    {
        let inner = Marker("inner");
    }
}

Результат будет таким:

drop inner
drop second
drop first

Переменная inner уничтожается при выходе из внутреннего блока. Затем при выходе из main уничтожаются second и first — в обратном порядке их объявления.

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

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

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

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

Другой вариант — явно вызвать drop для журнала перед выходом из блока. Его плюс — порядок становится очевидным и не зависит от перестановки последующих объявлений. Минус — появляется ручная точка управления временем жизни, которую нужно поддерживать при изменении кода.

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

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

Меняется ли порядок уничтожения из-за последнего использования переменной?

Нет, для значений с наблюдаемым Drop нельзя считать последнюю точку использования моментом уничтожения. Основное правило задаётся областью уничтожения и порядком объявления; если нужно завершить ресурс раньше, следует использовать отдельный блок или явный drop.

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

Что уничтожается раньше: структура с Drop или её поля?

Сначала вызывается реализация Drop самой структуры. После завершения этого метода Rust автоматически уничтожает поля структуры в порядке их объявления.

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

Как влияет явный drop на последующее использование имени?

std::mem::drop принимает значение по значению, поэтому вызов передаёт ему владение и немедленно запускает уничтожение. Для типа, не реализующего Copy, исходное имя после этого считается перемещённым и использовать его нельзя.

Это отличается от передачи ссылки в функцию: ссылка временно заимствует значение и не уничтожает владельца. Явный drop применяют, когда ресурс нужно освободить раньше окончания области видимости, например чтобы как можно раньше снять блокировку.