Tipos asociados: cuando el tipo de salida pertenece al trait

Un trait, hasta ahora, era una lista de firmas de método: un contrato sobre comportamiento. Pero un contrato puede pactar más que verbos. Puede pactar sustantivos: tipos que el implementador deberá aportar junto con los métodos. Eso es un tipo asociado, y el ejemplo que lo hace inolvidable es Iterator, cuyo type Item nombra qué produce cada next. La pregunta que abre el nivel es engañosamente simple: ¿por qué next devuelve Option<Self::Item> y no Option<T> para un T genérico cualquiera? La respuesta —que el tipo de los elementos es una función del iterador, no una elección libre de quien llama— es la semilla de todo lo que viene después.

Un trait también declara tipos

Junto a las firmas de método, un trait puede declarar un tipo pendiente. La sintaxis es una línea type sin valor: un hueco, exactamente como una firma de método sin cuerpo es un hueco de comportamiento.

trait Contenedor {
    type Elemento;                                   // hueco de tipo, sin resolver
    fn primero(&self) -> Option<&Self::Elemento>;
    fn longitud(&self) -> usize;
}

struct Pila<T> { datos: Vec<T> }

impl<T> Contenedor for Pila<T> {
    type Elemento = T;                               // se rellena aqui, una sola vez
    fn primero(&self) -> Option<&Self::Elemento> { self.datos.first() }
    fn longitud(&self) -> usize { self.datos.len() }
}

Dentro del trait, Self::Elemento es un nombre abstracto: “el tipo de elemento, sea cual sea, que el implementador decida”. Dentro del impl, type Elemento = T; lo aterriza en un tipo concreto. Y a partir de ahí Self::Elemento y T son sinónimos para ese impl. El tipo asociado es, en esencia, una variable de salida del contrato: no la elige quien usa el trait, la fija quien lo implementa.

Iterator, el ejemplo canónico

Toda la biblioteca de iteradores descansa sobre un tipo asociado. La definición, despojada de sus decenas de métodos por defecto, cabe en tres líneas:

pub trait Iterator {
    type Item;                                 // que produce este iterador
    fn next(&mut self) -> Option<Self::Item>;  // el unico metodo obligatorio
}

Un iterador es cualquier tipo que sepa entregar su siguiente elemento; Item nombra de qué son esos elementos. Al implementarlo, lo fijas:

struct Contador { actual: u32, hasta: u32 }

impl Iterator for Contador {
    type Item = u32;                           // este iterador produce u32
    fn next(&mut self) -> Option<u32> {        // Option<Self::Item>, ya concreto
        if self.actual < self.hasta {
            self.actual += 1;
            Some(self.actual)
        } else {
            None
        }
    }
}

Con solo eso, Contador hereda gratis map, filter, sum, collect y el resto: todos los métodos por defecto de Iterator están escritos en términos de Self::Item, así que se especializan a u32 en cuanto fijas el tipo. Fijar un tipo asociado desbloquea todo un ecosistema de comportamiento derivado.

Por qué asociado y no genérico

Imagina la alternativa: que Iterator llevara el elemento como parámetro genérico, trait Iterator<Item>. Nada impediría entonces que un mismo tipo lo implementara muchas veces, una por cada Item:

// Hipotetico y problematico: Item como parametro generico
// impl Iterator<u32> for Contador { ... }
// impl Iterator<String> for Contador { ... }   // el compilador lo permitiria

Y ahí muere la inferencia. Si Contador fuese iterador de u32 y de String, entonces contador.next() sería ambiguo —¿qué Option devuelve?—, contador.map(...) no sabría el tipo de entrada del cierre, y contador.collect() no podría deducir a qué colección va. Tendrías que anotar con turbofish en cada eslabón de cada cadena. El tipo asociado prohíbe esa multiplicidad de raíz: un tipo implementa Iterator como mucho una vez, y por tanto su Item queda determinado sin ambigüedad. Esa unicidad es lo que permite escribir v.iter().map(|x| x + 1).sum() sin una sola anotación.

Cuando un genérico necesita hablar del tipo asociado, no lo pasa: lo restringe con la sintaxis Trait<Tipo = ...>.

fn total<I>(it: I) -> u32
where
    I: Iterator<Item = u32>,   // no se pasa Item: se exige que sea u32
{
    let mut acc = 0;
    for x in it { acc += x; }
    acc
}

Iterator<Item = u32> no es “iterador parametrizado por u32”, sino “iterador cuyo Item es u32”. La igualdad liga una salida ya determinada, no inyecta una entrada. Y desde Rust 1.79 puedes incluso acotar el tipo asociado sin nombrarlo, con associated type bounds: impl Iterator<Item: Into<u64>> acepta cualquier iterador cuyos elementos se conviertan a u64, sin introducir un parámetro extra.

flowchart TB
subgraph Cada tipo determina un unico Item
  c1[Contador] --> i1[Item es u32]
  c2[Lineas] --> i2[Item es String]
  c3[Bytes] --> i3[Item es u8]
end
i1 --> nota[Cada tipo fija su Item sin ambiguedad]
i2 --> nota
i3 --> nota
nota --> infer[La inferencia fluye por la cadena sin anotar]
style i1 fill:#89b4fa,color:#11111b
style nota fill:#cba6f7,color:#11111b
style infer fill:#a6e3a1,color:#11111b

El patrón está por todas partes

En cuanto reconoces la forma, la ves en media biblioteca estándar. Add declara type Output porque el resultado de sumar dos tipos está determinado por ellos. Deref declara type Target porque un tipo se desreferencia a exactamente un destino. IntoIterator declara dos, encadenados entre sí:

pub trait Add<Rhs = Self> {
    type Output;                          // el tipo del resultado
    fn add(self, rhs: Rhs) -> Self::Output;
}

pub trait Deref {
    type Target: ?Sized;                  // a que apunta la desreferencia
    fn deref(&self) -> &Self::Target;
}

pub trait IntoIterator {
    type Item;
    type IntoIter: Iterator<Item = Self::Item>;  // un asociado acota a otro
    fn into_iter(self) -> Self::IntoIter;
}

Fíjate en IntoIterator: su type IntoIter no solo es asociado, sino que está acotado por otro asociado, Iterator<Item = Self::Item>, garantizando que el iterador producido entrega elementos del mismo tipo prometido. Los tipos asociados se refieren unos a otros y tejen contratos donde los tipos, no solo los métodos, quedan atados entre sí.