Respuesta.

Historia de la pregunta

RAII (Resource Acquisition Is Initialization) es una idiomática que proviene de C++, en la que el tiempo de vida de un recurso está estrictamente ligado al tiempo de vida de un objeto en la pila. En Rust, este concepto ha sido fundamental para el sistema de propiedad y liberación de recursos, lo que permite prescindir de recolectores de basura clásicos (GC).

Problema

Muchos lenguajes gestionan la memoria y los recursos a través de un recolector de basura que periódicamente "limpia" objetos no necesarios. Esta estrategia aumenta la latencia y no garantiza la liberación inmediata de recursos externos (archivos, sockets, etc.). En la programación de bajo nivel y sistemas, tal situación es inaceptable: se necesita precisión y determinación en la gestión del recurso.

Solución

En Rust, cada objeto posee su propio recurso y lo libera estrictamente cuando sale del ámbito (out of scope), a través de la llamada a Drop (el equivalente a un destructor). Como resultado, los recursos se liberan de inmediato y todos los errores de liberación implícita se reducen al mínimo. El sistema de tipos y propiedad de Rust previene fugas de memoria y liberaciones dobles casi en la etapa de compilación.

Ejemplo de código:

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

impl Drop for FileWrapper {
    fn drop(&mut self) {
        println!("FileWrapper cierra el archivo! (salida de ámbito)");
    }
}

fn main() {
    let _fw = FileWrapper { file: std::fs::File::create("test.txt").unwrap() };
    // Al salir de main, Drop se llama garantizadamente
}

Características clave:

RAII garantiza la liberación de recursos sincrónicamente con la salida del ámbito.
No es necesario llamar manualmente a la liberación, como en C o C++, y no hay "sorpresas" del GC.
Funciona para todos los recursos, no solo para la memoria (bloqueos, descriptores, archivos, etc.).

Preguntas engañosas.

¿Se llama a Drop para valores que han sido movidos (moved) anteriormente?

No, después de mover un valor, Drop solo se llama para el nuevo propietario, el objeto antiguo se considera "vacío" y Drop no se ejecuta.

let file1 = FileWrapper {...};
let file2 = file1; // file1 move
// Drop se llamará una vez — para file2

¿Puede panic! o unwrap() en medio del ámbito impedir la llamada a drop?

No, un pánico o salida por error no cancela la llamada al destructor — Drop se llamará necesariamente para todos los objetos que salieron del ámbito.

Si una referencia posee un objeto, ¿se llamará a drop al finalizar el tiempo de vida de la referencia?

No, drop solo se llama para el propietario del objeto, las referencias no poseen. Para recursos en heap, se necesita un puntero inteligente.

Errores típicos y antipatrón

Esperar que Drop se ejecute para una referencia o no propietario — conducirá a fugas de recursos.
Mover un recurso a Rc/Arc sin comprender la propiedad compartida — el objeto no se liberará mientras haya al menos un Rc.

Ejemplo de la vida real

Caso negativo

Un desarrollador pasó un descriptor de archivo por referencia a una función para escribir. Después de que finalizó el programa, el archivo quedó bloqueado porque drop no se llamó (no había propietario, se utilizó una referencia).

Pros:

Fácil de implementar un prototipo.

Contras:

El archivo quedó bloqueado.
Fuga de descriptor.

Caso positivo

La propiedad del recurso siempre se transfería a estructuras que implementan Drop. Todos los archivos abiertos, conexiones o bloqueos se liberan automáticamente al finalizar el ámbito o en caso de pánico. Un margen para gestionar recursos de manera segura y trivial incluso en proyectos complejos.