Polonius: el borrow checker de nueva generación

NLL enseñó al compilador a medir la vida real de cada préstamo, pero se quedó con un punto ciego: cuando una función devuelve una referencia solo en algunos caminos, NLL la considera viva en todos, y rechaza código perfectamente seguro. Polonius es la reformulación de nueva generación del borrow checker que cierra ese hueco. En vez de preguntar “¿hasta dónde vive esta referencia?”, pregunta “¿qué préstamos podrían estar en uso en este punto exacto del flujo?”, y esa inversión le permite aceptar programas sanos que NLL, por conservador, nunca pudo.

Qué le faltaba a NLL

Recupera el patrón que cerró la lección anterior: una función que devuelve un préstamo en una rama y muta el contenedor en otra. Es idiomático, es seguro, y NLL lo rechaza.

fn ultimo_o_insertar(v: &mut Vec<i32>) -> &i32 {
    if let Some(x) = v.last() {   // préstamo de `v` para obtener `x`
        return x;                  // ...que solo se usa en ESTE camino
    }
    v.push(0);                     // ERROR bajo NLL: cree que el préstamo sigue vivo
    v.last().unwrap()
}

El problema de NLL es de granularidad. NLL modela el préstamo con una vida —una región del grafo— y, para que el return x sea válido, esa región debe extenderse hasta la salida de la función. Pero una vez extendida, NLL la ve viva también en el camino del else, donde en realidad no devolvimos nada y el préstamo ya no importa. NLL no sabe decir “vivo en este camino, muerto en aquel”; solo maneja una región única que, o cubre el return, o no. Al cubrirlo, envenena el otro camino y el push choca contra un fantasma.

La raíz es que la vida de un préstamo, como región, tiene que ser convexa sobre el grafo: un solo trozo continuo que abarca todos sus usos. Cuando los usos viven en ramas distintas que se reúnen más adelante, esa región convexa engorda hasta cubrir puntos donde el préstamo, camino a camino, ya estaba muerto. Es una imprecisión inherente al modelo, no un fallo de implementación, y ninguna cantidad de afinado de NLL la elimina: hace falta cambiar de teoría.

Cómo razona Polonius: orígenes que fluyen por el grafo

Polonius invierte la pregunta. NLL parte de cada referencia y calcula hasta dónde vive su préstamo. Polonius parte de cada punto del programa y calcula qué préstamos podrían usarse a partir de aquí —lo que su teoría llama los orígenes (origins) vivos en ese punto—. La diferencia suena sutil, pero lo cambia todo: al razonar punto por punto sobre el grafo de flujo, Polonius distingue naturalmente el camino del return del camino del else.

En términos operativos, Polonius reformula el borrow checking como un problema de análisis de flujo al estilo Datalog: un conjunto de hechos —“aquí nace el préstamo L”, “aquí se accede a través de él”, “este punto sucede tras aquel”— y reglas que propagan qué orígenes siguen vivos en cada arista. Un préstamo mutable en un punto es un error solo si, en ese punto concreto, algún origen incompatible sigue vivo. En ultimo_o_insertar, cuando el flujo llega al push, el único origen que lo alcanzaría es el del camino que ya hizo return: en el camino del else ese origen está muerto, así que no hay conflicto y el push se acepta.

Puedes visualizar esos hechos casi como una base de datos que se consulta punto a punto. Anotando la misma función con los orígenes y los puntos de interés, se ve dónde vive y dónde muere cada préstamo:

fn ultimo_o_insertar(v: &mut Vec<i32>) -> &i32 {
    if let Some(x) = v.last() {   // nace el origen L0: préstamo compartido de `v`
        return x;                  // punto A: L0 vivo, se devuelve por este camino
    }                              // punto B: por aquí L0 ya está MUERTO
    v.push(0);                     // punto C: se pide &mut v; ningún origen vivo -> OK
    v.last().unwrap()
}

Una única regla —un préstamo mutable en un punto es un error si allí vive algún origen incompatible— recorre el grafo y solo dispara cuando de verdad hay solapamiento. La consulta se resuelve como cualquier deducción lógica: propagando hechos hasta el punto fijo. Ese cambio de maquinaria —de estirar regiones convexas a deducir hechos por punto— es exactamente lo que compra la precisión que a NLL le faltaba.

Que sea cara no la hace opcional: es la diferencia entre un borrow checker que solo mejora en los márgenes y uno que por fin acepta el patrón condicional que la comunidad lleva una década pidiendo.

flowchart TB
start[Entrada de la funcion] --> cond[Comprueba v.last]
cond -->|Some x| ret[return x usa el prestamo]
cond -->|None| push[v.push cero]
push --> tail[v.last unwrap]
ret --> salida[Salida]
tail --> salida
push --> nota[En este camino el prestamo del return ya esta muerto]

El patrón que ahora compila

Con el análisis de Polonius, ultimo_o_insertar se acepta tal cual, sin reestructurar. La familia de patrones que desbloquea comparte una firma: devolver una referencia obtenida en una comprobación previa y, si la comprobación falla, mutar el contenedor para producirla. Es el corazón de las APIs tipo get-or-insert, omnipresentes en cachés, mapas y arenas:

use std::collections::HashMap;

fn obtener_o_crear<'m>(mapa: &'m mut HashMap<u32, String>, clave: u32) -> &'m String {
    if let Some(valor) = mapa.get(&clave) {
        return valor;                       // camino A: devolvemos el préstamo compartido
    }
    mapa.insert(clave, String::from("nuevo")); // camino B: el préstamo de `get` ya murió
    &mapa[&clave]
}

Bajo NLL, el préstamo compartido de mapa.get se considera vivo hasta la salida por el return, y colisiona con el &mut que exige mapa.insert. Bajo Polonius, el flujo que llega al insert es exactamente el que no devolvió nada: allí el origen del get está muerto y no hay conflicto. El mismo razonamiento vale para Vec, BTreeMap, arenas de nodos y cualquier estructura donde consultas primero y construyes después.

No es un caso de laboratorio: es uno de los patrones más pedidos de la historia del lenguaje, con años de discusión a sus espaldas y un apodo propio entre los desarrolladores del compilador —“el problema del caso condicional”—. Que sobreviva tanto tiempo como falso positivo mide lo difícil que es afinar un borrow checker sin comprometer jamás la seguridad: es más fácil rechazar de más que arriesgarse a aceptar un solo programa peligroso.

La misma forma reaparece en cualquier estructura que memoiza sobre un mapa o una arena. Piensa en un intérprete que cachea el resultado de subexpresiones: consulta si ya calculó una clave y, si no, la calcula, la inserta y devuelve la referencia recién creada. Es obtener_o_crear con otro disfraz.

use std::collections::HashMap;

fn evaluar<'c>(cache: &'c mut HashMap<u32, u64>, clave: u32) -> &'c u64 {
    if cache.contains_key(&clave) {
        return &cache[&clave];        // camino A: ya estaba, devolvemos la referencia
    }
    let calculado = (clave as u64) * (clave as u64);
    cache.insert(clave, calculado);   // camino B: el préstamo previo ya murió
    &cache[&clave]
}

Bajo NLL, incluso esta variante que separa la consulta (contains_key) de la toma final de la referencia choca en el camino del insert; Polonius la acepta porque razona que, cuando el flujo llega a insertar, no queda vivo ningún préstamo de la rama que ya retornó.

Estado en 2026: qué es real y qué está en camino

Conviene ser preciso para no crearte expectativas falsas. Polonius es un proyecto de años, y en 2026 conviven varias piezas:

• El modelo teórico está definido y validado: se sabe qué programas debería aceptar y por qué son seguros.
• Una variante location-sensitive —la que de verdad distingue caminos— avanza en el compilador y se puede activar en nightly con las banderas de -Zpolonius, todavía como trabajo en curso, no apto para producción.
• El verificador por defecto en estable sigue siendo NLL. La edición 2024 no cambia por sí sola el motor de borrow checking, pero marca el rumbo: es el vehículo con el que estas mejoras llegarán sin romper código existente, porque Polonius solo añade programas aceptados, nunca quita.

La lección práctica: si hoy chocas con el retorno condicional de un préstamo en stable, aún debes reestructurar (lo verás en la próxima lección). Pero entender Polonius te dice por qué ese código era seguro desde el principio, y te ahorra la frustración de creer que tu diseño estaba mal cuando lo único insuficiente era el análisis.

Que la migración sea aditiva tiene una consecuencia tranquilizadora: ningún programa que compila hoy dejará de compilar cuando Polonius aterrice. Solo pasará que un puñado de funciones que hoy exigen un rodeo empezarán a aceptarse escritas de la forma directa. Por eso puedes escribir tu código pensando en la semántica correcta —la que Polonius reconoce— y, donde el stable de hoy aún no llegue, aplicar el rodeo con la conciencia tranquila de que es andamiaje temporal, no una cicatriz permanente en el diseño.