Ответ.

История вопроса:

В Rust управление ресурсами без сборщика мусора стало возможным благодаря строгим правилам владения и жизненного цикла объектов. Для автоматизации освобождения ресурсов (например, дескрипторов файлов, сокетов, памяти от сторонних библиотек) с самого начала разработки языка был введён trait Drop. Это основной способ «реакции» на окончание жизни объекта, который применяется для финализации и возврата ресурсов операционной системе или освобождения памяти.

Проблема:

Обычные типы Rust автоматически очищают собственные ресурсы, но когда структура хранит ресурс, требующий ручного освобождения (например, открытый файл или небезопасный указатель), нежелание или забывчивость разработчика могут вызвать утечки или гонки ресурсов. Если Drop реализован неправильно (например, не учтена возможность двойного освобождения памяти), это может привести к ошибкам времени выполнения.

Решение:

Trait Drop позволяет определить специальный метод drop(&mut self), который вызывается автоматически при уничтожении значения. Он подходит для release ресурсов именно тогда, когда объект выходит за границы видимости. Важно помнить, что освобождать ресурс (например, закрывать файл) нужно только здесь.

Пример кода:

struct RawFile {
    handle: *mut libc::FILE,
}

impl Drop for RawFile {
    fn drop(&mut self) {
        if !self.handle.is_null() {
            unsafe {
                libc::fclose(self.handle);
            }
        }
    }
}

Ключевые особенности:

Метод drop не вызывается явно — только компилятором.
Drop реализуется только для структуры, которая владеет не-Rust ресурсом.
Drop не срабатывает при утечке через mem::forget или panic! по умолчанию (за пределами unwinding).

Вопросы с подвохом.

Можно ли вызвать drop явно для объекта, чтобы освободить ресурс раньше времени?

Нет, напрямую вызвать метод drop (&obj.drop()) запрещено — только через функцию std::mem::drop(obj), которая принимает владение объектом и вызывает drop автоматически. Вызов drop() напрямую не компилируется.

Пример кода:

fn main() {
    let f = File::open("foo.txt").unwrap();
    // drop(&mut f); // Ошибка компиляции!
    std::mem::drop(f); // Правильно: закрытие файла
}

Что произойдет, если структура с Drop попадет под memcpy или move? Не вызовется ли деструктор дважды?

Нет, деструктор всегда вызывается ровно один раз за весь жизненный цикл объекта, и компилятор следит за этим. Но если делать unsafe копирование "сырых" байт структуры или использовать mem::forget, drop может не вызваться вовсе — отсюда опасность.

Можно ли реализовать Drop и Copy одновременно для одного и того же типа?

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

Типовые ошибки и анти-паттерны

Прямой вызов drop метода (нельзя)
Несвободный ресурс или нераскрытый файл из-за забывания Drop
Использование после освобождения (use after free) через неосторожный ptr
Имплементация Drop одновременно с Copy (Compile error)
Сложные цепочки владения, где порядок drop критичен

Пример из жизни

Негативный кейс

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

Плюсы:

Нет избыточного кода, структура простая для понимания

Минусы:

После выхода файла из области видимости дескриптор остается открытым
Может дойти до исчерпания дескрипторов и отказа операционной системы

Позитивный кейс

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