Coherencia y la regla del huérfano: el patrón newtype

Llega el momento en que quieres darle una capacidad ajena a un tipo ajeno: implementar Display para Vec<String>, digamos. Y el compilador te lo prohíbe con el error E0117. No es un capricho ni una limitación temporal: es la regla del huérfano, la guardiana de una propiedad más profunda llamada coherencia, sin la cual los traits no podrían ser un fundamento fiable para el código genérico. Entender por qué existe —y cómo el patrón newtype la sortea limpiamente y sin coste— cierra tu comprensión de los traits.

La regla del huérfano en acción

Prueba a dar formato humano a un vector de la biblioteca estándar y el compilador te frena en seco:

use std::fmt;

// NO COMPILA (error E0117): ni Display ni Vec son tuyos.
impl fmt::Display for Vec<String> {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "[{}]", self.join(", "))
    }
}

La regla que se incumple es la regla del huérfano (orphan rule): solo puedes escribir impl Trait for Tipo si posees el trait o posees el tipo —es decir, si al menos uno de los dos está definido en tu propio crate—. Aquí Display pertenece a la biblioteca estándar y Vec también: ambos te son ajenos, así que la implementación sería “huérfana”, sin ningún padre local que la reclame, y queda prohibida.

Cuando sí posees uno de los dos, todo funciona. Puedes implementar un trait ajeno para un tipo tuyo:

struct Temperatura(f64);

impl std::fmt::Display for Temperatura {   // trait ajeno, tipo propio: OK
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(f, "{} grados", self.0)
    }
}

…o un trait tuyo para un tipo ajeno:

trait Resumible { fn resumen(&self) -> String; }

impl Resumible for String {   // trait propio, tipo ajeno: OK
    fn resumen(&self) -> String {
        format!("cadena de {} bytes", self.len())
    }
}

Lo único vetado es la combinación doble-ajeno: trait ajeno y tipo ajeno a la vez.

Por qué existe la regla: la coherencia

La regla del huérfano no protege un capricho estético, sino una propiedad global llamada coherencia: en todo el programa, cada par (tipo, trait) tiene como mucho una implementación. Nunca dos. Gracias a ello, cuando escribes x.resumen(), el significado de esa llamada es único y no depende de qué crate la observe ni de qué módulos estén importados.

Imagina que la regla no existiera. El crate colores podría implementar Display para Vec<String> de una forma, y el crate tablas podría implementarlo de otra. Si tu programa dependiera de ambos, habría dos implementaciones de Display for Vec<String> compitiendo, y ni el compilador ni tú sabríais cuál usa mi_vec.to_string(). Peor aún: añadir una dependencia inofensiva rompería, a distancia, código que ya funcionaba. La regla del huérfano corta ese escenario de raíz con una condición puramente sintáctica —¿es local el trait o el tipo?— que dos crates cualesquiera nunca pueden satisfacer sobre el mismo par ajeno a la vez.

flowchart TB
q[quieres implementar un trait para un tipo] --> d[posees el trait o el tipo]
d -->|al menos uno es local| ok[permitido]
d -->|ambos son externos| no[la regla del huerfano lo prohibe con E0117]
no --> nt[envuelve el tipo externo en un newtype local]
nt --> ok

El patrón newtype: recuperar la propiedad

¿Y si de verdad necesitas Display para algo parecido a un Vec<String>? La salida canónica es el patrón newtype: envuelves el tipo ajeno en una tupla-struct de un solo campo definida por ti. Ese envoltorio es tuyo, así que recuperas el derecho a implementar cualquier trait sobre él.

use std::fmt;

struct Lista(Vec<String>);   // newtype: el envoltorio es local, ya es tuyo

impl fmt::Display for Lista {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "[{}]", self.0.join(", "))
    }
}

fn main() {
    let l = Lista(vec![String::from("a"), String::from("b")]);
    println!("{l}");   // [a, b]
}

Accedes al valor envuelto con self.0, el primer (y único) campo de la tupla. El coste en memoria es nulo: un newtype de un solo campo tiene exactamente la misma representación que su contenido, y el compilador lo trata igual de eficientemente; la envoltura existe solo en el sistema de tipos, no en el binario.

Para que el newtype sea cómodo, reexpones los métodos del interior que de verdad necesites, cada uno delegando en el valor envuelto:

impl Lista {
    fn agregar(&mut self, s: String) { self.0.push(s); }  // delega en Vec::push
    fn cuantos(&self) -> usize { self.0.len() }            // delega en Vec::len
}

El newtype más allá de la coherencia

Sortear la regla del huérfano es solo uno de los usos del newtype. El mismo patrón —envolver un valor en un tipo local de coste cero— sirve también para dar significado a datos que, desnudos, serían intercambiables. Un f64 puede representar metros o segundos, pero el compilador no lo sabe: sumar unos con otros, o pasarlos en el orden equivocado, compila aunque sea un disparate físico. Envuélvelos y el sistema de tipos empieza a vigilar:

struct Metros(f64);
struct Segundos(f64);

fn velocidad(distancia: Metros, tiempo: Segundos) -> f64 {
    distancia.0 / tiempo.0
}

fn main() {
    let v = velocidad(Metros(100.0), Segundos(9.58));
    println!("{v:.2} m/s");
    // velocidad(Segundos(9.58), Metros(100.0)); // ERROR: los tipos no encajan
}

Invertir los argumentos ya no compila: Metros y Segundos son tipos distintos aunque ambos envuelvan un f64. Es la misma técnica de la coherencia puesta al servicio de la corrección lógica: un envoltorio sin coste que convierte un error de razonamiento en un error de tipos, atrapado en compilación. Reconocerás en ello el espíritu de todo Rust —hacer inexpresables los estados inválidos—, y el newtype es una de sus herramientas más baratas para lograrlo.