El protocolo que no podía ser un tipo

Durante años, escribir un array de Dibujable compilaba y escribir un array de Collection no. El compilador respondía con una frase que casi todo el mundo ha leído alguna vez: el protocolo solo puede usarse como restricción genérica porque tiene requisitos de Self o de tipo asociado. No era un capricho ni una carencia temporal del compilador: era una verdad sobre qué es un protocolo. Entender por qué un contrato con huecos de tipo no puede comportarse como un tipo cualquiera es entender de dónde salen some y any, y por qué son dos respuestas distintas —una estática, otra dinámica— a una misma imposibilidad.

Un protocolo tiene dos vidas

Un protocolo sencillo —sin tipos asociados, sin requisitos de Self— vive dos vidas a la vez, y es fácil no notar que son distintas.

protocol Dibujable {
    func dibujar() -> String
}

struct Circulo: Dibujable { func dibujar() -> String { "circulo" } }
struct Cuadrado: Dibujable { func dibujar() -> String { "cuadrado" } }

// Vida 1: restriccion. T es UN tipo concreto, elegido en cada llamada.
func pintarEstatico<T: Dibujable>(_ figura: T) -> String { figura.dibujar() }

// Vida 2: tipo. Una caja capaz de contener CUALQUIER conformante.
let galeria: [any Dibujable] = [Circulo(), Cuadrado()]

En la primera vida el protocolo es un adjetivo: califica a un tipo que el compilador resolverá en el punto de llamada. En la segunda es un sustantivo: nombra por sí mismo un tipo de dato, uno cuyos valores pueden ser hoy un Circulo y mañana un Cuadrado. La primera vida es universal —para todo T que conforme—; la segunda es existencial —existe algún tipo, no sé cuál, y aquí está el valor—. Esta distinción, que en lógica separa el cuantificador universal del existencial, es la columna vertebral de todo el nivel.

Los tipos asociados rompen la segunda vida

Añade un solo associatedtype y la segunda vida se desmorona.

protocol Contenedor {
    associatedtype Elemento
    var cuenta: Int { get }
    mutating func agregar(_ nuevo: Elemento)
    subscript(indice: Int) -> Elemento { get }
}

La pregunta que mata la idea es concreta: si tuvieras una variable declarada simplemente como Contenedor, sin más, ¿qué tipo devolvería su subíndice? ¿Int, si dentro hay un array de enteros? ¿String, si hay otro? El compilador tendría que responder antes de saber qué valor guardarás dentro, y no puede: el tipo de retorno depende del conformante concreto, que es justo lo que la caja pretende olvidar. Hasta Swift 5.6 el compilador zanjaba el asunto en la fase de comprobación de tipos:

error: protocol 'Contenedor' can only be used as a generic constraint
       because it has Self or associated type requirements

Los requisitos de Self producen el mismo colapso por otra vía. Equatable exige un operador cuyos dos operandos sean del mismo tipo:

protocol Combinable {
    static func combinar(_ a: Self, _ b: Self) -> Self
}

Dos cajas independientes podrían contener un Int y un String. Pedirles que se combinen es pedir algo que ningún conformante prometió: la promesa era combinarse consigo mismo, no con cualquier otro habitante del protocolo. La caja borra precisamente la información —la identidad del tipo— que el requisito necesita para tener sentido.

Un protocolo es una familia, no un tipo

La lectura correcta es esta: Collection no es un tipo. Es un esquema parametrizado por Element, Index, SubSequence y varios más. Cada elección de esos parámetros produce un tipo distinto de la familia. Escribir la familia entera donde se espera un tipo es un error de categoría, como escribir la palabra función donde se espera un número.

// Cada linea es un miembro distinto de la familia Collection
let a: [Int]              // Element es Int, Index es Int
let b: Set<String>        // Element es String, Index es un indice de tabla hash
let c: Substring          // Element es Character, Index es String.Index

Un tipo, para serlo, necesita responder tres preguntas sin ambigüedad: cuánto ocupa en memoria, cómo se copia y se destruye, y qué operaciones admite con qué firmas. Un protocolo sin tipos asociados puede responderlas de forma uniforme para todos sus conformantes. Uno con tipos asociados no: la tercera respuesta cambia con cada miembro de la familia.

La analogía más útil es la de una función. Un protocolo con tipos asociados se comporta como una función que va de tipos a tipos: dale un conformante y te devuelve la firma concreta de cada requisito. Una función no es un valor de su codominio, igual que la raíz cuadrada no es un número. Confundir la función con sus resultados es el error de categoría exacto que el compilador denunciaba.

// Cada conformidad instancia la familia con valores distintos
extension Array: Contenedor {
    typealias Elemento = Element     // el hueco queda resuelto aqui
}

Y hay un matiz que conviene fijar desde ya: la prohibición nunca afectó al protocolo entero, sino a los miembros cuya firma depende del hueco. Contar elementos no depende del tipo asociado y siempre fue seguro; insertar uno sí depende, y por eso quedaba fuera. Swift 5.7 formalizó justamente esa distinción: hoy la caja se construye siempre, y el compilador te bloquea miembro a miembro en lugar de vetar el tipo completo.

flowchart TB
P[Protocolo] --> Q{Tiene tipos asociados o requisitos de Self}
Q -->|No| T[Puede actuar como tipo directamente]
Q -->|Si| F[Es una familia de tipos, no un tipo]
F --> S[Salida 1 con some: fijar un miembro y ocultarlo]
F --> A[Salida 2 con any: olvidar cual y encajarlo]
S --> E[Despacho estatico y coste cero]
A --> D[Despacho dinamico y coste de caja]
style F fill:#f38ba8,color:#11111b
style S fill:#a6e3a1,color:#11111b
style A fill:#89b4fa,color:#11111b

Dos salidas: fijar u olvidar

Ante la misma imposibilidad, Swift ofrece dos caminos que no compiten sino que se reparten el territorio.

La primera salida es fijar un miembro concreto de la familia y ocultar cuál. Eso es some: el compilador sabe con exactitud que devuelves un Array de enteros; quien llama solo sabe que devuelves algo que conforma. El tipo existe, es único y es estático; simplemente no aparece en la firma.

func numeros() -> some Collection {   // el compilador sabe que es [Int]
    [1, 2, 3]
}

La segunda salida es olvidar cuál y meterlo en una caja capaz de albergar a cualquiera. Eso es any: el tipo concreto se decide en ejecución y viaja acompañado de la maquinaria necesaria para operar sobre él sin conocerlo.

let figuras: [any Dibujable] = [Circulo(), Cuadrado()]  // heterogeneo, dinamico

Las dos salidas no compiten: se reparten el trabajo según dónde viva la variedad. Si la variedad está en el código —muchos conformantes, pero uno solo por cada punto del programa—, la salida es some. Si la variedad está en los datos —el mismo punto ve tipos distintos en ejecución—, la salida es any.

Desde Swift 5.6, la palabra any es obligatoria al escribir un existencial: lo que antes era un nombre de protocolo desnudo —ambiguo entre las dos vidas— hoy debe declararse. Y desde Swift 5.7 los existenciales están permitidos incluso para protocolos con tipos asociados: la caja se construye, aunque los miembros contravariantes sigan fuera de alcance salvo que abras el existencial o restrinjas el tipo asociado.