Conformidad condicional: heredar capacidades del parámetro

Un array de enteros se puede comparar; un array de closures no. Un opcional de un tipo hashable es hashable; de otro, no. Esa asimetría no está codificada a mano en el compilador: es conformidad condicional, el mecanismo por el que un tipo genérico adquiere capacidades que su parámetro le presta. Entenderlo cambia cómo diseñas tus propios contenedores.

La forma canónica

La declaración es una extensión con cláusula where que además adopta un protocolo. El significado es literal: este tipo conforma a ese protocolo, pero solo bajo esta condición.

struct Pila<Elemento> {
    private(set) var items: [Elemento] = []
    mutating func apilar(_ x: Elemento) { items.append(x) }
    mutating func desapilar() -> Elemento? { items.popLast() }
}

extension Pila: Equatable where Elemento: Equatable {}
extension Pila: Hashable where Elemento: Hashable {}
extension Pila: Sendable where Elemento: Sendable {}

Con esas tres líneas, Pila<Int> es comparable, hashable y segura de enviar entre dominios de aislamiento; Pila<() -> Void> no es ninguna de las tres, y el compilador lo dice en el punto exacto donde intentas usarlo. El cuerpo de la extensión suele estar vacío porque la síntesis automática de Equatable y Hashable cubre el trabajo cuando todas las propiedades almacenadas cumplen el requisito.

Cascada y comprobación dinámica

La propiedad más valiosa es que las conformidades condicionales se componen sin que nadie las declare explícitamente para cada combinación. El compilador resuelve la cadena entera recorriendo el anidamiento.

let matriz: [[Int]] = [[1, 2], [3]]
matriz == [[1, 2], [3]]              // true: Equatable en cascada

let conjunto: Set<[String?]> = [["a", nil]]   // Hashable en cascada

Y esa resolución también existe en tiempo de ejecución. Los metadatos del tipo llevan la condición, de modo que una conversión dinámica devuelve la respuesta correcta en lugar de fallar por precaución:

func esComparable(_ x: Any) -> Bool { x is any Equatable }

esComparable([1, 2])                 // true
esComparable([{ () -> Void in }])    // false, la condicion no se cumple

flowchart TD
A[Array de Optional de Int] --> B[Array conforma a Equatable si su Element conforma]
B --> C[Optional conforma a Equatable si su Wrapped conforma]
C --> D[Int conforma a Equatable de forma incondicional]
D --> E[Resultado: la cadena entera es Equatable]
style E fill:#a6e3a1,color:#11111b

Reglas, límites y trampas

La conformidad condicional está gobernada por una regla dura: un tipo conforma a un protocolo de una sola manera en todo el programa. No puedes declarar dos conformidades al mismo protocolo con condiciones distintas, aunque sean disjuntas.

extension Pila: Codable where Elemento: Codable {}
// extension Pila: Codable where Elemento: RawRepresentable {}
// error: conformidad duplicada de Pila a Codable

La razón es la coherencia global: si existieran dos rutas, dos módulos distintos podrían ver comportamientos incompatibles para el mismo tipo y el despacho dinámico dejaría de ser determinista. La solución cuando de verdad necesitas dos comportamientos es introducir dos tipos envoltorio, no dos conformidades.

Tres trampas más que conviene tener presentes:

• La condición debe ser satisfacible. Una restricción imposible no es un error inmediato; simplemente hace que la conformidad no exista nunca y el diagnóstico aparecerá lejos, en el punto de uso.
• Conformidad retroactiva. Extender un tipo de otro módulo para que conforme a un protocolo de un tercer módulo obliga a marcar la intención de forma explícita, porque si el dueño del tipo añade su propia conformidad más adelante, el programa se rompe en el enlazado.
• No confundir con la especialización. Que Pila<Int> sea comparable no significa que exista un tipo Pila<Int> distinto en el sistema de tipos: hay un solo Pila genérico y una tabla de conformidad que solo se instala cuando la condición se cumple.

Diseñar un contenedor completo

Juntemos las reglas en un tipo realista: un resultado paginado, el envoltorio que devuelve casi cualquier cliente de API. La estrategia es declarar el tipo sin ninguna restricción y añadir las capacidades por capas, cada una con su condición.

struct Pagina<Elemento> {
    let elementos: [Elemento]
    let siguiente: String?
}

extension Pagina: Equatable where Elemento: Equatable {}
extension Pagina: Hashable where Elemento: Hashable {}
extension Pagina: Decodable where Elemento: Decodable {}
extension Pagina: Encodable where Elemento: Encodable {}
extension Pagina: Sendable where Elemento: Sendable {}

extension Pagina: CustomStringConvertible where Elemento: CustomStringConvertible {
    var description: String {
        elementos.map(\.description).joined(separator: ", ")
    }
}

Observa la disciplina de diseño. La declaración del tipo no impone nada, así que Pagina funciona con cualquier elemento, incluso con uno que no sea codificable. Cada extensión añade una capacidad exactamente donde tiene sentido, y ninguna de ellas estrecha el universo de tipos admitidos por las demás. Si hubieras escrito struct Pagina<Elemento: Codable>, habrías cerrado la puerta a todos los elementos no codificables para siempre, a cambio de nada.

La regla práctica es esta: las restricciones van en las extensiones, no en la declaración del tipo, salvo cuando el tipo no puede existir sin ellas. Un diccionario necesita que su clave sea hashable para funcionar, así que esa restricción sí pertenece a la declaración. Una página no necesita nada para existir.