Las funciones withUnsafe: un préstamo con fecha de caducidad

La primera pregunta que hace todo el mundo al encontrarse con withUnsafeBufferPointer es por qué la biblioteca no ofrece simplemente una propiedad que devuelva el puntero. La respuesta obliga a desmontar una creencia heredada de C que en Swift es sencillamente falsa: la creencia de que todo valor tiene una dirección. En Swift no la tiene. Un Int puede vivir entero en un registro del procesador; un array puede compartir su almacenamiento con otros tres arrays y reubicarlo en cuanto alguien escriba en él; un valor pasado a una función puede ser un temporal que el optimizador decide no materializar nunca. La dirección no es una propiedad preexistente que se pueda consultar: es algo que el compilador fabrica cuando alguien la pide, y que solo se compromete a mantener durante un intervalo acotado. La forma de bloque no es una incomodidad de la API: es la única sintaxis capaz de nombrar ese intervalo.

La dirección como ficción acotada

Todas estas funciones comparten una misma forma: reciben el valor, fabrican una dirección válida, invocan tu bloque con ella y, al volver, dejan de garantizar nada. La firma es genérica en el resultado y propaga los errores, de modo que el bloque puede devolver lo que quiera y lanzar lo que quiera sin que la función intermedia estorbe.

var x = 42
let doble = withUnsafePointer(to: &x) { p -> Int in
    p.pointee * 2          // p vive exactamente hasta el cierre de esta llave
}
print(doble)               // 84

La firma completa merece leerse despacio, porque todo el diseño está condensado en ella:

func withUnsafePointer<T, Resultado>(
    to valor: inout T,
    _ cuerpo: (UnsafePointer<T>) throws -> Resultado
) rethrows -> Resultado

El resultado es un parámetro genérico independiente, de modo que el bloque puede devolver cualquier cosa; y rethrows hace que la función lance solo si el bloque lanza, con lo que un try dentro del cuerpo no obliga a envolver la llamada entera cuando no hace falta. La consecuencia incómoda de esa generosidad la veremos enseguida: si el resultado puede ser cualquier cosa, también puede ser el propio puntero.

Lo que el compilador hace por debajo se llama materialización: si x no tenía dirección, la crea copiándolo a una posición de pila; si la tenía, la usa. Y aquí aparece la primera consecuencia sorprendente. Para un valor sin dirección estable, escribir a través de withUnsafeMutablePointer opera sobre un temporal que se copia de vuelta al salir del bloque —el patrón que ya conoces de inout—, así que las escrituras se ven al final, no durante. Si dentro del bloque leyeras x por su nombre esperando ver el cambio, verías el valor antiguo. Por fortuna, esa lectura no está permitida, y por una razón independiente.

El catálogo de préstamos

Hay cuatro familias, y elegir mal no da un error sino una copia inesperada. Para un valor suelto están withUnsafePointer(to:) y su versión mutable, más withUnsafeBytes(of:) cuando lo que quieres son los bytes en crudo. Para colecciones contiguas están withUnsafeBufferPointer y compañía, que prestan el almacenamiento real y no una copia. Para cadenas, withCString entrega una representación terminada en cero apta para C, y withUTF8 presta directamente los bytes de la codificación interna sin conversión.

let nombres = ["ada", "grace"]

nombres.withUnsafeBufferPointer { b in
    print(b.count)                       // presta el almacenamiento real
}

var texto = "hola"
texto.withUTF8 { bytes in
    print(bytes.count)                   // 4, sin terminador
}
texto.withCString { c in
    print(strlen(c))                     // 4, con terminador cero anadido
}

La cuarta familia es la menos conocida y a menudo la más útil: withUnsafeTemporaryAllocation(of:capacity:), incorporada por SE-0322 en Swift 5.6, reserva un bloque temporal —en pila cuando el tamaño lo permite— y lo presta con la misma disciplina de ámbito. Es la respuesta correcta al espacio de trabajo efímero que antes obligaba a reservar en el montículo y liberar a mano.

let suma = withUnsafeTemporaryAllocation(of: Int.self, capacity: 64) { bufer -> Int in
    bufer.initialize(repeating: 1)
    defer { bufer.deinitialize() }
    return bufer.reduce(0, +)
}
print(suma)   // 64

sequenceDiagram
participant C as Tu codigo
participant R as Runtime de Swift
participant M as Memoria
C->>R: withUnsafeBufferPointer
R->>M: fija el almacenamiento y fabrica la direccion
R->>C: entrega el puntero al bloque
C->>M: lecturas y escrituras validas
C->>R: el bloque devuelve un resultado
R->>M: libera la fijacion
Note over C,M: a partir de aqui el puntero apunta a nada garantizado

Las tres formas de romper el contrato

La primera es escapar el puntero. Compila, no avisa y es indefinido. La variante más frecuente consiste en devolver el propio parámetro del bloque, porque el resultado del bloque es genérico y un puntero es un valor perfectamente válido para devolver.

// TODAS estas lineas compilan y TODAS son incorrectas
let fugado = nombres.withUnsafeBufferPointer { $0 }
let base   = nombres.withUnsafeBufferPointer { $0.baseAddress }
var guardado: UnsafePointer<Int>?
withUnsafePointer(to: &x) { guardado = $0 }

La segunda es mutar el origen mientras el préstamo está vivo. Un array con copia al escribir puede reubicar su almacenamiento en el instante en que alguien le añade un elemento, y el puntero prestado quedaría apuntando al búfer viejo, ya liberado. Que el bloque no sea async no te salva: basta con llamar a una función que capture el array y lo modifique.

var xs = [1, 2, 3]
xs.withUnsafeBufferPointer { b in
    xs.append(4)          // puede reubicar: b queda colgando
    print(b[0])           // indefinido
}

La tercera es la violación de acceso exclusivo. Desde Swift 5, la ley de exclusividad se comprueba también en compilaciones optimizadas para propiedades globales y de clase, y prestar una variable con el operador de dirección abre un acceso de escritura durante todo el bloque; tocar esa misma variable por su nombre dentro del bloque es un acceso solapado.

var contador = 0
withUnsafeMutablePointer(to: &contador) { p in
    p.pointee += 1
    // contador += 1     // acceso solapado: exclusividad violada
}

Hay un cuarto peligro que no rompe el contrato pero lo roza, y es la concurrencia. Los bloques de esta familia son síncronos, así que dentro de ellos no puedes suspender la ejecución: el lenguaje te impide llevar un puntero prestado a través de un punto de suspensión, y esa prohibición es una protección, no una molestia. Entre la suspensión y la reanudación puede pasar cualquier cosa con el almacenamiento de origen, incluida su reubicación por otra tarea. Cuando necesites trabajo asíncrono sobre memoria contigua, copia primero a una reserva que poseas y cuyo ciclo de vida controles.

El pariente cercano de estas funciones es withExtendedLifetime, que resuelve un problema distinto y complementario: no presta ninguna dirección, sino que impide que ARC libere un objeto antes de tiempo. Es la herramienta correcta cuando entregas a una API de C un puntero que pertenece a un objeto y necesitas garantizar que ese objeto sigue vivo mientras la API lo usa, un caso en el que el optimizador podría insertar la liberación antes de lo que la intuición sugiere.