Casos dificiles: estructuras autorreferenciales, temporales y como resolverlos

Hay una frontera donde toda la maquinaria de lifetimes que has dominado deja de tener sintaxis con que expresarse. Es la de las estructuras autorreferenciales: un struct que guarda un dato y, a la vez, una referencia hacia el interior de ese mismo dato. Parece inofensivo, y sin embargo es imposible en Rust seguro por dos razones que se refuerzan: mover el struct invalidaria la referencia interna, y no existe forma de nombrar la region de un campo desde el propio tipo que lo contiene. Su primo cercano —devolver una referencia a un temporal— es el mismo problema disfrazado. Esta leccion final del nivel explica por que estos casos son duros de verdad, no un capricho del checker, y despliega el catalogo de patrones y crates con que la comunidad los resuelve: indices, arenas, Rc, Pin y macros como ouroboros.

Por que la autorreferencia es imposible en Rust seguro

Considera el struct que todo el mundo intenta escribir alguna vez: uno que posee un String y guarda una vista &str hacia dentro de el.

struct AutoRef {
    datos: String,
    vista: &str,   // quiere apuntar a datos, pero... con que lifetime?
}

No compila, y el porque es doble. Primero, no puedes nombrar la region: el campo vista necesita un lifetime, pero la unica region valida seria “tan larga como el propio AutoRef”, y un tipo no puede referirse a su propia vida desde dentro. Cualquier 'a que inventes sera, o bien externo (y entonces vista no apunta a datos, sino a algo de fuera), o bien inexpresable. Segundo, y mas grave: los valores en Rust son movibles por defecto. Si construyes el struct en una direccion y luego lo mueves —al devolverlo, al meterlo en un Vec—, datos viaja a una nueva direccion pero vista seguiria apuntando a la vieja, ya invalida. El borrow checker no prohibe la autorreferencia por pedanteria: la prohibe porque el modelo de moves de Rust la volveria insegura en el instante siguiente.

Su version cotidiana es devolver una referencia a un temporal o a un local, el clasico E0515. Es el mismo fallo —una referencia que sobrevive al dato que la sostiene— y su cura es siempre la misma direccion: dejar de prestar y poseer.

fn mal() -> &String {
    let local = String::from("efimero");
    // &local     // ERROR E0515: el local muere al terminar la funcion
    unreachable!()
}

fn bien() -> String {
    String::from("devuelvo el dueno, sin referencia que pueda colgar")
}

Patrones sin referencias: indices y arenas

La estrategia mas robusta es la mas radical: no usar referencias en absoluto. Si el problema es que una referencia cuelga, sustituyela por algo que no pueda colgar —un indice—. En un grafo o un arbol, en vez de que cada nodo apunte a otro con &Nodo, guardas todos los nodos en un Vec<Nodo> y los enlazas con usize. Los indices no tienen lifetime, no se invalidan al mover el Vec, y rompen los ciclos sin drama.

struct Arbol { nodos: Vec<Nodo> }
struct Nodo { valor: i32, hijo: Option<usize> }   // indice, no referencia: nunca cuelga

impl Arbol {
    fn valor_del_hijo(&self, i: usize) -> Option<i32> {
        self.nodos[i].hijo.map(|h| self.nodos[h].valor)
    }
}

El punto debil de los indices desnudos es que un indice viejo puede apuntar a una ranura reutilizada tras un borrado —el problema ABA—. La solucion madura son los indices generacionales: cada ranura lleva un contador de generacion, y el indice guarda la generacion que vio; si no coinciden, el acceso falla en vez de leer datos ajenos. Crates como slotmap y slab implementan justo esto y son el estandar para grafos mutables.

Cuando de verdad necesitas referencias entre nodos —no indices—, la respuesta es la arena: un asignador que reserva todos los objetos con un lifetime comun 'arena. Como todas las referencias comparten esa region, pueden apuntarse entre si libremente, incluso en ciclos, y se liberan todas de golpe al caer la arena. Crates como bumpalo y typed-arena te dan exactamente esto.

// Con typed-arena: todos los nodos comparten 'arena, asi que las referencias mutuas son legales.
// let arena = typed_arena::Arena::new();
// let a: &Nodo = arena.alloc(Nodo::nuevo());
// let b: &Nodo = arena.alloc(Nodo::nuevo());
// a y b viven ambos en 'arena; pueden referenciarse sin que ninguno cuelgue antes que el otro.

Cuando necesitas la autorreferencia de verdad: Pin y los crates

A veces no puedes evitarla: la propia async de Rust genera futuros autorreferenciales, porque un .await guarda referencias a variables locales que viven en el mismo futuro. La respuesta del lenguaje fue Pin: un envoltorio que garantiza que el valor no se movera de su direccion, eliminando de raiz la mitad insegura del problema (la invalidacion al mover). Pin no te deja escribir la referencia interna en seguro —eso sigue requiriendo unsafe—, pero da el cimiento sobre el que construir autorreferencia correcta, y es la razon de que async funcione sin coste oculto.

Para el caso general, la comunidad encapsula ese unsafe en crates que ofrecen una API segura:

El patron Rc/RefCell/Weak merece verse escrito, porque es la via directa para un grafo con ciclos como un arbol con punteros al padre: los hijos se poseen con Rc, pero la vuelta al padre usa Weak para no cerrar un ciclo de conteos que nunca llegaria a cero.

use std::rc::{Rc, Weak};
use std::cell::RefCell;

struct Nodo {
    valor: i32,
    padre: RefCell<Weak<Nodo>>,       // Weak: no suma al conteo fuerte, rompe el ciclo
    hijos: RefCell<Vec<Rc<Nodo>>>,    // Rc: el padre si posee a sus hijos
}
// El padre mantiene vivos a los hijos (Rc); el hijo solo observa al padre (Weak).
// Sin el Weak, padre e hijo se sostendrian mutuamente y jamas se liberarian: fuga.

flowchart TB
p[Necesito referencias que se cruzan o hacia mi mismo] --> q1[Puedo usar indices en vez de referencias?]
q1 -->|si| idx[Vec mas usize; slotmap para indices generacionales]
q1 -->|no| q2[Comparten un mismo ambito de vida?]
q2 -->|si| ar[Arena con lifetime comun: bumpalo o typed-arena]
q2 -->|no| q3[Propiedad compartida con posibles ciclos?]
q3 -->|si| rc[Rc y RefCell con Weak para cortar ciclos]
q3 -->|autorreferencia real| pin[Pin mas unsafe, o crate ouroboros o self_cell]