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

Проверка уничтожения (drop check) рассматривает реализацию Drop консервативно: деструктор потенциально может обратиться к обобщённым полям во время уничтожения значения. Поэтому параметр типа, способный содержать ссылки, должен жить достаточно долго — как минимум до момента уничтожения объекта с деструктором. Тело drop обычно не анализируется настолько подробно, чтобы доказать отсутствие таких обращений.

Иными словами, Drop не продлевает время жизни данных, но может сузить множество допустимых связей между временем жизни объекта и его параметрами.

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

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

Подход с drop check решает исходную проблему использования уже уничтоженных данных в деструкторах. Вместо попытки доказать безопасность каждого тела drop компилятор применяет консервативные правила к типам, имеющим Drop.

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

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

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

struct Guard<'a, T: 'a> {
    reference: &'a T,
    value: T,
}

impl<'a, T: 'a> Drop for Guard<'a, T> {
    fn drop(&mut self) {}
}

Здесь ограничение T: 'a означает, что ссылки, содержащиеся внутри T, не должны быть короче 'a. Это позволяет безопасно рассматривать Guard как объект, который может обращаться к своим полям до их уничтожения.

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

Без Drop компилятор может точнее учитывать порядок уничтожения отдельных полей. Когда пользовательский деструктор присутствует, сначала вызывается drop, а только затем автоматически уничтожаются поля. Следовательно, во время drop все поля ещё существуют и потенциально доступны.

Ограничение T: 'a не означает, что само значение T обязательно хранится 'a или что его жизнь продлевается. Оно означает, что любые заимствованные данные, необходимые для корректного использования T, должны пережить 'a.

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

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

Важно отличать drop check от обычной проверки времени жизни ссылок. Обычная проверка анализирует, может ли ссылка использоваться в конкретном месте. Drop check дополнительно проверяет, безопасно ли существование объекта до его уничтожения с учётом возможного поведения деструктора.

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

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

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

удалить ненужную реализацию Drop. Плюс — компилятор получает больше свободы при анализе времени жизни; минус — исчезает гарантированное действие при уничтожении;
изменить дизайн и хранить владеющие данные вместо заимствованных. Плюс — меньше ограничений времени жизни и проще API; минус — возможны дополнительные копирования или расход памяти;
оставить Drop и явно обеспечить требуемые связи времени жизни. Плюс — сохраняется автоматическая очистка; минус — вызывающий код должен дольше удерживать заимствованные данные.

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

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

Дополнительный вопрос 1: достаточно ли того, что тело drop не обращается к проблемному полю?

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

Дополнительный вопрос 2: продлевает ли Drop жизнь данных, на которые ссылается объект?

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

Дополнительный вопрос 3: почему удаление Drop иногда устраняет ошибку времени жизни?

Без пользовательского деструктора компилятор знает стандартный порядок уничтожения полей и может разбирать зависимости между ними точнее. Наличие Drop добавляет потенциальный этап доступа к полям до их автоматического уничтожения, поэтому появляются дополнительные требования вроде T: 'a. Удаление деструктора убирает этот потенциальный доступ, но, разумеется, также убирает выполняемую при уничтожении логику.