El `!` no es el error: es el recibo de un modelo mal hecho

El consejo habitual sobre el force unwrap es a la vez cierto e inútil: «no lo uses». Cierto porque cada ! es un punto de terminación abrupta del proceso; inútil porque no dice qué poner en su lugar, y quien lo escribió normalmente no tenía alternativa dentro del código que estaba tocando. La observación productiva es otra: un ! casi nunca es un fallo de esa línea. Es la consecuencia visible de un tipo que permite representar situaciones que el dominio no permite. El programador sabe que el valor está ahí; el compilador no puede saberlo porque el modelo no se lo ha contado. Esta lección enseña a leer el ! como un recibo —alguien pagó por una decisión de diseño tomada tres archivos más arriba— y a rediseñar el tipo para que la duda no exista en lugar de suprimirla con un operador.

Anatomía de un opcional que sobra

Un opcional dice una cosa muy concreta: este valor puede estar ausente y el programa debe contemplarlo. Cuando el dominio no admite la ausencia, el opcional es una mentira que el compilador se cree, y a partir de ahí obliga a desmentirla en cada uso. El caso canónico es el modelo que se rellena por partes.

final class Pedido {
    var id: UUID?
    var cliente: Cliente?
    var lineas: [Linea] = []
    var total: Decimal?
    var confirmadoEn: Date?
}

func imprimir(_ p: Pedido) {
    print("Pedido \(p.id!) de \(p.cliente!.nombre): \(p.total!)")
}

Cuatro propiedades opcionales generan dieciséis combinaciones representables. El dominio real tiene dos o tres. Las trece restantes no son estados: son agujeros que el tipo abrió y que todo el código posterior tiene que tapar a mano, generalmente con ! cuando el autor recuerda que en ese punto ya están rellenas. Nadie escribió un bug; se escribió un tipo con más grados de libertad que el problema, y el ! es el peaje.

El diagnóstico se hace con una pregunta por propiedad: ¿existe algún instante observable, después de la construcción, en que este valor pueda faltar legítimamente? Si la respuesta es no, el opcional es un artefacto de construcción y se elimina moviendo el trabajo al inicializador. Si es sí pero solo durante una fase, el opcional está codificando un estado y debe convertirse en un estado explícito. Solo si la ausencia es una propiedad permanente y significativa del dominio —una segunda línea de dirección, una fecha de baja— el opcional es correcto.

El refactor: de banderas a estados

El pedido anterior no tiene cuatro opcionales independientes; tiene un ciclo de vida. Escribirlo como ciclo de vida elimina los ! sin trasladarlos a ningún sitio, porque el compilador pasa a saber lo mismo que sabía el programador.

struct PedidoConfirmado {
    let id: UUID
    let cliente: Cliente
    let lineas: [Linea]       // invariante: no vacio
    let total: Decimal
    let confirmadoEn: Date
}

enum Pedido {
    case borrador(lineas: [Linea])
    case listo(cliente: Cliente, lineas: [Linea])
    case confirmado(PedidoConfirmado)
}

func imprimir(_ p: Pedido) -> String {
    switch p {
    case .borrador(let lineas):        return "Borrador con \(lineas.count) lineas"
    case .listo(let cliente, _):       return "Pendiente de \(cliente.nombre)"
    case .confirmado(let c):           return "Pedido \(c.id) de \(c.cliente.nombre): \(c.total)"
    }
}

Han desaparecido los cuatro ! y ha aparecido algo más valioso: el switch es exhaustivo, así que añadir mañana un estado anulado provocará errores de compilación exactamente en los sitios que hay que revisar. El opcional no ofrecía esa garantía; ofrecía silencio y un fallo en tiempo de ejecución.

La misma técnica resuelve el segundo gran productor de !, la validación tardía. Si un String puede o no ser un correo válido, comprobarlo en cada uso es a la vez costoso y frágil. Un tipo que solo se construye si la validación pasa mueve la comprobación a la frontera y la convierte en una garantía permanente.

struct Correo {
    let valor: String
    init?(_ crudo: String) {
        let limpio = crudo.trimmingCharacters(in: .whitespaces).lowercased()
        guard limpio.contains("@"), !limpio.hasPrefix("@") else { return nil }
        self.valor = limpio
    }
}

flowchart TD
A[Dato crudo del exterior] --> B{Valida en la frontera}
B -- no --> C[Error explicito o valor nil]
B -- si --> D[Tipo con invariante garantizada]
D --> E[Nucleo sin opcionales ni signos de admiracion]
C --> F[Ruta de fallo tratada una sola vez]

El patrón general se llama empujar la incertidumbre a los bordes. El opcional vive donde el dato entra al sistema; el núcleo trabaja con tipos que ya no dudan. Un código con muchos ! en el centro suele ser un código sin frontera definida: el dato crudo viaja hasta el fondo y cada capa lo revalida o lo fuerza.

Los tres ! defendibles

Prohibir el operador por completo produce código peor, porque empuja a escribir rutas de recuperación falsas para situaciones que no admiten recuperación. Hay tres usos legítimos, y los tres comparten una característica: el ! documenta una invariante que el compilador no puede verificar pero el programador sí ha demostrado.

El primero es el recurso empaquetado con la aplicación. Si una imagen o un Bundle no está, el binario está corrupto y continuar no tiene sentido. El segundo es la expresión regular literal o cualquier constante que se valida en tiempo de compilación de facto: si falla, falla en el primer arranque, en la máquina del desarrollador, nunca en producción. El tercero es la referencia @IBOutlet gestionada por el sistema, donde el ciclo de vida garantiza el orden y el opcional implícitamente desenvuelto es la forma canónica.

// Aceptable: fallo aqui significa binario roto, no dato inesperado
let esquema = Bundle.module.url(forResource: "esquema", withExtension: "json")!

// Mejor todavia: convertir la aserción en un mensaje util
guard let esquema = Bundle.module.url(forResource: "esquema", withExtension: "json") else {
    preconditionFailure("Falta esquema.json en el bundle: build mal configurado")
}

Cómo hacer el refactor sin romper todo

El error táctico más común es empezar por los ! y trabajar hacia atrás. Eso produce una cascada de guard que devuelven nil y el problema se propaga hacia arriba hasta que alguien, en la capa de presentación, escribe un ! porque ya no puede propagarlo más. El orden correcto es el inverso: se empieza por el tipo, se corrige el modelo y los ! desaparecen solos porque dejan de tener razón de ser.

En la práctica el procedimiento es mecánico. Se listan las propiedades opcionales de un tipo y se anota, para cada una, el instante en que se rellena. Las que se rellenan siempre en el mismo momento pertenecen al mismo estado y se agrupan en un caso de enumeración o en un tipo aparte. Las que se rellenan en el inicializador pero se declararon opcionales por comodidad se vuelven constantes. Las que sobreviven al análisis son los opcionales de verdad, y suelen ser una o dos donde antes había seis.

El refactor se puede hacer sin parar el mundo. El truco es introducir el tipo nuevo al lado del viejo, escribir una función de conversión que falle ruidosamente si encuentra una combinación imposible, y migrar consumidores de uno en uno. Esa función de conversión es además un instrumento de medida: si en producción nunca dispara, el análisis de estados era correcto; si dispara, acabas de descubrir un estado real que tu modelo mental no contemplaba, y eso vale más que el refactor entero.

extension Pedido {
    init(legado p: PedidoLegado) {
        switch (p.cliente, p.total, p.confirmadoEn) {
        case (let c?, let t?, let fecha?) where p.id != nil:
            self = .confirmado(PedidoConfirmado(id: p.id!, cliente: c,
                                                lineas: p.lineas, total: t,
                                                confirmadoEn: fecha))
        case (let c?, _, nil):
            self = .listo(cliente: c, lineas: p.lineas)
        default:
            self = .borrador(lineas: p.lineas)
        }
    }
}

Sí, ese código contiene un !. Es el último, vive en la frontera con el modelo antiguo y desaparece el día en que el modelo antiguo se borra. Un ! con fecha de caducidad escrita es una deuda gestionada; un ! disperso por treinta archivos es una deuda ignorada.