GATs en la práctica: colecciones que prestan y async en traits

Un mecanismo del sistema de tipos se juzga por lo que permite escribir que antes era imposible. Los GATs superan esa prueba dos veces. La primera, con las colecciones genéricas que prestan: por fin puedes escribir una función que funcione para cualquier contenedor y su iterador de referencias, algo que el sistema de tipos rechazaba de plano. La segunda, y la que de verdad los llevó a todos los proyectos: async fn dentro de traits, la característica que Rust persiguió durante años y que, por debajo de su sintaxis limpia, no es más que un tipo asociado genérico sobre el lifetime de self. Este capítulo cierra el nivel bajando de la teoría a por qué los GATs fueron, durante seis años, la funcionalidad más esperada del lenguaje.

Colecciones genéricas que prestan

Antes de los GATs, no podías escribir un trait Coleccion que abstrajera a la vez el contenedor y su iterador de referencias, porque ese iterador presta de la colección y su tipo depende de un lifetime que el tipo asociado clásico no sabía nombrar. Con type Iter<'a>, el contrato se expresa por fin:

trait Coleccion {
    type Elemento;
    type Iter<'a>: Iterator<Item = &'a Self::Elemento>   // iterador que presta
    where
        Self: 'a;
    fn iter(&self) -> Self::Iter<'_>;
}

impl<T> Coleccion for Vec<T> {
    type Elemento = T;
    type Iter<'a> = std::slice::Iter<'a, T> where Self: 'a;
    fn iter(&self) -> Self::Iter<'_> { self.as_slice().iter() }
}

type Iter<'a>: Iterator<Item = &'a Self::Elemento> es la clave: el iterador asociado está acotado para producir referencias con el mismo lifetime 'a que el préstamo de iter. Ahora una función genérica puede recorrer cualquier colección sin conocer su tipo de iterador concreto:

fn cuenta<C: Coleccion>(c: &C) -> usize {
    let mut n = 0;
    for _ in c.iter() { n += 1; }   // funciona para Vec, para tu tipo, para cualquiera
    n
}

Esto —ser genérico sobre un constructor de iteradores parametrizado por lifetime— era literalmente inexpresable antes, y es el patrón que subyace a bibliotecas de estructuras de datos que quieren ofrecer una interfaz común de préstamo.

async fn en traits: un GAT disfrazado

Aquí está el caso que llevó los GATs a todos los Cargo.toml. Desde Rust 1.75 puedes escribir async fn directamente dentro de un trait:

trait Cliente {
    async fn pedir(&self, url: &str) -> String;   // estabilizado en Rust 1.75
}

Se ve trivial, pero encierra un problema profundo que solo los GATs resuelven. Un async fn no devuelve su valor: devuelve un Future que, al ejecutarse, lo produce. Y ese Future toma prestado self mientras vive. Así que la desazucarización pasa primero por el retorno de impl Trait en traits —RPITIT—, y de ahí a un tipo asociado que debe ser genérico sobre el lifetime del préstamo:

// Lo que el compilador genera, conceptualmente, a partir del async fn:
trait Cliente {
    fn pedir(&self, url: &str) -> impl Future<Output = String>;   // paso 1: RPITIT
}

// Y ese impl Trait en retorno es, por debajo, un GAT anonimo:
trait ClienteDesazucarado {
    type Pedir<'a>: Future<Output = String> where Self: 'a;       // paso 2: GAT
    fn pedir<'a>(&'a self, url: &'a str) -> Self::Pedir<'a>;
}

El Future devuelto presta de self, luego su tipo depende del lifetime 'a de ese préstamo, luego el tipo asociado que lo nombra ha de ser type Pedir<'a>: un GAT, con su inevitable where Self: 'a. La sintaxis async fn en traits es azúcar; la maquinaria que la hace posible es, exactamente, la del capítulo anterior. Sin GATs no habría async en traits, y sin async en traits no habría ecosistema async idiomático —ni un trait Service, ni middlewares, ni abstracciones sobre transportes—.

RPITIT: la generalización

async fn es un caso particular de algo más amplio que se estabilizó a la vez: devolver impl Trait desde un método de trait, el RPITIT. Sirve para devolver iteradores, cierres o futuros sin nombrar su tipo concreto, y por debajo siempre es lo mismo —un tipo asociado, generalizado a GAT si el retorno presta de self—:

trait Fabrica {
    fn numeros(&self) -> impl Iterator<Item = u32>;   // no nombras el iterador concreto
}

struct Rango { hasta: u32 }
impl Fabrica for Rango {
    fn numeros(&self) -> impl Iterator<Item = u32> {
        (0..self.hasta)   // devuelve un Range, oculto tras impl Trait
    }
}

El implementador elige el tipo concreto del iterador; quien llama solo ve “algo que itera u32”. Es la ergonomía de impl Trait que ya conocías en funciones libres, extendida a los traits gracias a que por debajo hay un tipo asociado —anónimo— que el compilador sintetiza.

flowchart TB
a[async fn pedir en un trait] --> b[Paso 1 RPITIT devuelve impl Future]
b --> c[Paso 2 el Future presta de self]
c --> d[Tipo asociado generico sobre el lifetime que es un GAT]
d --> e[type Pedir de a con where Self de a]
g[Colecciones que prestan] --> d
h[LendingIterator] --> d
d --> i[La misma maquinaria sostiene los tres casos]
style a fill:#89b4fa,color:#11111b
style d fill:#cba6f7,color:#11111b
style i fill:#a6e3a1,color:#11111b

La feature más esperada, y por qué tardó

El RFC de los tipos asociados genéricos —el RFC 1598— se abrió en 2016. La estabilización llegó en Rust 1.65, en noviembre de 2022: más de seis años, uno de los desarrollos más largos de la historia del lenguaje, con un hilo de seguimiento que se convirtió casi en leyenda. La espera no fue negligencia, sino la dificultad genuina de la empresa: un GAT es, en esencia, genericidad de orden superior —tipos que producen tipos—, y encajarla en un sistema que debe seguir infiriendo lo indecible y permaneciendo decidible obligó a resolver problemas teóricos sobre well-formedness y sobre qué bounds implica cada uso. Cuando por fin aterrizó, el anuncio la describió, con razón, como una de las funcionalidades más demandadas jamás. El motivo de tanta demanda no era el LendingIterator en sí —un caso llamativo pero de nicho—, sino lo que colgaba detrás: sin GATs, el async en traits, la pieza que faltaba para que Rust fuera un lenguaje async de primera clase, era imposible de estabilizar. Los seis años de espera por los GATs fueron, en el fondo, seis años de espera por el async idiomático.