associatedtype y Self: protocolos con requisitos de tipo

Hay un momento en el aprendizaje de Swift en que el compilador rechaza algo que parecía obvio: guardar en un array valores de un protocolo perfectamente razonable. La causa es que ese protocolo no describe un contrato, sino una familia de contratos parametrizada por un tipo que solo el conformante conoce. Un protocol con associatedtype o con Self en posición de entrada no es un tipo; es una plantilla de tipos. Entender por qué —y no solo memorizar el remedio— es la diferencia entre pelear con el compilador y diseñar abstracciones que se dejan usar.

Un hueco de tipo dentro del contrato

Un associatedtype es un parámetro de tipo que el protocolo declara pero no fija: cada conformante decide con qué lo rellena.

protocol Contenedor {
    associatedtype Elemento
    var cuenta: Int { get }
    mutating func anadir(_ item: Elemento)
    subscript(i: Int) -> Elemento { get }
}

struct Pila: Contenedor {
    private var items: [Int] = []
    var cuenta: Int { items.count }
    mutating func anadir(_ item: Int) { items.append(item) }   // Elemento = Int
    subscript(i: Int) -> Int { items[i] }
}

Swift infiere que Elemento es Int a partir de las firmas implementadas; podrías escribirlo explícitamente con typealias Elemento = Int. Lo decisivo es que Contenedor no nombra un tipo único: nombra Contenedor con Elemento igual a Int, con Elemento igual a String, y así infinitas veces. Es una familia.

El hueco puede acotarse. associatedtype Elemento: Equatable exige que el relleno conforme a algo, y una cláusula where puede relacionar varios huecos entre sí, como hace la biblioteca estándar al pedir que el elemento de un iterador coincida con el de su secuencia.

Self, el tipo del conformante

Self no es un associatedtype declarado por ti, pero se comporta igual: es un hueco implícito que vale, en cada conformidad, el propio tipo conformante.

protocol Duplicable {
    func copia() -> Self              // Self en posicion de salida
}

protocol Combinable {
    func combinar(con otro: Self) -> Self   // Self en posicion de entrada
}

La distinción entre las dos posiciones es más importante que la sintaxis. En salida, Self promete devolver algo del mismo tipo; el que llama recibe información. En entrada, Self exige recibir algo del mismo tipo, y ahí aparece el problema: si tuvieras dos valores distintos que solo conoces como Combinable, nada garantiza que sean del mismo tipo concreto, y combinar sería una llamada imposible de tipar. Equatable es el caso arquetípico: el operador de igualdad compara dos Self, no dos cosas cualesquiera.

Por qué no es un tipo sin más

Un protocolo sin requisitos de tipo puede usarse como existencial: una caja que dice “aquí dentro hay algún valor que cumple el contrato”. La caja funciona porque toda la información necesaria para operar está en el contrato.

Con un hueco de tipo, la caja pierde una pieza. Dos cajas de Contenedor pueden esconder rellenos incompatibles, así que el compilador no puede tipar una operación que mezcle sus elementos.

// Antes de Swift 5.7 esto era directamente un error de compilacion.
// Hoy es legal, pero con limites reales:
let cajas: [any Contenedor] = [Pila(), Pila()]

for caja in cajas {
    print(caja.cuenta)          // ok: no menciona Elemento
    // caja.anadir(1)           // error: Elemento no se conoce aqui
}

La regla que subyace es limpia: puedes usar los miembros cuyo tipo asociado aparezca solo en salida —Swift lo abre como un tipo opaco anónimo— y no puedes usar los que lo tengan en entrada, porque tendrías que fabricar un valor de un tipo que nadie sabe nombrar.

Si el protocolo declara un tipo asociado primario, puedes cerrar el hueco al escribir la existencial y recuperarlo casi todo:

protocol Coleccionable<Elemento> {
    associatedtype Elemento
    func todos() -> [Elemento]
}

let fuentes: [any Coleccionable<Int>] = []   // hueco cerrado en Int

flowchart TB
p[protocolo con associatedtype o Self] --> q{el hueco esta cerrado en el uso}
q -->|no| lim[existencial limitada solo miembros de salida]
q -->|si por restriccion generica| gen[tipo concreto conocido en compilacion]
q -->|si por tipo asociado primario| pri[existencial utilizable con el hueco fijado]
gen --> full[acceso a todos los miembros y especializacion]
pri --> full

Las tres salidas

Las tres conviven en una misma API sin contradecirse:

// 1. El llamante elige el tipo: se especializa, coste cero.
func sumar<C: Contenedor>(_ c: C) -> Int where C.Elemento == Int {
    (0..<c.cuenta).reduce(0) { $0 + c[$1] }
}

// 2. El implementador elige y lo oculta: un solo tipo, identidad conservada.
func pilaVacia() -> some Contenedor { Pila() }

// 3. Tipos distintos en el mismo sitio: caja en ejecucion, miembros limitados.
func contarTodo(_ cajas: [any Contenedor]) -> Int {
    cajas.reduce(0) { $0 + $1.cuenta }
}

Fíjate en la cláusula where C.Elemento == Int de la primera: solo la versión genérica puede hablar del hueco por su nombre y relacionarlo con otros tipos. Esa capacidad —expresar restricciones entre huecos— es la que se pierde al pasar a la existencial, y suele ser la razón real por la que un diseño acaba obligado a ser genérico.