Odpowiedź.

Historia pytania

RAII (Resource Acquisition Is Initialization) — idiom, który pochodzi z C++, w którym czas życia zasobu jest ściśle związany z czasem życia obiektu na stosie. W Rust koncepcja ta stała się fundamentem systemu własności i zwolnienia zasobów, co pozwala na ominięcie klasycznych zbieraczy śmieci (GC).

Problem

Wiele języków zarządza pamięcią i zasobami za pomocą zbieracza śmieci, który okresowo "czyści" niepotrzebne obiekty. Strategia ta zwiększa opóźnienia i nie daje gwarancji natychmiastowego zwolnienia zewnętrznych zasobów (plików, gniazd itp.). W niskopoziomowym i systemowym programowaniu taka sytuacja jest niedopuszczalna: potrzebna jest precyzja i deterministyczne zarządzanie zasobem.

Rozwiązanie

W Rust każdy obiekt posiada swój zasób i zwalnia go ściśle w miejscu zniszczenia (out of scope), poprzez wywołanie Drop (podobne do destruktora). W rezultacie zasoby są zwalniane natychmiast, a wszystkie błędy niewidocznego zwolnienia są zminimalizowane. System typów i własności w Rust zapobiega wyciekom oraz podwójnemu zwolnieniu prawie już na etapie kompilacji.

Przykład kodu:

struct FileWrapper {
    file: std::fs::File,
}

impl Drop for FileWrapper {
    fn drop(&mut self) {
        println!("FileWrapper zamyka plik! (wyjście z zakresu)");
    }
}

fn main() {
    let _fw = FileWrapper { file: std::fs::File::create("test.txt").unwrap() };
    // Przy wyjściu z main, drop jest gwarantowanie wywoływane
}

Kluczowe cechy:

RAII gwarantuje zwolnienie zasobów synchronicznie z wyjściem z zakresu.
Nie ma potrzeby ręcznego wywoływania zwolnienia, jak w C czy C++, i nie ma "niespodzianek" od GC.
Działa dla wszystkich zasobów, nie tylko dla pamięci (blokady, deskryptory, pliki itp.).

Pytania z pułapkami.

Czy Drop jest wywoływane dla wartości, które wcześniej zostały przeniesione (moved)?

Nie, po przeniesieniu wartości Drop jest wywoływane tylko dla nowego właściciela, stary obiekt jest uznawany za "pusty" i Drop nie działa.

let file1 = FileWrapper {...};
let file2 = file1; // file1 move
// Drop wywoła się tylko raz — dla file2

Czy panic! lub unwrap() w środku zakresu mogą przeszkodzić w wywołaniu drop?

Nie, panika lub wyjście z błędem nie anulują wywołania destruktora — Drop na pewno wywoła się dla wszystkich obiektów, które opuściły zakres.

Jeśli odniesienie posiada obiekt, czy drop zostanie wywołane przy zakończeniu czasu życia odniesienia?

Nie, drop jest wywoływane tylko dla właściciela obiektu, odniesienia nie mają własności. Dla zasobów na stercie potrzebny jest wskaźnik inteligentny.

Typowe błędy i antywzorce

Oczekiwanie, że Drop zadziała dla odniesienia lub nie-właściciela — prowadzi do wycieku zasobów.
Przeniesienie zasobu do Rc/Arc bez zrozumienia shared-ownership — obiekt nie zostanie zwolniony, póki istnieje choćby jeden Rc.

Przykład z życia

Negatywny przypadek

Programista przesłał deskryptor pliku przez odniesienie do funkcji pisania. Po zakończeniu pracy programu plik pozostał zablokowany, ponieważ drop nie został wywołany (nie było właściciela, użyto odniesienia).

Zalety:

Łatwo zaimplementować prototyp

Wady:

Lock-pliku nie zdjęto
Wyciek deskryptora

Pozytywny przypadek

Własność zasobu zawsze była przekazywana przez struktury, które realizują Drop. Wszystkie otwarte pliki, połączenia lub blokady są automatycznie zwalniane przy zakończeniu zakresu lub panic. Kart blanche na bezpieczne i trywialne zarządzanie zasobami nawet w trudnych projektach.