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

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

Чтобы извлечь поле безопасно, его заменяют другим корректным значением — например, через mem::replace или Option::take. Тогда к моменту вызова деструктора структура остаётся полностью валидной.

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

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

Запрет перемещения полей из Drop-типа делает эту гарантию проверяемой статически: деструктор всегда получает объект, находящийся в допустимом состоянии. Это позволяет сочетать автоматическое освобождение ресурсов с безопасностью памяти без анализа содержимого каждого деструктора.

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

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

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

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

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

Вместо перемещения поле сначала заменяют валидным значением:

struct Buffer {
    data: String,
}

impl Drop for Buffer {
    fn drop(&mut self) {
        println!("buffer length: {}", self.data.len());
    }
}

fn extract(buffer: &mut Buffer) -> String {
    std::mem::replace(&mut buffer.data, String::new())
}

После replace исходная структура продолжает владеть пустой строкой, поэтому её Drop может безопасно обратиться к data. Старое значение передаётся вызывающему коду, а новое значение будет уничтожено вместе со структурой.

Для полей типа Option<T> часто используют Option::take: оно заменяет Some(value) на None и возвращает прежнее значение. Это особенно удобно, когда отсутствие ресурса является допустимым состоянием объекта.

Компромисс состоит в необходимости определить корректное замещающее состояние. Если подходящего значения нет, можно изменить дизайн API: предоставить метод, который потребляет всю структуру, либо хранить ресурс в Option. Использование ManuallyDrop и сырой работы с памятью возможно в особых случаях, но переносит ответственность за корректность деструктора на разработчика и требует unsafe.

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

Сервис хранит в структуре сетевое соединение и буфер сообщений. Нужно передать буфер вызывающему коду, но соединение должно остаться внутри структуры и корректно закрыться в Drop.

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

Другой вариант — обернуть буфер в Option и вызвать take. Он оставляет в структуре значение None, явно описывая состояние после извлечения. Такой вариант выбран, если пустой буфер допустим до уничтожения объекта: деструктор проверяет Option, а извлечённый буфер становится независимым владельцем и освобождается у вызывающего кода.

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

Запрещено ли любое извлечение данных из Drop-типа?

Нет. Запрещено именно прямое перемещение поля, оставляющее объект частично перемещённым. Можно переместить всё значение целиком, если операция передаёт владение объектом другому владельцу, а также можно заменить поле новым значением и вернуть старое через mem::replace.

Почему компилятор не проверяет тело drop и не разрешает перемещение неиспользуемого поля?

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

Чем Option::take отличается от обычного перемещения поля?

Option::take выполняет контролируемую замену: прежнее значение извлекается, а на его месте остаётся None. Поэтому структура не становится частично перемещённой и её деструктор может безопасно обработать состояние «ресурс отсутствует». Обычное перемещение поля не оставляет такого значения автоматически и потому запрещено для типа с Drop.