Object safety: qué traits pueden ser trait objects

No todo trait puede convertirse en un dyn Trait. Intenta un Box<dyn Clone> y el compilador te frena en seco. Las reglas que deciden qué traits sí y cuáles no se llamaban históricamente object safety, y Rust las renombró hace poco a dyn compatibility (compatibilidad con dyn). No son caprichos: cada regla es una consecuencia inevitable de cómo funciona la vtable. Si entendiste la tabla de métodos de la lección anterior, estas restricciones dejarán de parecer arbitrarias y se volverán casi obvias.

Por qué no todo trait sirve

Recuerda qué es una llamada dinámica: buscar un puntero a función en una tabla y saltar a él, pasándole un puntero a datos como self. Todo lo que un trait object sabe hacer tiene que caber en esa mecánica. Un trait es dyn compatible —antes object safe— cuando todos sus métodos pueden expresarse como una entrada en esa tabla. Si algún método no encaja, no puede haber vtable, y por tanto no puede haber dyn Trait.

trait Constructor {
    fn nueva() -> Self;              // no recibe self...
    fn combinar(&self, otro: Self);  // ...y toma Self por valor
}

// Esto NO compila: Constructor no es dyn compatible.
// let x: Box<dyn Constructor> = /* ... */;

Las reglas de la dyn compatibility

Las condiciones son varias, pero las que encontrarás en la práctica son tres, y todas se leen mejor como “qué NO puede tener un método despachable”:

El ejemplo canónico con el que todo el mundo tropieza es Clone:

// La firma de Clone es, en esencia:
trait Clone {
    fn clone(&self) -> Self;   // devuelve Self por valor
}

// Por eso esto NO compila:
// let cosas: Vec<Box<dyn Clone>> = vec![];  // Clone no es dyn compatible

clone devuelve Self por valor; quien recibe el valor clonado necesitaría saber cuánto ocupa, pero a través de dyn Clone ese tamaño está borrado. La regla no es un capricho del diseño de Clone: es que devolver Self es, literalmente, irrepresentable tras el borrado de tipo.

De dónde salen las reglas: la vtable manda

Cada restricción es la sombra que proyecta el borrado de tipo. Vale la pena verlas como teoremas, no como prohibiciones:

• Métodos genéricos. La vtable tiene un número fijo de ranuras, una por método. Un fn map<U>(&self, f: F) necesitaría una ranura por cada U posible —infinitas—, y no existe un único puntero a función que las represente. Sin puntero, no hay entrada.
• Self por valor. Para pasar o devolver un Self por valor, el llamador debe conocer su tamaño y colocarlo en la pila. Pero dyn Trait es ?Sized: el tamaño se olvidó. &self y &mut self sí valen, porque una referencia siempre mide una palabra, conozcas o no el tipo. Y self: Box<Self> también vale, porque un Box es un puntero de tamaño fijo.
• Funciones asociadas sin self. Self::nueva() no tiene receptor: no hay puntero gordo del que extraer la vtable, así que ni siquiera se sabe qué tabla consultar. Son métodos que solo tienen sentido sobre un tipo conocido en compilación.

Un ejemplo concreto del primer punto, el más sutil:

trait Serializar {
    fn escribir<W: std::io::Write>(&self, dst: &mut W); // metodo generico
}

// NO compila como trait object: escribir<W> no tiene una unica direccion.
// let s: Box<dyn Serializar> = /* ... */;

El truco idiomático cuando necesitas algo así es borrar también el genérico: cambia <W: Write> por un &mut dyn Write, y el método recupera una sola firma despachable. Es dispatch dinámico anidado dentro del método, pero rescata la compatibilidad del trait entero.

flowchart TB
t[Un trait] --> g[Algun metodo es generico]
g -->|si| no[No es dyn compatible]
g -->|no| s[Algun metodo usa Self por valor o no tiene self]
s -->|si y sin acotar| no
s -->|acotado con Self Sized| ok
s -->|no| ok[Es dyn compatible y admite dyn Trait]
style no fill:#f38ba8,color:#11111b
style ok fill:#a6e3a1,color:#11111b

Rescatar un trait con where Self: Sized

Un método problemático no tiene por qué condenar al trait entero. Si marcas ese método con where Self: Sized, le dices al compilador que solo existe para tipos de tamaño conocido, y con ello queda excluido de la vtable. El trait vuelve a ser dyn compatible; simplemente, ese método no se podrá llamar a través de dyn, solo sobre tipos concretos.

trait Registro {
    fn escribir(&self, msg: &str);   // despachable: va a la vtable

    fn por_defecto() -> Self         // problematico: devuelve Self y no tiene self...
    where
        Self: Sized;                 // ...pero excluido del objeto, asi que no estorba
}

struct Consola;
impl Registro for Consola {
    fn escribir(&self, msg: &str) { println!("{msg}"); }
    fn por_defecto() -> Self { Consola }
}

fn main() {
    let r: Box<dyn Registro> = Box::new(Consola); // OK: Registro es dyn compatible
    r.escribir("hola");                           // OK: escribir esta en la vtable
    // r.por_defecto();                           // ERROR: excluido del trait object
    let _c = Consola::por_defecto();              // OK sobre el tipo concreto
}

Es el mismo mecanismo por el que muchos traits de la biblioteca estándar ofrecen métodos “de conveniencia” acotados con Self: Sized sin renunciar a ser usables como trait objects.