HRTB: `for<'a>`, o cuantificar sobre todos los lifetimes

Todas las cotas que has visto fijan un lifetime concreto: <'a, F: Fn(&'a T)> dice “existe una region ’a, elegida por quien llama a la funcion externa, para la que F funciona”. Pero hay un patron que esa forma no puede expresar: una cota que debe valer para cualquier region, incluida una que aun no existe porque la elegira el propio cuerpo mas tarde. Para eso Rust tiene los higher-ranked trait bounds, escritos for<'a>: el cuantificador universal sobre lifetimes. Se lee “para todo ’a”. Vive escondido en casi toda cota Fn(&T) gracias al azucar de elision, y emerge explicito en cuanto un closure toma referencias cuya region no puedes nombrar desde fuera. Entenderlo es la diferencia entre firmas que aceptan cualquier closure y firmas que rechazan los correctos con mensajes cripticos.

for<'a> frente a un 'a fijo: quien elige la region

La clave de todo es quien elige el lifetime. Compara estas dos firmas, que parecen equivalentes y no lo son:

// (1) 'a lo elige quien llama a `aplica`, ANTES de entrar en el cuerpo. Una region fija.
fn aplica_fijo<'a, F: Fn(&'a i32) -> &'a i32>(f: F, x: &'a i32) -> &'a i32 { f(x) }

// (2) F debe valer para CUALQUIER 'a; el cuerpo puede llamar a f con regiones distintas.
fn aplica_hrtb<F: for<'a> Fn(&'a i32) -> &'a i32>(f: F) {
    let a = 10;
    let b = 20;
    let _ra = f(&a);   // una region
    let _rb = f(&b);   // otra region distinta, mas corta
}

En (1) hay un 'a, escogido en el momento de la llamada; el closure solo tiene que funcionar para esa region concreta. En (2), for<'a> exige que f funcione para toda region imaginable, porque el cuerpo va a invocarlo con prestamos locales cuya vida ni siquiera existe cuando se llama a aplica_hrtb. La version fija no serviria: no hay ningun 'a externo que abarque a la vez la region de a y la de b. El cuantificador universal es la unica forma de decir “sea cual sea la referencia que yo te pase luego, tu sabras manejarla”.

El azucar que lo esconde: por que casi nunca lo escribes

Si los HRTB fueran tan necesarios, deberias escribirlos a todas horas. No lo haces porque el compilador desazucara las cotas Fn con lifetimes elididos hacia HRTB de forma automatica. Estas tres lineas son idenficas:

fn f1<F: Fn(&str) -> &str>(_f: F) {}
fn f2<F: for<'a> Fn(&'a str) -> &'a str>(_f: F) {}   // lo que f1 significa de verdad
// f1 y f2 son la MISMA cota; el azucar de elision escribe el for<'a> por ti.

Por eso una funcion como fn cada<F: Fn(&str)>(f: F) acepta sin drama closures que reciben referencias de cualquier procedencia: por debajo, la cota ya es for<'a> Fn(&'a str). El azucar cubre el caso comun —una region que entra, una region que sale, ambas ligadas— y solo necesitas el for<'a> explicito cuando quieres una relacion que la elision no adivina, o cuando el HRTB no esta sobre un Fn sino sobre un trait tuyo con parametro de lifetime.

// HRTB explicito sobre un trait propio con lifetime: "para todo 'a, T sabe analizar &'a str".
trait Analiza<'a> { fn parse(&self, s: &'a str) -> usize; }

fn usar<T>(t: T) where T: for<'a> Analiza<'a> {
    // t vale para regiones distintas dentro de este cuerpo, no para una fija de fuera.
    let _ = t.parse("uno");
    let _ = t.parse("dos");
}

Donde emergen en la vida real: punteros a funcion, closures y serde

Los HRTB dejan de ser teoria en tres frentes. El primero son los punteros a funcion que toman referencias: su tipo es literalmente higher-ranked.

// El tipo de esta funcion es for<'a> fn(&'a i32) -> &'a i32, higher-ranked de nacimiento.
fn id(x: &i32) -> &i32 { x }
let _p: for<'a> fn(&'a i32) -> &'a i32 = id;

El segundo son los closures que devuelven referencias derivadas del argumento, el terreno donde el compilador a veces necesita ayuda para inferir el HRTB y aparecen los errores mas oscuros de Rust: “implementation is not general enough” significa casi siempre que tu closure solo vale para un lifetime concreto cuando la cota pedia que valiera para todos. El tercero son bibliotecas como serde: el trait Deserialize<'de> lleva un lifetime, y la cota DeserializeOwned no es mas que for<'de> Deserialize<'de> —“deserializable para cualquier region de entrada”—, lo que permite deserializar sin atarte al buffer de origen.

Cuando choques con “not general enough”, el arreglo casi nunca esta en la cota, sino en ayudar a la inferencia del closure a permanecer generica. La palanca mas fiable es extraerlo a una fn con nombre, que es higher-ranked por construccion y nunca colapsa a un lifetime:

fn aplica<F: for<'a> Fn(&'a str) -> &'a str>(_f: F) {}

fn id(s: &str) -> &str { s }        // higher-ranked por construccion: vale para toda region

fn main() {
    aplica(id);                     // robusto: la fn con nombre satisface el for<'a> sin dudas
    // si un closure equivalente fallara la inferencia, anota sus tipos o usa la fn con nombre
}

flowchart TB
q[Cota Fn con referencias] --> a[Escrita con lifetime elidido como Fn de ref str]
a --> d[El compilador desazucara a for de a Fn de ref a str]
d --> u[Universal: el cuerpo llama f con regiones locales distintas]
q --> e[Necesitas relacionar arg y retorno o trait con lifetime?]
e -->|si| x[Escribe for de a explicito]
e -->|no| y[Deja que el azucar lo ponga por ti]