Métodos genéricos e impl condicionales: la API que el tipo se gana

Ya sabes parametrizar un struct y darle métodos con impl<T>. Ahora llega la vuelta de tuerca que separa a quien usa genéricos de quien los domina: un método puede introducir su propio parámetro de tipo, distinto del struct, y —más potente aún— un bloque impl puede llevar un bound que haga que sus métodos existan solo cuando el tipo del contenedor cumple ciertas capacidades. Un Punto<T> cualquiera tendrá unos métodos; un Punto<T> cuyo T sabe imprimirse tendrá esos y algunos más. La API deja de ser fija: se la gana el tipo.

El T del tipo frente al T del método

Cuando escribes impl<T> Envoltura<T>, ese T viene fijado por la instancia: en una Envoltura<i32>, T ya es i32 en todos los métodos. Pero un método puede declarar su propio parámetro de tipo, elegido de nuevo en cada llamada, ortogonal al del struct:

struct Envoltura<T> {
    valor: T,
}

impl<T> Envoltura<T> {
    // U es del método, no del struct: se decide en cada llamada
    fn combinar<U>(self, otro: U) -> (T, U) {
        (self.valor, otro)
    }
}

Aquí T está atado a la envoltura (self.valor es T), pero U es libre: puedes combinar una misma Envoltura<i32> con un &str en una llamada y con un bool en la siguiente. Son dos ejes de genericidad independientes conviviendo en la misma firma.

let e = Envoltura { valor: 10 };
let (a, b) = e.combinar("diez");   // T = i32, U = &str
assert_eq!(a, 10);
assert_eq!(b, "diez");

Contrasta con un método que se apoya en el T del struct: obtener no declara ningún parámetro nuevo, solo devuelve lo que ya hay dentro.

impl<T> Envoltura<T> {
    fn obtener(&self) -> &T {
        &self.valor
    }
}

Dos métodos, dos orígenes de genericidad: obtener reutiliza el T de la instancia; combinar añade su propio U. Distinguirlos es la clave para leer sin perderte las firmas más densas de la biblioteca.

impl condicional: métodos que dependen de T

Un mismo tipo puede tener varios bloques impl, y cada uno puede pedir bounds distintos. Los métodos de un bloque con bound solo existen para las instancias cuyo T cumple ese bound. Es el patrón más característico del sistema:

use std::fmt::Display;

struct Punto<T> {
    x: T,
    y: T,
}

// Bloque incondicional: TODO Punto<T> tiene `nuevo`
impl<T> Punto<T> {
    fn nuevo(x: T, y: T) -> Self {
        Punto { x, y }
    }
}

// Bloque condicional: SOLO si T sabe imprimirse y compararse
impl<T: Display + PartialOrd> Punto<T> {
    fn mostrar_mayor(&self) {
        if self.x >= self.y {
            println!("la mayor coordenada es x = {}", self.x);
        } else {
            println!("la mayor coordenada es y = {}", self.y);
        }
    }
}

El efecto es quirúrgico. Punto<i32> tiene nuevo y mostrar_mayor, porque i32 cumple Display + PartialOrd. Pero si defines un struct Opaco que no implementa esos traits, un Punto<Opaco> tendrá nuevo y no tendrá mostrar_mayor: el método sencillamente no existe para esa instanciación, y llamarlo es un error de compilación, no de ejecución.

Punto::nuevo(3, 7).mostrar_mayor();   // OK: i32 cumple los bounds

struct Opaco;
let p = Punto::nuevo(Opaco, Opaco);   // OK: `nuevo` no exige nada
// p.mostrar_mayor();                 // ERROR: Opaco no implementa Display

El patrón en la biblioteca estándar

Una vez que ves este patrón, lo reconoces en toda la std. Es la razón de que muchos métodos “aparezcan y desaparezcan” según el tipo que metas en un contenedor:

• Vec<T> tiene dedup solo si T: PartialEq, y sort solo si T: Ord. Un Vec de un tipo sin orden no ofrece sort.
• Option<T> tiene unwrap_or_default solo si T: Default, y copied solo si T: Copy.
• [T] tiene contains solo si T: PartialEq.

El caso extremo es el impl general (blanket impl): la std implementa ToString para todo T que cumpla Display. Por eso cualquier tipo que sepa mostrarse obtiene gratis un método to_string, sin escribir una línea. Es un impl<T: Display> ToString for T: un solo bloque condicional que dota de una capacidad a una familia entera de tipos de golpe.

// En la std, conceptualmente:
// impl<T: Display> ToString for T { ... }

let s: String = 42.to_string();        // i32: Display  ⇒  tiene to_string
let t: String = 3.14.to_string();      // f64: Display  ⇒  también

Y lo ves en acción con Vec: el método sort aparece solo si el elemento es Ord.

let mut nums = vec![3, 1, 2];
nums.sort();                       // i32: Ord  ⇒  sort disponible
assert_eq!(nums, vec![1, 2, 3]);

struct SinOrden(i32);
let mut raros = vec![SinOrden(3), SinOrden(1)];
// raros.sort();                   // ERROR: SinOrden no implementa Ord

flowchart TB
base[impl de T sobre Punto de T] --> todos[Todo Punto tiene nuevo]
cond[impl de T con Display y PartialOrd] --> algunos[Solo esos Punto tienen mostrar_mayor]
i32[Punto de i32 cumple los bounds] --> ambos[Obtiene nuevo y mostrar_mayor]
opaco[Punto de Opaco no cumple] --> solo[Obtiene solo nuevo]
style todos fill:#89b4fa,color:#11111b
style ambos fill:#a6e3a1,color:#11111b
style solo fill:#f9e2af,color:#11111b