Sealed traits y los límites de la programación a nivel de tipos

Un trait público es, por defecto, una invitación abierta: cualquiera, en cualquier crate, puede implementarlo para sus tipos. A veces eso es justo lo que quieres. Otras, no: quieres un trait que la gente pueda usar como cota —T: MiTrait— pero que solo tú puedas implementar. Cerrarlo así se llama sealing, y con una técnica de tres líneas te devuelve dos poderes: evolucionar el trait —añadirle métodos— sin romper el código ajeno, y razonar sobre sus implementadores como sobre un conjunto cerrado, casi un enum. Con el patrón sealed en la mano cerramos también el nivel, asomándonos a la frontera del sistema de tipos y a los muros que Rust ha decidido, a conciencia, no derribar.

Cerrar un trait: el patrón sealed

La técnica se apoya en una asimetría de visibilidad. Se declara un trait privado —el sello— en un módulo privado, y el trait público lo exige como supertrait. Quien esté fuera puede nombrar el trait público, pero no el sello, así que no puede satisfacer su requisito:

pub mod formato {
    mod sello {
        pub trait Sellado {}        // privado: nadie de fuera puede nombrarlo
    }

    pub trait Formato: sello::Sellado {   // solo quien implemente Sellado puede implementar Formato
        fn extension(&self) -> &str;
    }

    pub struct Json;
    pub struct Toml;

    impl sello::Sellado for Json {}       // el sello se cierra aqui dentro
    impl sello::Sellado for Toml {}

    impl Formato for Json { fn extension(&self) -> &str { "json" } }
    impl Formato for Toml { fn extension(&self) -> &str { "toml" } }
}

Desde otro crate, formato::Formato sirve como cota —fn guardar<T: formato::Formato>(x: T)— pero implementarlo es imposible:

// En otro crate:
struct MiFormato;
// impl formato::Formato for MiFormato { ... }
// ERROR: no puedes implementar Formato sin implementar sello::Sellado,
// que es privado y ni siquiera puedes nombrar

Tres líneas —un módulo privado, un trait vacío, un supertrait— y el trait queda cerrado: usable por todos, implementable solo por ti.

Por qué sellar

Cerrar un trait no es mezquindad, es diseño. Compra tres cosas concretas.

Evolución sin rupturas. Si nadie fuera de tu crate implementa Formato, puedes añadirle un método nuevo —con o sin cuerpo por defecto— sin romper a ningún usuario, porque conoces todas las implementaciones que existen: las tuyas. Un trait abierto no tiene ese lujo; añadirle un método sin defecto rompe todas las implementaciones externas.

Razonar sobre un conjunto cerrado. Un trait sellado es casi un enum de tipos: sabes que sus únicos implementadores son los que tú escribiste. Eso te deja razonar exhaustivamente sobre ellos, igual que un match razona sobre las variantes de un enum. Es el reverso de #[non_exhaustive]: aquel abre un enum para poder crecer; el sellado cierra un trait para poder crecer sin que nadie dependa de la totalidad.

Invariantes garantizadas. Si solo tú implementas un trait, controlas que toda implementación respete las invariantes que tu API asume. Nadie colará una implementación tramposa. Aquí conecta con el typestate del orden anterior: sellar el trait de los estados posibles de una conexión cierra el conjunto de estados legales, y ningún crate externo puede inventarse uno nuevo.

El reverso exacto de esta técnica es #[non_exhaustive], que se pone sobre un enum o struct público para lo contrario: dejarlo abierto a crecer.

#[non_exhaustive]
pub enum Evento {   // podra ganar variantes en el futuro
    Clic,
    Tecla(char),
}

Un enum marcado así obliga a los match de crates externos a incluir un brazo comodín, de modo que añadir una variante mañana no rompa su código. Sellado y #[non_exhaustive] son dos caras de una misma moneda de evolución: aquel garantiza creceré yo solo, nadie más implementa esto; este avisa podré crecer, no asumas que están todas las variantes. Ambos protegen tu libertad de añadir sin romper a nadie.

Al filo del sistema

Sellar un trait es un ejercicio de cerrar el sistema para razonar mejor. En el filo opuesto están las herramientas que lo abren hacia más expresividad, cada una una extensión de la misma idea de programar con tipos.

Los GATs —tipos asociados genéricos—, estables desde Rust 1.65, permiten que un tipo asociado tenga sus propios parámetros, típicamente un tiempo de vida:

trait Prestador {
    type Prestado<'a> where Self: 'a;   // tipo asociado con parametro (GAT)
    fn prestar<'a>(&'a self) -> Self::Prestado<'a>;
}

Con ellos se expresan los lending iterators —iteradores que prestan referencias a su propio interior—, imposibles de escribir antes. impl Trait en posición de retorno dentro de traits —estable desde 1.75— es, a su vez, lo que hizo por fin posibles las async fn en traits. Ambas amplían qué puedes decir con tipos sin salir del lenguaje.

Y luego están los muros, levantados a conciencia:

Rust no tiene tipos dependientes plenos: un tipo no puede depender de un valor de ejecución, solo de constantes conocidas en compilación. No tiene tipos de orden superior —higher-kinded types—: no puedes abstraer sobre Vec o Option como constructores sin aplicar; los GATs cubren algunos de esos casos, pero no todos. La especialización de implementaciones sigue inestable, por problemas de solidez sin resolver. Son fronteras, no fallos pendientes.

flowchart TB
s[Trait publico Formato] --> sup[Supertrait privado Sellado]
sup --> solo[Solo tu crate puede implementarlo]
solo --> evo[Anades metodos sin romper a nadie]
solo --> raz[Razonas sobre un conjunto cerrado]
style sup fill:#cba6f7,color:#11111b
style solo fill:#89b4fa,color:#11111b
style evo fill:#a6e3a1,color:#11111b
style raz fill:#a6e3a1,color:#11111b