Cotas de lifetime: `T: 'a` (outlives) y `'a: 'b` (subtipado)

Hasta ahora un lifetime era una marca solitaria sobre una referencia: &'a T. Este nivel empieza cuando esas marcas dejan de vivir aisladas y se relacionan. Aparecen dos formas nuevas que comparten el mismo : pero pertenecen a mundos distintos: T: 'a liga un tipo a una region —“el tipo T sobrevive a ’a”—, y 'a: 'b ordena dos regiones —“’a sobrevive a ’b”—. La primera gobierna cuando una referencia esta bien formada; la segunda, cuando una referencia larga puede usarse donde se esperaba una corta. Domina estas dos cotas y habras visto la aritmetica cruda que el borrow checker resuelve por ti en cada compilacion.

T: 'a: la cota de “sobrevivir a una region”

La cota T: 'a se lee “T sobrevive a ’a” (en ingles, T outlives ’a). Su significado formal es preciso: todo lifetime que aparezca dentro del tipo T es al menos tan largo como ’a. Dicho de otro modo, un valor de tipo T sigue siendo valido durante toda la region ’a, porque ninguna referencia escondida en su interior caduca antes.

De aqui nace una de las reglas mas fundamentales del lenguaje, la buena formacion de las referencias: el tipo &'a T solo esta bien formado si T: 'a. La intuicion es inevitable. Si tienes una referencia valida durante ’a, el dato al que apunta debe seguir vivo durante ’a; y si ese dato fuera a su vez un tipo con una referencia interna mas corta, seguir la referencia externa podria alcanzar memoria ya liberada. La cota prohibe justo eso.

// i32 no contiene referencias: sobrevive a cualquier region, incluso 'static.
fn _a<'a>(_x: &'a i32) {}          // exige i32: 'a  -> trivialmente cierto

// Un tipo que guarda una referencia 'b solo sobrevive a 'a si 'b: 'a.
struct Vista<'b> { s: &'b str }
fn _b<'a, 'b>(_v: &'a Vista<'b>) {} // el compilador asume Vista<'b>: 'a, es decir 'b: 'a

Los tipos duenos de sus datos cumplen la cota mas fuerte, T: 'static: un String, un Vec<u8> o un i32 no dependen de ningun prestamo efimero, asi que sobreviven a cualquier region. Solo la incumplen los tipos que guardan una vista prestada, como Vista<'b>, cuya supervivencia queda encadenada a la de su 'b.

'a: 'b: ordenar dos regiones y el subtipado que esconde

La cota 'a: 'b se lee “’a sobrevive a ’b”: la region ’a es al menos tan larga como ’b y la contiene por completo. Cuidado con la direccion, que es la trampa clasica: en 'a: 'b, la region larga es 'a (la que esta a la izquierda del :) y la corta es 'b. El : se lee siempre “sobrevive a”.

Esta relacion es lo que hace posible el subtipado de lifetimes. Cuando 'a: 'b, el tipo &'a T es un subtipo de &'b T, y por tanto una referencia larga puede usarse en cualquier sitio donde se espere una corta. Es lo que ocurre cada vez que pasas un &'static str a una funcion que pide un &str cualquiera: 'static sobrevive a toda region, luego encaja en todas. Las referencias son covariantes en su lifetime: alargar la region de lo que exiges es siempre seguro; acortarla, no.

// 'a: 'b  =>  la region 'a contiene a 'b  =>  &'a str encaja donde se pide &'b str.
fn elige<'a, 'b>(largo: &'a str, _corto: &'b str) -> &'b str
where
    'a: 'b,                     // 'a sobrevive a 'b: autoriza devolver el largo como corto
{
    largo                       // coercion covariante &'a str -> &'b str
}

Sin la clausula where 'a: 'b, esa funcion no compila: el compilador no puede devolver un &'a str donde se prometio un &'b str salvo que tenga garantia de que ’a incluye a ’b. La cota se la da. Observa que 'static: 'a se cumple para toda ’a por definicion —el programa entero contiene a cualquier region—, y por eso 'static es el subtipo universal.

Esa coercion tiene un solo sentido, y la asimetria es fundamental: las referencias compartidas son covariantes en su lifetime —puedes sustituir una region por otra mas corta, jamas al reves—. Intentar lo contrario, usar un &'b str corto donde se pide un &'a str largo, es exactamente lo que el sistema debe prohibir, porque dejaria vivo un nombre para un dato ya muerto.

fn necesita_corto<'b>(_r: &'b str) {}

fn demo<'a>(largo: &'a str) {
    necesita_corto(largo);   // OK: &'a str se coacciona a &'b str mas corto (covariante)
}

La covarianza se rompe bajo mutabilidad: &mut T es invariante en T. Si &mut &'a str pudiera coaccionarse a &mut &'b str, alguien podria escribir a traves de esa referencia un &'b str efimero en una ranura que el resto del programa cree que guarda un &'a str duradero; al leerla despues, referencia colgante. La invarianza de &mut es, literalmente, la que cierra esa puerta —y por eso la variancia no es un tecnicismo academico, sino parte del andamiaje de seguridad.

Quien escribe estas cotas: inferencia frente a anotacion

La razon de que rara vez veas T: 'a escrito a mano es que el compilador lo infiere en casi todas partes. Dentro de una funcion actuan los implied bounds: si un parametro tiene tipo &'a T, el cuerpo puede asumir T: 'a sin declararlo, porque el propio tipo del argumento seria mal formado de otro modo. Y desde la RFC 2093 (inferred outlives), las definiciones de struct y enum tampoco necesitan la cota: se deduce de los campos.

// Rust moderno: NO hace falta escribir T: 'a. Se infiere del campo.
struct Ref<'a, T> { r: &'a T }

// Antes de la RFC 2093 el compilador exigia la cota explicita:
//   struct Ref<'a, T: 'a> { r: &'a T }

Entonces, cuando si debes escribirlas? En los sitios donde no hay campo ni argumento del que inferirlas: al relacionar dos lifetimes nombrados en una firma (where 'a: 'b, como arriba), en definiciones y cotas de traits, en tipos asociados y GATs (generic associated types), y a veces junto a PhantomData cuando modelas variancia a mano. En esos contextos la cota deja de ser ruido y se vuelve la unica forma de expresar la relacion temporal que tu diseno exige.

flowchart TB
s[static: el techo, todo el programa] --> a[region a: mas larga]
a --> b[region b: contenida en a]
b --> e[expresion: region minima]
note[a colon b significa a sobrevive a b: la flecha baja de lo que contiene a lo contenido]