La nulabilidad vive en el tipo

Tony Hoare llamó a la referencia nula que introdujo en ALGOL W en 1965 su error de mil millones de dólares. Sesenta años después seguimos pagándolo, y la lección que el ecosistema tardó en aprender es que no se corrige comprobando más, porque comprobar más es disciplina y la disciplina no escala. Se corrige haciendo que el compilador sepa distinguir una referencia que puede faltar de una que no. Kotlin no envuelve nada, no añade defensas alrededor del NullPointerException ni introduce un contenedor: reorganiza su sistema de tipos para que la posibilidad de ausencia sea una propiedad estática del tipo. Todo el nivel se apoya en esa idea; esta lección la construye desde los cimientos.

Dos tipos donde antes había uno

La declaración más importante del nivel cabe en dos líneas, y lo que separa a quien las entiende de quien las memoriza es saber que la segunda no es una variante de la primera.

val nombre: String = "Ada"
val quiza: String? = null

nombre.length      // compila siempre
quiza.length       // error: length solo existe sobre String, no sobre String?

String? no es String con un aviso pegado. Es un tipo diferente cuyo conjunto de valores es el de String más un habitante extra, y cuyo conjunto de operaciones disponibles es, en consecuencia, mucho más pequeño: sobre él solo puedes invocar lo que esté definido para Any? y las extensiones declaradas explícitamente sobre un receptor nulable. Por eso quiza.toString() sí compila —la biblioteca estándar declara fun Any?.toString(): String, que devuelve la cadena null cuando el receptor lo es— mientras que quiza.length no.

La relación entre ambos es de subtipo, y la dirección importa. String es subtipo estricto de String?, así que la conversión es libre hacia arriba y prohibida hacia abajo sin una prueba:

val abierto: String? = nombre   // ensanchar: siempre legal, sin coste
val cerrado: String = quiza     // estrechar: error de compilacion

Esto es exactamente lo que hace que la nulabilidad sea contagiosa en el sentido correcto: puedes pasar un valor seguro a un hueco que admite ausencia, nunca al revés. Cada vez que quieres cruzar la frontera en el sentido peligroso, el compilador te obliga a producir una justificación —una comprobación, un valor por defecto, una aserción— y esa obligación es todo el mecanismo.

La jerarquía completa

Duplicar cada tipo genera una jerarquía con dos mitades unidas por arriba y por abajo, y conocer sus extremos explica muchos mensajes de error que de otro modo parecen arbitrarios.

flowchart BT
N[Nothing] --> S[String]
N --> I[Int]
S --> A[Any]
I --> A
N --> NN[Nothing nullable]
NN --> SN[String nullable]
NN --> IN[Int nullable]
S --> SN
I --> IN
SN --> AN[Any nullable]
IN --> AN
A --> AN
style N fill:#f38ba8,color:#11111b
style NN fill:#f9e2af,color:#11111b
style AN fill:#a6e3a1,color:#11111b

Los cuatro vértices de esa figura merecen nombre propio, porque casi todos los mensajes de error sobre nulabilidad que verás en tu vida los mencionan.

Que Nothing sea subtipo de todo es la pieza que hace funcionar el elvis con return y throw a su derecha, y ese será el primer truco de la próxima lección.

De ahí salen varios comportamientos que conviene poder predecir:

val x = null                  // inferido: Nothing?
val lista = listOf(null)      // inferido: List<Nothing?>
val y = if (hoy) "texto" else null   // inferido: String?, el supremo de String y Nothing?

La inferencia calcula el supremo de las ramas, y como Nothing? es subtipo de todo tipo nulable, ese supremo es siempre la versión nulable del otro operando. No hay magia: es aritmética de la jerarquía.

En genéricos aparece la consecuencia menos intuitiva. Un parámetro de tipo sin cota explícita tiene como cota superior implícita Any?, no Any, de modo que puede sustituirse por un tipo nulable:

fun <T> identidad(v: T): T = v
identidad<String?>(null)      // legal: T se instancia a String?

fun <T : Any> exigente(v: T): T = v
exigente<String?>(null)       // error: String? no cumple la cota Any

Dentro de identidad, el parámetro v no admite v.length ni siquiera si el llamante usó String, porque el cuerpo se compila una sola vez para toda instanciación posible. Cuando necesitas dentro del cuerpo la garantía de no nulidad sin cerrar la firma, existe el tipo intersección T & Any, el llamado definitely non-nullable estable desde Kotlin 1.7: es lo que devuelve v!! sobre un genérico y lo que puedes escribir explícitamente en una firma para expresar la idea sin prohibir que T sea nulable en otros usos.

Nada de esto existe al ejecutar

Aquí está la clave que separa el modelo mental correcto del aproximado. En la JVM no hay ninguna clase String?. Tanto String como String? se compilan al mismo java.lang.String, y toda la información de nulabilidad viaja como metadatos: las anotaciones que el compilador emite en la firma y el bloque de metadatos de Kotlin que otro módulo lee al compilar contra el tuyo. La nulabilidad es una disciplina del comprobador de tipos, no una estructura del programa ejecutable.

Eso tiene tres consecuencias directas. La primera es que la seguridad es gratis: no hay asignación, no hay indirección, no hay envoltorio que abrir. Convertir un String? demostrado no nulo en un String no genera ni una instrucción, porque no hay nada que desenvolver.

La segunda es la excepción que confirma el modelo: los tipos primitivos. Int se representa como el primitivo int, que no tiene manera de codificar la ausencia, así que Int? se representa como java.lang.Integer y paga una asignación —o un acierto en la caché de enteros pequeños—.

val a: Int = 1_000        // primitivo int, sin objeto
val b: Int? = 1_000       // objeto Integer, con boxing
val c: Int? = 1_000

println(b == c)           // true: compara por equals
println(b === c)          // false fuera del rango cacheado: identidades distintas

Un Array<Int?> o una List<Int?> en un bucle caliente cuestan un objeto por elemento. Cuando esa diferencia importa, la solución no es abandonar la nulabilidad sino rediseñar el dato para que la ausencia no sea representable —el tema de la última lección del nivel—.

La tercera es que la garantía solo vale dentro de Kotlin. Java, la reflexión y las bibliotecas de deserialización pueden inyectar null en un hueco declarado no nulo sin que ningún tipo se lo impida. Por eso el compilador siembra comprobaciones intrínsecas en las fronteras públicas, un mecanismo que estudiaremos a fondo en la cuarta lección.