Escribir el tuyo: validar, persistir, registrar

Entender la transformación del compilador es una cosa; decidir qué merece envolverse es otra bastante más difícil. Un property wrapper es un lugar privilegiado: se ejecuta en cada lectura y en cada escritura de una propiedad, invisible desde el código que la usa. Esa invisibilidad es su virtud cuando el comportamiento es una invariante del valor, y su peor defecto cuando esconde trabajo caro o efectos que el lector no espera. En esta lección escribiremos tres wrappers completos —validación, persistencia y registro— y, en cada uno, la pregunta de fondo no será cómo se escribe, sino qué clase de comportamiento tiene derecho a volverse invisible.

Un wrapper que valida

El caso más sano es el que mantiene una invariante del propio valor: normalizar, acotar, recortar. Nada de estado externo, nada de efectos. Generalizando el ejemplo del nivel anterior con Comparable, el wrapper sirve para cualquier tipo ordenable:

@propertyWrapper
struct Acotado<Valor: Comparable> {
    private var valor: Valor
    private let rango: ClosedRange<Valor>

    init(wrappedValue: Valor, _ rango: ClosedRange<Valor>) {
        self.rango = rango
        self.valor = min(max(wrappedValue, rango.lowerBound), rango.upperBound)
    }

    var wrappedValue: Valor {
        get { valor }
        set { valor = min(max(newValue, rango.lowerBound), rango.upperBound) }
    }
}

La variante de saneado de texto es igual de barata y bastante más frecuente en la práctica, porque elimina de golpe una familia entera de bugs de espacios en blanco:

@propertyWrapper
struct Recortado {
    private var valor: String = ""

    init(wrappedValue: String) { self.wrappedValue = wrappedValue }

    var wrappedValue: String {
        get { valor }
        set { valor = newValue.trimmingCharacters(in: .whitespacesAndNewlines) }
    }
}

struct Formulario {
    @Recortado var nombre = ""
    @Acotado(1...120) var edad = 18
}

La propiedad de estos dos wrappers que los hace defendibles es que son puros y locales: el resultado depende solo del valor entrante, no tocan nada fuera y el coste de leerlos es el de leer un campo. Quien escriba formulario.nombre no necesita saber que hay un intermediario, porque el intermediario no hace nada que pueda sorprenderle.

Un wrapper que persiste

El segundo caso es el que más se escribe en el mundo real y el que introduce la decisión de diseño interesante. Queremos que una propiedad viva en UserDefaults en lugar de en memoria:

@propertyWrapper
struct Preferencia<Valor> {
    let clave: String
    let porDefecto: Valor
    let almacen: UserDefaults

    init(wrappedValue: Valor, _ clave: String, almacen: UserDefaults = .standard) {
        self.porDefecto = wrappedValue
        self.clave = clave
        self.almacen = almacen
    }

    var wrappedValue: Valor {
        get { almacen.object(forKey: clave) as? Valor ?? porDefecto }
        nonmutating set { almacen.set(newValue, forKey: clave) }
    }
}

struct Configuracion {
    @Preferencia("modoOscuro") var modoOscuro = false
    @Preferencia("nombreUsuario") var nombreUsuario = "invitado"
}

Observa que el wrapper no guarda el valor: guarda la clave, el valor por defecto y una referencia al almacén. El estado real está fuera del programa, en el disco. Y de ahí sale la pieza clave, nonmutating set. Escribir en la propiedad no modifica ni un byte del wrapper ni del struct que lo contiene, así que declarar el set como no mutante le dice la verdad al compilador y permite asignar a través de una constante:

let config = Configuracion()
config.modoOscuro = true      // legal: el set es nonmutating

Si omitieras nonmutating, Swift consideraría que asignar muta el struct contenedor, exigiría var y propagaría mutating por toda la cadena de llamadas. Es un ejemplo perfecto de cómo la anotación de mutación en Swift no describe la sintaxis sino la semántica: aquí no hay mutación real, y decirlo abre posibilidades.

Un wrapper que registra

El tercer caso vigila los cambios. Es el más instructivo porque es donde el mecanismo empieza a rozar su techo:

@propertyWrapper
struct Registrado<Valor> {
    private var valor: Valor
    private let etiqueta: String

    init(wrappedValue: Valor, _ etiqueta: String) {
        self.valor = wrappedValue
        self.etiqueta = etiqueta
    }

    var wrappedValue: Valor {
        get { valor }
        set {
            print("[\(etiqueta)] \(valor) pasa a \(newValue)")
            valor = newValue
        }
    }
}

struct Sesion {
    @Registrado("token") var token = ""
}

Funciona, y a la vez muestra la carencia estructural del mecanismo: Registrado sabe su etiqueta y su valor, pero no sabe en qué instancia vive. No puede consultar otra propiedad del contenedor, no puede llamar a un método suyo, no puede notificarle. Por eso todo wrapper que quiera avisar de un cambio necesita que se le inyecte a mano el destinatario del aviso, con una clausura o una referencia, y por eso el paso siguiente —que un cambio de propiedad despierte al objeto entero— no se resolvió con wrappers sino con macros. Existe un mecanismo no oficial y con nombre subrayado para acceder a la instancia contenedora desde el wrapper; que nunca se haya estabilizado es la señal más clara de que ese camino no era el bueno.

flowchart LR
esc[Escritura en la propiedad] --> set[Setter de wrappedValue]
set --> val[Validar o normalizar]
set --> per[Escribir en almacen externo]
set --> log[Registrar el cambio]
val --> mem[Estado dentro del wrapper]
per --> disco[Estado fuera del programa]
log --> consola[Efecto observable]
style esc fill:#cba6f7,color:#11111b
style set fill:#89b4fa,color:#11111b
style disco fill:#f9e2af,color:#11111b
style consola fill:#f38ba8,color:#11111b