El modelo mental completo: una sola imagen de todo Swift

Has recorrido treinta y ocho niveles de piezas: semántica de valor, opcionales, closures, enums, protocolos, genéricos, some y any, property wrappers, result builders, macros, errores, ARC, copy-on-write, ownership, punteros, interoperabilidad, Sendable, actores, secuencias asíncronas, tareas estructuradas, actores distribuidos. Presentadas así parecen un catálogo, y un catálogo se olvida. No lo son. Swift tiene una idea rectora, y una sola, que aparece disfrazada en cada uno de esos capítulos: toda mutación debe tener un conjunto de observadores conocido en tiempo de compilación. La semántica de valor es esa idea aplicada a un objeto; la ley de exclusividad, aplicada a un instante; el aislamiento de actores, aplicada al tiempo y a los hilos; los genéricos, aplicados a través de una frontera de abstracción. Cuando ves eso, el lenguaje deja de ser una lista de reglas y se convierte en un teorema con cuatro corolarios.

El principio y sus cuatro escalas

Un programa incorrecto casi siempre lo es por la misma razón: algo cambió y alguien lo vio cambiar sin esperarlo. El resto son variantes. Un array que se modifica mientras se itera, un objeto compartido que otro módulo mutó, un dato que dos hilos escriben a la vez, un puntero cuyo dueño ya lo liberó. Swift no ataca esos bugs uno a uno: ataca la condición que los hace posibles, y lo hace en cuatro escalas anidadas.

En la escala del instante, la ley de exclusividad prohíbe que dos accesos a la misma variable se solapen si al menos uno escribe. Por eso inout es copy-in copy-out y por eso no puedes pasar la misma propiedad dos veces al mismo swap. En la escala del objeto, la semántica de valor garantiza que el conjunto de observadores de una mutación tiene exactamente un elemento: tú. Copy-on-write hace que esa garantía sea barata en lugar de ruinosa. En la escala del tiempo, el aislamiento de actores extiende la exclusividad a los accesos que no se solapan en el código pero sí en la ejecución: Sendable marca qué puede cruzar y await marca dónde otro pudo colarse. Y en la escala de la abstracción, los genéricos y los protocolos transportan las tres garantías anteriores a través de una frontera donde el tipo concreto se desconoce.

flowchart TD
P[Principio: toda mutacion tiene observadores conocidos]
P --> I[Escala instante: ley de exclusividad e inout]
P --> O[Escala objeto: semantica de valor y COW]
P --> T[Escala tiempo: Sendable actores aislamiento]
P --> A[Escala abstraccion: genericos protocolos ownership]
I --> V[Verificado por el compilador o por el runtime]
O --> V
T --> V
A --> V
style P fill:#cba6f7,color:#11111b
style V fill:#a6e3a1,color:#11111b

La palabra que une el diagrama es verificado. Swift no te pide disciplina: te pide que escribas lo suficiente para que la disciplina sea comprobable. Sendable no hace que un tipo sea seguro, declara que lo es y obliga al compilador a revisarlo. borrowing no acelera nada por sí solo, promete que no consumirás el valor y permite al optimizador eliminar el retain. Esa es la mecánica constante del lenguaje: una anotación que suena a promesa y un verificador que la cobra.

Que las cuatro escalas son la misma se ve mejor con dos programas casi idénticos que fallan por la misma razón a distinta velocidad.

// Escala instante: dos accesos exclusivos solapados. Error de compilacion.
var puntos = [1, 2, 3]
// swap(&puntos[0], &puntos[0])

// Escala tiempo: dos accesos exclusivos que no se solapan en el texto
// pero si en la ejecucion. En modo estricto, tambien error de compilacion.
final class Contador { var n = 0 }
let c = Contador()
// Task { c.n += 1 }
// Task { c.n += 1 }

El primer caso lo detecta la ley de exclusividad; el segundo, la comprobación de Sendable. Son verificadores distintos, con mensajes distintos y con años de diferencia en su llegada al lenguaje, pero comprueban exactamente la misma propiedad: que no haya dos escrituras cuyo orden nadie determinó. Cuando entiendes eso, los errores de concurrencia dejan de parecer una categoría aparte y se leen como lo que son, exclusividad extendida al eje del tiempo.

Un tipo que toca las cuatro escalas a la vez

La forma más rápida de comprobar que el modelo está integrado es escribir un tipo pequeño donde las cuatro escalas aparecen en veinte líneas. Una matriz densa sirve: necesita almacenamiento contiguo por rendimiento, semántica de valor por corrección, ARC para gestionar el buffer y Sendable para poder viajar.

struct Matriz: Sendable {
    private final class Almacen {
        let datos: UnsafeMutableBufferPointer<Double>
        init(capacidad: Int) {
            datos = .allocate(capacity: capacidad)
            datos.initialize(repeating: 0)
        }
        init(copiando otro: Almacen) {
            datos = .allocate(capacity: otro.datos.count)
            _ = datos.initialize(from: otro.datos)
        }
        deinit { datos.deinitialize(); datos.deallocate() }
    }

    private var almacen: Almacen
    let filas: Int
    let columnas: Int

    init(filas: Int, columnas: Int) {
        self.filas = filas
        self.columnas = columnas
        self.almacen = Almacen(capacidad: filas * columnas)
    }

    subscript(f: Int, c: Int) -> Double {
        get { almacen.datos[f * columnas + c] }
        set {
            if !isKnownUniquelyReferenced(&almacen) {
                almacen = Almacen(copiando: almacen)
            }
            almacen.datos[f * columnas + c] = newValue
        }
    }
}

Lee ahora cada decisión como una respuesta a una escala distinta. struct externo: escala objeto, el usuario obtiene semántica de valor y nadie puede alias su matriz por accidente. final class interno: escala memoria, hace falta una identidad para que varias copias compartan un buffer y para que ARC decida cuándo liberarlo; final además elimina el despacho dinámico. isKnownUniquelyReferenced: la bisagra exacta entre las dos escalas anteriores, el punto donde el conteo de referencias se usa para simular que cada copia tiene su propio almacén. El deinit que desinicializa y libera: escala instante, el buffer no tiene dueño automático y el deinit es el único lugar donde el ciclo de vida se cierra. Y Sendable en el struct: escala tiempo, la promesa de que enviar esta matriz a otro dominio de aislamiento no crea una carrera, promesa que es cierta precisamente porque el copy-on-write garantiza que nadie más escribirá en el mismo buffer.

Las cuatro costuras donde el modelo se rompe

Ningún sistema de tipos es total, y el valor de conocer el modelo está sobre todo en saber dónde deja de aplicarse. Swift tiene cuatro costuras declaradas, y en las cuatro la estrategia es idéntica: el compilador se retira, lo dice en voz alta con una palabra fea, y te transfiere la obligación de prueba.

Estas cuatro costuras explican por qué el track dedicó niveles enteros a punteros, interoperabilidad, reentrada y migración de código heredado. No eran apéndices: son el borde del teorema, y todo bug serio que escribirás en Swift vivirá en uno de esos bordes o en la unión de dos.

La costura más traicionera es la cuarta, porque no tiene palabra fea que la señale. Un await parece una espera y es una cesión de turno: entre la suspensión y la reanudación, otras tareas entran al actor y el estado que leíste antes puede haber cambiado.

actor Inventario {
    private var existencias: [String: Int] = [:]

    func reservar(_ sku: String) async throws {
        guard let n = existencias[sku], n > 0 else { throw Falta.agotado }
        try await registrarEnRemoto(sku)   // aqui otro puede entrar y vaciar el stock
        existencias[sku] = n - 1           // decrementa con un valor caducado
    }
}

El aislamiento hizo su trabajo: no hay carrera de datos, ninguna escritura se solapa y el compilador está en silencio. Lo que se rompió es una invariante que abarcaba dos instantes, y esa clase de corrección nunca fue competencia del sistema de tipos. El modelo mental completo incluye saber exactamente eso: dónde termina la garantía mecánica y empieza tu obligación de razonar.

Usar el modelo para decidir

Un modelo mental solo vale si produce decisiones. Este produce una, y se toma con cuatro preguntas en orden estricto.

Primera: ¿este dato tiene identidad? Es decir, ¿dos instancias con los mismos campos son la misma cosa o cosas distintas? Un usuario con el mismo nombre y el mismo correo que otro es el mismo usuario si comparten identificador; una coordenada con los mismos números es indistinguible de la otra. Identidad significa class o actor; ausencia de identidad significa struct o enum, y esta pregunta se responde antes que ninguna otra porque condiciona el resto.

Segunda: ¿el estado se toca desde más de un dominio de aislamiento? Si la respuesta es no, un tipo de valor Sendable o un tipo confinado al actor principal basta. Si es sí y hay identidad, la respuesta natural es actor; si es sí y no hay identidad, basta con que el tipo sea Sendable de verdad y no por decreto.

Tercera: ¿la copia es aceptable? Si el tipo almacena mucho o su copia tiene efectos, la respuesta es copy-on-write con almacenamiento interno de referencia, tal como la Matriz de arriba. Si el tipo representa un recurso que no debe duplicarse jamás —un descriptor de fichero, una transacción, una clave criptográfica— la respuesta es ~Copyable, y entonces el compilador impide la copia en vez de hacerla barata.

Cuarta: ¿quién debe verlo a través de la frontera de abstracción? Un tipo concreto no oculta nada, some Protocolo oculta la identidad del tipo pero conserva su estaticidad y el rendimiento, any Protocolo la borra por completo a cambio de despacho dinámico y una caja. La regla operativa es empezar por lo más estático que resuelva el problema y bajar solo cuando haga falta heterogeneidad real en tiempo de ejecución.