Qué es ownership: las tres reglas

Ownership es la idea de la que cuelga todo lo demás en Rust. No es una biblioteca ni una convención de estilo: es una disciplina que el compilador impone y demuestra, y que resuelve —en tiempo de compilación, con coste cero en ejecución— el problema que ha atormentado a los lenguajes de sistemas durante medio siglo: quién libera cada porción de memoria, y cuándo exactamente.

El problema que ownership resuelve

Durante décadas hubo solo dos respuestas a la pregunta “¿quién libera la memoria?”. La primera, la gestión manual de C: tú pides con malloc y tú devuelves con free. Máximo control, pero un campo minado de fugas, dobles liberaciones y use-after-free. La segunda, el recolector de basura de Java, Go o Python: una rutina en ejecución rastrea qué sigue vivo y libera el resto. Cómodo, pero con coste de CPU, pausas y un instante de liberación que tú no eliges.

En Rust la pregunta “¿quién es el dueño de este dato?” se responde en el código y en los tipos, y el compilador la verifica antes de emitir el binario. El resultado: la liberación se inserta automáticamente en el punto correcto.

fn main() {
    let s = String::from("dueño"); // `s` posee un buffer en el heap
    saluda(&s);                    // se lo prestamos, sin cederlo
} // fin de scope: el buffer de `s` se libera aquí, exactamente una vez

fn saluda(nombre: &String) {
    println!("Hola, {nombre}");
}

Fíjate en el detalle clave: en ningún punto del código aparece un free, ni una anotación especial, ni una llamada a un recolector. La liberación está implícita en la estructura del programa y, aun así, es exacta y única.

Las tres reglas

Toda la teoría del ownership cabe en tres frases que el compilador nunca deja de aplicar:

1. Cada valor tiene un dueño: la variable que lo posee.
2. Solo puede haber un dueño a la vez.
3. Cuando el dueño sale de scope, el valor se libera (se ejecuta su drop).

// Regla 1: cada valor tiene un dueño.
let nombre = String::from("Rust"); // `nombre` es el dueño de este String

// Regla 2: solo un dueño a la vez.
let alias = nombre;                // la PROPIEDAD se mueve a `alias`
// a partir de aquí `nombre` ya no es válido: hay un único dueño

// Regla 3: al salir de scope, se libera.
{
    let temporal = String::from("efímero");
    println!("{temporal}");
} // `temporal` sale de scope: su memoria se libera aquí, automáticamente

Cada regla tapa un agujero clásico. La regla 1 impide memoria sin dueño (la fuga). La regla 2 impide dos dueños del mismo buffer (el doble free). La regla 3 impide el use-after-free y el olvido de liberar: el fin de scope es la liberación, y ocurre siempre.

El scope como frontera de vida

Un String vive en dos sitios a la vez. En el stack guarda tres palabras: un puntero al buffer, la longitud y la capacidad. En el heap vive el buffer real de bytes. El dueño es la variable del stack; la regla 3 dice que cuando esa variable muere, Rust libera el buffer del heap que cuelga de ella.

flowchart LR
s[Variable s en el stack] -->|apunta a| buf[Buffer de bytes en el heap]
s -->|sale de scope| free[Se libera el buffer]

fn main() {
    let externo = String::from("vivo todo main");
    {
        let interno = String::from("vivo solo el bloque");
        println!("{interno}");
    } // `interno` muere aquí: su buffer se libera
    println!("{externo}");
} // `externo` muere aquí, después: orden inverso a la creación

Observa el anidamiento: interno nace después que externo y muere antes, respetando el orden de una pila. Ese comportamiento LIFO no es casual, y reaparecerá con nombre propio cuando hablemos de Drop.

El punto de liberación es léxico y predecible: la llave de cierre del bloque donde vive la variable. No hay que adivinarlo ni esperar a un recolector. Esa determinación es lo que convierte al ownership en un sustituto real del GC: sabes el instante exacto de cada liberación con solo leer las llaves.

El árbol de propiedad

De la regla del dueño único sale una estructura elegante: la propiedad forma un árbol. Cada valor tiene exactamente un padre-dueño, y los valores que posee cuelgan de él. Un struct posee sus campos; un Vec<T> posee sus elementos; un Box<T> posee lo que envuelve. No hay ciclos por defecto —para eso hará falta Rc<T>, mucho más adelante—, así que el grafo de propiedad es un bosque de árboles limpios.

struct Nodo {
    nombre: String,
    hijo: Option<Box<Nodo>>,
}

fn main() {
    let raiz = Nodo {
        nombre: String::from("raíz"),
        hijo: Some(Box::new(Nodo {
            nombre: String::from("hoja"),
            hijo: None,
        })),
    };
    println!("{}", raiz.nombre);
} // al morir `raiz`: se libera su String, luego su hijo, y el String del hijo

Liberar raiz es entonces un recorrido en postorden de ese árbol: primero se destruye la raíz, lo que dispara la destrucción de sus campos, que a su vez destruyen los suyos, hasta las hojas. Todo automático, todo determinista, todo demostrado en compilación. La gestión de memoria manual reaparece aquí convertida en una travesía de árbol que tú nunca tienes que programar.

Ownership es un sistema de tipos afín

Bajo la superficie, el ownership es un sistema de tipos afín: cada valor puede usarse como mucho una vez por su dueño. “Como mucho” —y no “exactamente una”— porque un valor puede no usarse nunca y aun así liberarse limpiamente al final del scope. Cuando mueves un valor (regla 2), el compilador marca el origen como no inicializado mediante un análisis de flujo de datos, y prohíbe volver a leerlo. No hay contador de referencias ni rastreo en ejecución: es álgebra sobre el grafo del programa, resuelta antes de compilar.

Que el sistema sea afín, y no lineal, tiene una consecuencia práctica: el origen invalidado no queda muerto para siempre. Puedes reasignarle un valor nuevo y vuelve a la vida como dueño de algo distinto. La invalidación recae sobre el valor movido, no sobre el nombre de la variable.

let mut s = String::from("primero");
let t = s;                    // `s` queda sin valor (movido a `t`)
s = String::from("segundo");  // `s` vuelve a ser dueña, de otro buffer
println!("{s} y {t}");        // ambos válidos: dueños de buffers distintos

De ahí el eslogan de “coste cero”: las llamadas a drop que liberan la memoria las escribe el compilador por ti, en los puntos que su análisis demuestra correctos. El binario resultante no lleva runtime de GC; lleva exactamente los free que tú habrías escrito a mano si fueras infalible.

Esta es también la razón por la que el ownership no tiene coste conceptual oculto: no hay un “recolector” mental que debas modelar en ejecución. El programa se razona igual que se lee una demostración —cada valor entra en scope, se usa a lo sumo una vez como dueño, y sale—. Si sabes leer llaves, sabes leer vidas.