associatedtype en Swift: el mecanismo que hace posible la abstracción genérica en protocolos

Arturo Rivas Arias

20 de abril de 2026

🧩 associatedtype es una de esas características del sistema de tipos de Swift que pasan desapercibidas al principio, pero que están detrás de casi todo lo que usamos a diario. El protocolo Sequence, la colección Array, el propio protocolo View de SwiftUI: todos ellos dependen de esta misma pieza. Entender cómo funciona no es solo un ejercicio teórico; es comprender el contrato que Swift establece entre la abstracción y la seguridad de tipos en tiempo de compilación.

🔤 Un associatedtype define un tipo dentro de un protocolo. Es la forma que tiene el protocolo de decir: opero sobre un tipo concreto, pero no soy yo quien decide cuál es; lo decidirá el tipo que me conforme. Esto distingue los protocolos con tipo asociado de los protocolos simples: en lugar de fijar el tipo en la definición del protocolo, se deja ese hueco abierto para que cada conformante lo rellene según su propia lógica.

protocol Repository {
    associatedtype Entity

    func findAll() -> [Entity]
    func save(_ entity: Entity)
}

El protocolo Repository no sabe nada sobre Entity más allá de su existencia. Cuando un tipo concreto adopta el protocolo, Swift infiere automáticamente el tipo asociado a partir de la implementación (si es capaz), o puedes declararlo explícitamente con typealias si la inferencia no es suficiente.

⚖️ La pregunta más frecuente al encontrarse con associatedtype es en qué se diferencia de los genéricos clásicos. Con los genéricos, es el llamante quien elige el tipo en el momento de uso: struct Stack<T> deja en manos de quien instancia Stack decidir qué es T. Con associatedtype, es el conformante del protocolo quien fija el tipo en el momento de la implementación. Una es una herramienta para tipos concretos y flexibles; la otra, para abstracciones con comportamiento definido.

// Genérico: el tipo lo elige quien crea el valor
struct EventQueue<Event> {
    private var events: [Event] = []

    mutating func enqueue(_ event: Event) {
        events.append(event)
    }

    mutating func dequeue() -> Event? {
        events.isEmpty ? nil : events.removeFirst()
    }
}

// Protocolo con associatedtype: el tipo lo elige quien conforma
protocol EventProcessor {
    associatedtype Event
    func process(_ event: Event)
}

🔒 Los tipos asociados pueden llevar restricciones, y eso es donde la herramienta gana músculo real. Puedes exigir que el tipo asociado conforme a otro protocolo, lo que te permite escribir extensiones condicionales que añaden comportamiento solo cuando el tipo cumple ciertos requisitos.

protocol DataSource {
    associatedtype Record: Identifiable & Sendable

    func fetch() async throws -> [Record]
}

extension DataSource where Record: Comparable {
    func fetchSorted() async throws -> [Record] {
        try await fetch().sorted()
    }
}

Con where, la extensión solo existe si Record es Comparable. El código que trabaja con un DataSource cuyo Record no es comparable simplemente no ve el método fetchSorted. El compilador hace cumplir esa restricción sin ningún coste en tiempo de ejecución.

🏗️ SwiftUI es el ejemplo más omnipresente del sistema. El protocolo View está definido esencialmente así en la librería estándar:

public protocol View {
    associatedtype Body: View
    @ViewBuilder var body: Self.Body { get }
}

SwiftUI necesita conocer el tipo exacto de Body en tiempo de compilación para optimizar el árbol de renderizado. Si body devolviese un View existencial, el sistema perdería esa información y tendría que recurrir a un despachado dinámico en tiempo de ejecución al no conocer los tipos, con el coste de rendimiento que ello implica. El associatedtype permite que el compilador construya una representación estática del árbol de vistas y lo optimice con cero sobrecarga en tiempo de ejecución.

🚧 Este diseño introduce una limitación que todo desarrollador de Swift encuentra antes o después: un protocolo con associatedtype no puede usarse directamente como tipo concreto. La razón es que Swift necesita conocer el tipo asociado para razonar sobre la memoria y el comportamiento del valor, y un protocolo con ese hueco abierto no proporciona la información necesaria.

// ❌ No compila: protocol 'Repository' can only be used as a generic constraint
func buildRepositories() -> [Repository] { ... }

// ✅ Correcto: usando una restricción genérica
func process<R: Repository>(repository: R) where R.Entity == UserProfile {
    let users = repository.findAll()
    // ...
}

💡 Cuando necesitas heterogeneidad real —guardar en un array valores de tipos distintos que conforman el mismo protocolo—, la solución canónica es el borrado de tipos (type erasure). El patrón consiste en envolver el tipo concreto en una clase o struct que sí tiene tipo fijo, ocultando el tipo subyacente.

struct AnyRepository<Entity>: Repository {
    private let _findAll: () -> [Entity]
    private let _save: (Entity) -> Void

    init<R: Repository>(_ base: R) where R.Entity == Entity {
        _findAll = { base.findAll() }
        _save = { base.save($0) }
    }

    func findAll() -> [Entity] { _findAll() }
    func save(_ entity: Entity) { _save(entity) }
}

Desde Swift 5.7, some y any ofrecen formas más ergonómicas de manejar estos escenarios. some Repository en una posición de retorno indica que el tipo concreto es fijo pero opaco; any Repository introduce el existencial abierto y permite heterogeneidad con un overhead explícito y visible en el código.

// Swift 5.7+: existencial abierto con any
func makeRepositories() -> [any Repository] { ... }

// Opaque return type con some
func makeUserRepository() -> some Repository { ... }

🏛️ En arquitecturas más elaboradas, associatedtype permite definir contratos de capa que cada módulo satisface a su manera sin acoplamiento entre ellos. Un caso habitual es definir un protocolo de ViewModel genérico donde el tipo de estado lo determina cada feature.

protocol FeatureViewModel: ObservableObject {
    associatedtype ViewState: Equatable
    associatedtype Intent

    var state: ViewState { get }
    func handle(_ intent: Intent)
}

// Cada feature define su propio estado e intenciones
final class SearchViewModel: FeatureViewModel {
    struct ViewState: Equatable {
        var query: String = ""
        var results: [SearchResult] = []
        var isLoading: Bool = false
    }

    enum Intent {
        case updateQuery(String)
        case submitSearch
        case clearResults
    }

    @Published private(set) var state = ViewState()

    func handle(_ intent: Intent) {
        switch intent {
        case .updateQuery(let query):
            state.query = query
        case .submitSearch:
            state.isLoading = true
            // lanzar búsqueda...
        case .clearResults:
            state = ViewState()
        }
    }
}

El protocolo FeatureViewModel impone que ViewState sea Equatable, lo que permite a SwiftUI o a cualquier capa de presentación comparar estados anteriores y nuevos sin saber nada del tipo concreto. La restricción viaja con el protocolo, no hay que recordarla en cada implementación.

👨‍💻 Comprender associatedtype es comprender cómo Swift construye sus abstracciones de alto rendimiento sin sacrificar seguridad de tipos. No es una característica avanzada reservada para autores de librerías: aparece en el código de producción cada vez que defines un protocolo que necesita trabajar con más de un tipo concreto. Cuanto antes se integra este modelo mental, más natural resulta diseñar APIs expresivas, componibles y seguras en Swift.