Tipos híbridos: el struct que contiene una clase

Un struct que contiene una class sigue siendo un struct para el compilador: se copia al asignarlo, obliga a mutating para escribir en él y respeta let al pie de la letra. Y sin embargo ha dejado de comportarse como un valor. La copia duplica fielmente sus propiedades, pero una de ellas es un puntero, y duplicar un puntero no duplica lo apuntado. El tipo es de valor por fuera y de referencia por dentro, no hay ninguna palabra clave que lo anuncie, y el compilador no te va a avisar.

La copia se detiene en la referencia

El mecanismo ya lo conoces: asignar copia el valor de cada propiedad almacenada. Cuando la propiedad es una referencia, su valor es el puntero, y eso es lo que se duplica.

final class Buffer { var datos: [Int] = [] }

struct Documento {
    var titulo: String
    var buffer: Buffer          // una referencia dentro de un valor
}

var a = Documento(titulo: "Informe", buffer: Buffer())
var b = a
b.titulo = "Borrador"
b.buffer.datos.append(1)

print(a.titulo)                 // "Informe"  ← el String sí se copió
print(a.buffer.datos)           // [1]        ← el Buffer no

La mitad del tipo obedece la semántica de valor y la otra mitad no. Peor aún: el compilador considera que escribir a través del puntero no modifica la estructura, así que ni siquiera hace falta var.

let congelado = a
congelado.buffer.datos.append(2)   // COMPILA: no se muta el struct, se muta el objeto
print(a.buffer.datos)              // [1, 2]

Aquí se rompe la promesa central del lenguaje. let sigue significando exactamente lo que decía —el binding no cambia, las propiedades del agregado no cambian—, pero el estado observable del programa sí cambia, y cambia a través de una constante. La garantía de inmutabilidad era transitiva sobre valores; sobre referencias no lo es.

Híbridos accidentales

El caso anterior es visible: la palabra Buffer está ahí, y sabes que es una clase. Los peligrosos son aquellos en los que ninguna línea menciona una clase.

struct Formulario {
    var texto: String = ""
    var alCambiar: () -> Void = {}          // los closures son tipos de referencia
}

protocol Almacen { func guardar(_ s: String) }

struct Editor {
    var contenido: String
    var almacen: any Almacen                // ¿struct o class? el tipo no lo dice
}

Un closure es un objeto en el montículo que además captura por referencia las variables que usa: dos copias del Formulario comparten el mismo contexto capturado. Un existencial como any Almacen hereda la semántica del conformante concreto, que puede ser una clase decidida en otro módulo; el tipo del campo no revela nada. La lista de sospechosos habituales es corta y vale la pena memorizarla:

• Closures y funciones almacenadas como propiedades.
• Existenciales any P y AnyObject cuyo conformante real es una clase.
• Tipos de Objective-C y de Core Foundation: NSMutableArray, NSCache, UIImage, CGContext.
• Punteros no seguros y búferes: UnsafeMutablePointer, UnsafeMutableBufferPointer.
• Cualquier struct de terceros que a su vez contenga uno de los anteriores. El problema es transitivo.

flowchart TB
s[Se copia un struct] --> p1[Propiedad de valor: se duplica en profundidad]
s --> p2[Propiedad de referencia: se duplica solo el puntero]
p2 --> comp[Objeto compartido por las dos copias]
comp --> rot[Semantica de valor rota si el objeto es mutable]
comp --> ok[Semantica intacta si el objeto es inmutable]

Restaurar el valor: copy-on-write a mano

Si la referencia está ahí por rendimiento —un búfer grande que no quieres duplicar en cada asignación—, la solución no es eliminarla sino esconderla detrás de una comprobación de unicidad. Es exactamente lo que hacen Array, String y Data, y puedes reproducirlo en veinte líneas.

struct Lienzo {
    private final class Almacen {
        var pixeles: [UInt8]
        init(_ p: [UInt8]) { pixeles = p }
        func copia() -> Almacen { Almacen(pixeles) }
    }

    private var almacen: Almacen

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

    private mutating func asegurarUnico() {
        if !isKnownUniquelyReferenced(&almacen) {
            almacen = almacen.copia()          // alguien más lo comparte: duplicar
        }
    }

    mutating func pintar(_ i: Int, _ v: UInt8) {
        asegurarUnico()
        almacen.pixeles[i] = v
    }

    var muestra: [UInt8] { almacen.pixeles }   // lectura: nunca copia
}

Tres condiciones sostienen la corrección de este patrón, y las tres son fáciles de romper. La clase de almacenamiento debe ser private y no filtrarse jamás hacia fuera: si algún método devuelve el Almacen, la comprobación de unicidad seguirá diciendo la verdad sobre el número de referencias, pero esas referencias externas verán mutaciones que no deberían. El argumento de isKnownUniquelyReferenced tiene que ser una propiedad var pasada como inout —de ahí que asegurarUnico sea mutating—. Y la función devuelve siempre false para clases de Objective-C, así que el almacenamiento debe ser una clase Swift nativa.

Cuándo el híbrido es correcto

No todo struct con una clase dentro es un error. Hay dos casos en los que la semántica de valor sobrevive intacta y uno en el que compartir es justamente el objetivo.

El primero es el copy-on-write que acabas de escribir: la referencia existe, pero ninguna escritura la comparte. El segundo es la referencia inmutable: si la clase es final y todas sus propiedades son let, compartir la instancia es indistinguible de haberla copiado, porque nadie puede observar un cambio que no puede ocurrir. Un struct que contiene un objeto congelado sigue teniendo semántica de valor a todos los efectos observables.

final class Fuente {                    // inmutable: compartirla es inofensivo
    let nombre: String
    let tamano: Double
    init(nombre: String, tamano: Double) { self.nombre = nombre; self.tamano = tamano }
}

struct Estilo { var color: Int; var fuente: Fuente }   // sigue siendo un valor

El tercer caso es el envoltorio deliberado de un servicio: una estructura que guarda una URLSession, un registrador o un cliente de base de datos. Ahí lo compartido es una entidad con identidad genuina, y la estructura solo le da forma de valor a su fachada. Es correcto siempre que lo declares y que el objeto sea seguro frente a accesos concurrentes.