Asociados frente a genéricos: uno-a-uno o muchos-a-uno

Ya sabes qué es un tipo asociado. Ahora afrontas la decisión de diseño que lo acompaña, y que separa a quien copia sintaxis de quien entiende el sistema de tipos: cuando defines un trait que involucra otro tipo, ¿lo pones como parámetro genérico —trait Trait<T>— o como tipo asociado —type T;? No es cuestión de gusto ni de estilo. Hay una regla precisa, y se reduce a una sola pregunta: ¿cuántas veces debe un tipo poder implementar este trait? La respuesta a esa pregunta —una o muchas— dicta mecánicamente la elección, y explica por qué From lleva un genérico, Iterator lleva un asociado, y Add lleva ambos a la vez.

La pregunta que lo decide todo

La elección entre parámetro genérico y tipo asociado se resuelve con una única pregunta sobre la relación entre el tipo implementador y el otro tipo en juego:

Para un tipo dado, ¿tiene sentido implementar este trait una sola vez o varias veces con tipos distintos?

• Si la respuesta es una sola vez, el otro tipo es una función del implementador: va como tipo asociado.
• Si la respuesta es varias veces, el otro tipo es una elección libre de quien implementa: va como parámetro genérico.

Es la misma dicotomía entrada/salida del capítulo anterior, ahora convertida en criterio de diseño. Un parámetro genérico es un eje sobre el que un tipo puede tener muchas implementaciones; un tipo asociado colapsa ese eje a un único valor. Todo lo demás —inferencia, ergonomía, capacidad de usar el trait como objeto— se deduce de esta elección.

From: muchas conversiones, luego genérico

String se construye desde un &str, desde un char, desde un Vec<u8>… Un mismo tipo destino admite muchas conversiones de origen, todas igual de legítimas. Esa multiplicidad es exactamente la señal de “parámetro genérico”:

pub trait From<T> {         // T es un parametro: eje de multiples impls
    fn from(value: T) -> Self;
}

// Un mismo destino, muchas implementaciones sobre el eje T:
impl From<&str> for String { /* ... */ }
impl From<char> for String { /* ... */ }
impl From<Box<str>> for String { /* ... */ }

Si From usara un tipo asociado —trait From { type Origen; }—, String solo podría convertirse desde un único tipo en todo el programa, una limitación absurda. El genérico es lo que permite las tres implementaciones coexistiendo. El precio, coherente con el capítulo anterior, es que a veces hay que decir cuál: u32::from(x) puede necesitar contexto o turbofish cuando varios orígenes encajan, porque el compilador no puede deducir por sí solo cuál de las muchas implementaciones quieres.

Iterator: un elemento, luego asociado

Un iterador produce elementos de un tipo. Contador produce u32; no tiene sentido que “también” sea, simultáneamente, un iterador de String. La relación es uno-a-uno, y por eso Item es asociado, como ya viste:

pub trait Iterator {
    type Item;                                  // uno por implementador
    fn next(&mut self) -> Option<Self::Item>;
}

La consecuencia práctica es la inferencia sin fricción. Como Contador determina su Item, el compilador lo deduce y lo propaga por toda la cadena. Compara el efecto de cada elección en el sitio de llamada:

fn main() {
    // Asociado: el Item se deduce solo, cero anotaciones
    let suma: u32 = Contador::nuevo(5).map(|x| x * 2).sum();

    // Generico: a veces hay que desambiguar cual implementacion
    let n = u32::from(3u8);          // ok, un solo origen plausible aqui
    let s = String::from("hola");    // el tipo del literal fija T = &str
}

Regla mnemotécnica: el genérico te obliga a hablar, el asociado habla por ti. Un eje de múltiples implementaciones exige que digas por cuál vas; un tipo determinado se deduce en silencio.

Add: el caso mixto

Add es el ejemplo que consolida la regla, porque contiene las dos figuras a la vez y cada una por su motivo exacto:

pub trait Add<Rhs = Self> {
    type Output;                          // salida: determinada por el par
    fn add(self, rhs: Rhs) -> Self::Output;
}

El operando derecho, Rhs, es un parámetro genérico con valor por defecto Self, porque un mismo tipo puede sumarse a varios: un instante temporal admite Instant + Duration, y una duración admite Duration + Duration. Muchos operandos derechos posibles, luego eje genérico. En cambio Output es un tipo asociado, porque una vez fijado el par ordenado (Self, Rhs), el tipo del resultado está determinado: f64 + f64 da f64 y nada más. La firma codifica con precisión quirúrgica qué es libre y qué es forzoso:

use std::ops::Add;

struct Metros(f64);
struct Pies(f64);

// Metros + Metros = Metros
impl Add for Metros {
    type Output = Metros;
    fn add(self, otro: Metros) -> Metros { Metros(self.0 + otro.0) }
}

// Metros + Pies = Metros: otro Rhs, misma Self, Output aun determinado por el par
impl Add<Pies> for Metros {
    type Output = Metros;
    fn add(self, otro: Pies) -> Metros { Metros(self.0 + otro.0 * 0.3048) }
}

Dos implementaciones de Add para Metros conviven porque difieren en el eje genérico Rhs. Pero cada una fija un único Output: no podrías dar dos resultados distintos a Metros + Pies. Entrada plural, salida singular, en un mismo trait.

flowchart TB
q[Un tipo implementa el trait una vez o muchas veces]
q -->|una vez y el otro tipo se deduce| a[Tipo asociado]
q -->|muchas veces con tipos distintos| g[Parametro generico]
a --> ae[Iterator Item, Deref Target, Add Output]
g --> ge[From T, Add Rhs, AsRef T]
ae --> ai[La inferencia fluye sola]
ge --> gi[A veces hay que desambiguar]
style a fill:#89b4fa,color:#11111b
style g fill:#cba6f7,color:#11111b
style ai fill:#a6e3a1,color:#11111b
style gi fill:#f9e2af,color:#11111b