Reservar y liberar a mano: el ciclo completo sin ARC

En Swift de alto nivel, el nacimiento y la muerte de un valor son un solo acontecimiento indivisible: escribes una declaración y ahí hay un valor; el ámbito termina y ya no hay nada. Esa fusión es tan cómoda que resulta invisible, y por eso desconcierta descubrir que en realidad son dos acontecimientos independientes que ARC se limitaba a sincronizar. Reservar memoria es conseguir un trozo de dirección con el tamaño y la alineación adecuados; inicializarlo es depositar allí un valor válido. Nada obliga a que ocurran a la vez, y las APIs manuales de Swift toman esa separación en serio hasta un extremo que ningún otro lenguaje de uso masivo alcanza: cada una de las cuatro transiciones tiene su propio método, con su propio nombre, y equivocarse de método no da un error de compilación sino una fuga silenciosa o una liberación doble.

Cuatro estados y sus transiciones

La región de memoria que manipulas atraviesa una máquina de estados muy pequeña. No reservada. Reservada pero sin inicializar. Inicializada, es decir, conteniendo un valor válido del tipo. Y de vuelta a reservada sin inicializar, y finalmente devuelta al sistema. La ley que gobierna todo lo demás cabe en dos frases: leer memoria reservada pero no inicializada es comportamiento indefinido, y liberar memoria todavía inicializada fuga los recursos que ese valor poseía.

let p = UnsafeMutablePointer<String>.allocate(capacity: 3)  // reservada, sin inicializar
// print(p.pointee)          // indefinido: aqui no hay ningun String, hay basura

p.initialize(repeating: "vacio", count: 3)                  // inicializada
p[1] = "hola"                                               // ahora si, escritura normal

p.deinitialize(count: 3)                                    // libera los buffers de los String
p.deallocate()                                              // devuelve la memoria

allocate(capacity:) reserva stride multiplicado por la capacidad, con la alineación que exige el tipo, y devuelve un puntero ligado a ese tipo pero sin inicializar. La ligadura y la inicialización son cosas distintas: la primera dice de qué tipo serán los bytes cuando los haya; la segunda dice que ya los hay. Esa distinción, que suena escolástica, es justo la que hace que la primera línea comentada del ejemplo sea indefinida en vez de simplemente devolver un valor raro.

Inicializar no es asignar

Aquí está el error que más caro se paga, y es un error que el compilador no puede detectar porque ambas operaciones tienen tipos idénticos. initialize asume que la memoria destino no contiene un valor y deposita uno nuevo. update —llamada assign antes de que SE-0370 la renombrara en Swift 5.8— asume que la memoria destino sí contiene un valor válido, lo destruye correctamente y pone otro en su lugar.

let q = UnsafeMutablePointer<String>.allocate(capacity: 1)

q.initialize(to: "primero")   // correcto: la memoria estaba vacia
q.update(to: "segundo")       // correcto: libera "primero" y guarda "segundo"

// q.initialize(to: "tercero") // FUGA: no libera "segundo", lo pisa

Para tipos triviales —enteros, valores en coma flotante, estructuras compuestas solo de triviales— la diferencia no se nota, porque destruir un Int no hace nada. Para todo lo que gestione recursos —cadenas, arrays, instancias de clase, enumeraciones con carga— la diferencia es exactamente la fuga o la liberación doble. La regla de trabajo es mecánica: si no puedes afirmar con certeza en qué estado está la memoria, no has diseñado bien el tipo que la posee.

La familia se completa con las operaciones de movimiento, que existen porque copiar tiene un coste que a veces es innecesario. move extrae el valor y deja la memoria deinicializada; moveInitialize traslada un rango entero desde otro puntero, dejando el origen deinicializado y el destino inicializado, y es la operación que implementa un crecimiento de búfer sin retenciones ni liberaciones intermedias.

let viejo = UnsafeMutablePointer<String>.allocate(capacity: 2)
viejo.initialize(repeating: "x", count: 2)

let nuevo = UnsafeMutablePointer<String>.allocate(capacity: 4)
nuevo.moveInitialize(from: viejo, count: 2)   // traslada sin retener ni liberar
viejo.deallocate()                            // ya esta deinicializado: NO llamar deinitialize

nuevo.deinitialize(count: 2)
nuevo.deallocate()

stateDiagram-v2
[*] --> NoReservada
NoReservada --> SinInicializar: allocate capacity
SinInicializar --> Inicializada: initialize
Inicializada --> Inicializada: update
Inicializada --> SinInicializar: deinitialize o move
SinInicializar --> NoReservada: deallocate
Inicializada --> Fuga: deallocate directo
SinInicializar --> Indefinido: leer pointee

Un tipo propietario que no fugue

Las cuatro operaciones sueltas son un peligro; encapsuladas en un tipo con dueño único, son una herramienta. El patrón canónico es una clase que reserve en su inicializador y libere en su deinit, de modo que el ciclo manual quede confinado y el resto del programa vuelva a la seguridad de ARC.

final class Bufer<Elemento> {
    private let base: UnsafeMutablePointer<Elemento>
    private(set) var cuenta: Int
    let capacidad: Int

    init(capacidad: Int, valorInicial: Elemento) {
        self.capacidad = capacidad
        self.cuenta = capacidad
        self.base = .allocate(capacity: capacidad)
        base.initialize(repeating: valorInicial, count: capacidad)
    }

    subscript(i: Int) -> Elemento {
        get { precondition(i < cuenta); return base[i] }
        set { precondition(i < cuenta); base[i] = newValue }
    }

    var vista: UnsafeBufferPointer<Elemento> {
        UnsafeBufferPointer(start: base, count: cuenta)
    }

    deinit {
        base.deinitialize(count: cuenta)
        base.deallocate()
    }
}

Dos detalles de ese código merecen atención. El deinit deinicializa exactamente cuenta elementos, no capacidad: deinicializar posiciones que nunca se inicializaron es tan indefinido como leerlas. Y el subíndice recupera la comprobación de rango con precondition, que sobrevive a la optimización, porque el objetivo del tipo es precisamente devolver garantías al mundo exterior.

Cuando el tipo no se conoce de antemano o el formato lo dicta un protocolo externo, se reserva en crudo y se liga después. UnsafeMutableRawPointer.allocate(byteCount:alignment:) te obliga a decir la alineación a mano, y bindMemory(to:capacity:) establece la ligadura antes de inicializar.

let crudo = UnsafeMutableRawPointer.allocate(
    byteCount: MemoryLayout<Double>.stride * 8,
    alignment: MemoryLayout<Double>.alignment
)
let tipado = crudo.bindMemory(to: Double.self, capacity: 8)
tipado.initialize(repeating: 0, count: 8)

tipado.deinitialize(count: 8)
crudo.deallocate()   // se libera el puntero base, con la misma alineacion