Smart casts: cuando el compilador demuestra la no nulidad

Si cada acceso a un valor nulable exigiera un operador, Kotlin sería insoportable. Lo que lo hace habitable es que, tras comprobar algo, el compilador recuerda lo comprobado y estrecha el tipo por sí mismo: escribes la comprobación una vez y el resto del bloque trabaja con el tipo estrecho, sin aserciones ni variables auxiliares. Eso es un smart cast, y no es azúcar sintáctico sino un análisis de flujo de datos completo sobre el grafo de control de la función. Entender cuándo se concede y cuándo se deniega es lo que convierte los errores más frustrantes del lenguaje en consecuencias previsibles de una regla sencilla.

El análisis de flujo

Tras una comprobación que domina el uso, el tipo declarado se estrecha al tipo intersección entre el declarado y lo demostrado. Con nulabilidad, String? comprobado distinto de nulo pasa a comportarse como String.

fun saludar(nombre: String?) {
    if (nombre != null) {
        println(nombre.length)     // String: sin ?., sin !!
    }
}

El análisis no se limita al if positivo. Entiende la negación con salida temprana, los cortocircuitos de las conjunciones y disyunciones, las ramas de un when y los bloques else:

fun longitud(texto: String?): Int {
    if (texto == null) return 0
    return texto.length            // aqui ya es String: la rama nula no llega
}

fun util(texto: String?): Boolean =
    texto != null && texto.isNotBlank()   // el lado derecho ya lo ve como String

fun describir(v: Any?): String = when (v) {
    null -> "ausente"
    is Int -> "entero " + (v + 1)
    is String -> v.uppercase()
    else -> v.toString()
}

La reescritura del frontend con K2 amplió notablemente el alcance. Hoy el análisis propaga la información a través de una variable booleana que guarda el resultado de la comprobación, a través de la disyunción, dentro de las lambdas de funciones inline cuyo contrato garantiza que se invocan en el sitio, a través de bloques try/catch y sobre variables que se incrementan o decrementan. Muchos errores que la gente aprendió a esquivar en la era del frontend antiguo simplemente ya no se producen.

fun k2(v: Any?) {
    val esTexto = v is String      // se guarda la evidencia
    if (esTexto) println(v.length) // K2 la recupera aqui
}

Cuándo el compilador se niega

La regla que gobierna todas las denegaciones es una sola: un valor solo puede estrecharse si el compilador puede probar que no cambia entre la comprobación y el uso. A esa propiedad se la llama estabilidad, y no es una lista arbitraria de casos sino la consecuencia directa de esa exigencia.

flowchart TD
A[Comprobacion de no nulidad] --> B[El valor es estable]
B -->|val local| S[Smart cast concedido]
B -->|var local sin captura que lo modifique| S
B -->|val del mismo modulo sin getter propio| S
B -->|propiedad open o con getter personalizado| F[Denegado]
B -->|var de otro modulo| F
B -->|propiedad delegada| F
B -->|var miembro modificable por otro hilo| F
F --> C[Copia a un val local o usa let]
C --> S
style S fill:#a6e3a1,color:#11111b
style F fill:#f38ba8,color:#11111b

Los tres casos que más desconciertan tienen la misma raíz y merecen verse en código:

open class Base {
    open val nombre: String? = "fijo"
}

class Traviesa : Base() {
    private var n = 0
    override val nombre: String?
        get() = if (n++ % 2 == 0) "a" else null   // dos lecturas, dos resultados
}

fun usar(b: Base) {
    if (b.nombre != null) {
        // println(b.nombre.length)  // error: nombre es open y podria estar sobrescrita
    }
}

Una propiedad open puede sobrescribirse por un getter que devuelva algo distinto en cada lectura, así que la comprobación no dice nada sobre la lectura siguiente. Exactamente lo mismo ocurre con un val que declara getter propio: sintácticamente parece un campo, semánticamente es una llamada a función. Y un var declarado en otro módulo queda fuera del alcance del análisis porque el compilador no ve todas las escrituras posibles: la unidad de compilación es la frontera del razonamiento. Las propiedades delegadas caen por la misma razón, ya que cada acceso pasa por el operador de lectura del delegado.

El caso del var miembro añade el argumento de la concurrencia: entre la comprobación y el uso, otro hilo puede escribir. Aquí la negativa del compilador no es pedantería, es prevención de una condición de carrera clásica que en Java se resuelve exactamente con el mismo remedio, copiar a una variable local.

Cómo darle la prueba que le falta

Las tres soluciones son la misma idea con distinta ergonomía: fijar el valor en algo estable.

class Servicio(private val repo: Repo) {
    var sesion: Sesion? = null      // propiedad mutable: nunca hay smart cast

    fun refrescar() {
        val s = sesion ?: return    // 1. copia local con guarda
        repo.renovar(s.token)       // s es Sesion, estable por ser val local
    }

    fun notificar() {
        sesion?.let { s ->          // 2. el receptor pasa como argumento
            repo.avisar(s.id)       //    dentro del bloque ya no es nulable
        }
    }

    fun exigir() {
        val s = requireNotNull(sesion) { "no hay sesion activa" }  // 3. con causa
        repo.renovar(s.token)
    }
}

La primera forma es la preferida cuando hay más de un uso o cuando quieres salir. La segunda encaja para un bloque corto y con efecto. La tercera es para invariantes que, de romperse, indican un error de programación y no un caso de negocio.

Queda la pieza que permite extender el análisis a tus propias funciones: los contratos. La biblioteca estándar los usa para que comprobaciones envueltas sigan informando al compilador, y por eso isNullOrBlank funciona como si hubieras escrito la comparación a mano:

fun etiqueta(t: String?): String {
    if (t.isNullOrBlank()) return "vacio"
    return t.trim()                 // String: el contrato de la stdlib lo garantiza
}

Puedes declarar el tuyo. La sintaxis sigue marcada como experimental, así que exige activación explícita, y el compilador confía en lo que afirmas sin verificarlo: un contrato falso es tan peligroso como una aserción falsa.

import kotlin.contracts.ExperimentalContracts
import kotlin.contracts.contract

@OptIn(ExperimentalContracts::class)
fun Pedido?.esFacturable(): Boolean {
    contract { returns(true) implies (this@esFacturable != null) }
    return this != null && total > 0
}

fun facturar(p: Pedido?) {
    if (p.esFacturable()) emitir(p.total)   // p es Pedido dentro del if
}