Implementar copy-on-write en tu propio tipo

Llega el momento de escribir el patrón entero. No es difícil —cabe en cuarenta líneas— pero es implacable: hay media docena de invariantes y romper cualquiera de ellas no produce un error de compilación, sino un tipo que parece funcionar y que, en el caso equivocado, deja que una copia observe la mutación de otra. Ese es el peligro específico de copy-on-write manual: los fallos no se manifiestan como caídas sino como aliasing silencioso, y aparecen tarde, en el código de otro, mucho después de que hayas dejado de mirar. Escribirlo bien exige entender que el struct público es una fachada sin estado propio salvo un puntero, que la clase privada es el dato real, y que el único punto del programa autorizado a escribir en ella es una función que primero comprueba la unicidad.

El esqueleto canónico

Supongamos un tipo que envuelve un búfer de bytes de tamaño arbitrario. La estrategia es partirlo en dos: una clase que posee el dato y un struct que posee una referencia a esa clase.

private final class Almacen {
    var bytes: [UInt8]
    init(bytes: [UInt8]) { self.bytes = bytes }
    init(copiando otro: Almacen) { self.bytes = otro.bytes }
}

struct Bufer {
    private var almacen: Almacen

    init(_ bytes: [UInt8] = []) {
        almacen = Almacen(bytes: bytes)
    }

    var count: Int { almacen.bytes.count }
}

Cuatro decisiones ya están tomadas en estas líneas. La clase es final, porque una subclase podría añadir estado que el inicializador de copia no duplicaría y porque el despacho dinámico no aporta nada aquí. Es private, porque el patrón entero depende de que ninguna referencia al almacenamiento escape del tipo. Tiene un inicializador de copia explícito, que será el encargado de materializar la duplicación y el único sitio donde tendrás que acordarte de añadir los campos nuevos. Y el struct guarda la referencia en un var, no en un let, porque en un momento tendrá que pasarla como inout.

El punto único de mutación

Todo lo demás gira alrededor de una función privada que garantiza la exclusividad antes de cualquier escritura.

extension Bufer {
    private mutating func asegurarUnico() {
        if !isKnownUniquelyReferenced(&almacen) {
            almacen = Almacen(copiando: almacen)
        }
    }

    mutating func append(_ byte: UInt8) {
        asegurarUnico()
        almacen.bytes.append(byte)
    }

    mutating func removeAll() {
        asegurarUnico()
        almacen.bytes.removeAll()
    }
}

La función tiene que ser mutating por dos motivos encadenados: reasigna self.almacen en la rama de copia, y necesita pasar almacen como inout, lo cual exige acceso de escritura a self. Esto tiene una consecuencia de diseño que conviene interiorizar: cualquier método que pueda escribir en el almacenamiento debe ser mutating, aunque no parezca modificar nada visible. Si escribes una función no mutating que toca almacen.bytes, el compilador te dejará —la referencia es una constante, pero el objeto al que apunta no lo es— y habrás abierto un agujero por el que una copia verá los cambios de otra.

flowchart TB
api[Metodo mutating publico] --> unico[asegurarUnico]
unico --> chk[isKnownUniquelyReferenced sobre almacen]
chk --> si[Exclusivo luego seguir]
chk --> no[Compartido luego construir Almacen copiando]
no --> reasig[Reasignar self almacen al nuevo]
reasig --> escribir[Escribir en el almacenamiento]
si --> escribir
lect[Metodo de lectura] --> directo[Leer almacen sin comprobar nada]
style unico fill:#cba6f7,color:#11111b
style no fill:#f9e2af,color:#11111b
style escribir fill:#a6e3a1,color:#11111b
style directo fill:#89b4fa,color:#11111b

Los accesores: el problema del subíndice

Exponer un subíndice ingenuo funciona pero desperdicia trabajo. Con get y set clásicos, una expresión como bufer[3] += 1 obliga al compilador a leer el elemento, operar y escribirlo de vuelta, y en tipos con carga útil grande esa lectura copia. La solución que usa la biblioteca estándar son los accesores de corrutina: _read cede una lectura prestada sin copiar y _modify cede una referencia mutable directa al almacenamiento.

extension Bufer {
    subscript(i: Int) -> UInt8 {
        _read {
            yield almacen.bytes[i]
        }
        _modify {
            asegurarUnico()
            yield &almacen.bytes[i]
        }
    }
}

La forma es peculiar: el cuerpo se ejecuta hasta el yield, el llamante hace su trabajo con el valor cedido, y luego el cuerpo continúa tras el yield si hay algo más que hacer. Para el caso mutable, esto significa que asegurarUnico corre una sola vez, el llamante escribe directamente sobre el elemento en el búfer, y no hay ningún valor intermedio que copiar. Es la diferencia entre una operación proporcional al tamaño del elemento y una operación en el sitio, y es también lo que hace que matriz[i][j] = x sea eficiente en Swift, como veremos en la lección siguiente.

Conviene ser honesto sobre el estatus de estos accesores: _read y _modify llevan guion bajo porque siguen siendo oficialmente internos y su sintaxis puede cambiar. La propuesta que los estabiliza bajo los nombres read y modify lleva tiempo en el horno. Úsalos con conocimiento de causa, sabiendo que son la herramienta correcta y que la biblioteca estándar entera depende de ellos.

La lista de invariantes

Un tipo con copy-on-write manual es correcto si y solo si sostiene todo lo siguiente, y merece la pena auditarlo punto por punto cada vez que lo tocas.

El almacenamiento es una clase Swift nativa, final y private, y ninguna referencia a él escapa: no se devuelve, no se pasa a un closure que sobreviva a la llamada, no se guarda en otro objeto. Toda escritura pasa por la comprobación de unicidad, y por tanto todo método que escriba es mutating. El inicializador de copia duplica todos los campos, y si alguno es a su vez un tipo con copy-on-write, basta asignarlo porque él se encargará de lo suyo. Ninguna propiedad del struct fuera del almacenamiento guarda estado observable; si guardas, por ejemplo, un count cacheado en el struct, tendrás dos fuentes de verdad que pueden divergir tras una copia.

Y hay un caso que merece mención aparte: si el almacenamiento contiene referencias a otros objetos mutables, copiarlo superficialmente no basta. La copia debe ser profunda hasta el punto donde la mutabilidad se detiene. Un almacenamiento que guarda instancias de una clase final con todas sus propiedades let puede compartirlas sin peligro, porque nadie puede observar un cambio que no puede ocurrir; uno que guarda objetos mutables debe duplicarlos también, o habrás construido un híbrido con semántica de valor solo en el primer nivel.

extension Bufer: Equatable, CustomStringConvertible {
    static func == (a: Bufer, b: Bufer) -> Bool {
        a.almacen === b.almacen || a.almacen.bytes == b.almacen.bytes
    }
    var description: String { "Bufer(\(count) bytes)" }
}

Ese atajo de la igualdad es una cortesía habitual y una buena señal de que has entendido el patrón: si dos valores comparten almacenamiento, son iguales sin necesidad de mirar el contenido, y esa comparación de identidad es O(1) frente a la comparación estructural, que es O(n).