Operador Elvis en Kotlin: ?: no funciona como pensabas

Operador Elvis en Kotlin: no solo "si es null, entonces…"

Si alguna vez has escrito en Kotlin y te has encontrado con null, seguramente has visto este divertido emoticono con peinado: el operador ?:. Se llama Operador Elvis, y en la comunidad de Kotlin se ha convertido en un verdadero meme. Pero detrás de esta sintaxis simple se esconde una mecánica sorprendentemente compleja e interesante.

Hoy analizaremos el operador Elvis en Kotlin no como un simple "azúcar sintáctico", sino como una poderosa herramienta que, a nivel de bytecode, resuelve el problema de la seguridad contra null. Descubrirás qué sucede cuando el compilador encuentra ?: y por qué en algunos casos funciona más rápido que if-else.

El artículo se basa en una pregunta real de Stack Overflow con miles de visitas: la hemos adaptado para un contenido educativo profundo. ¡Allá vamos!

¿Qué es el Operador Elvis y con qué se come?

Formalmente, el Operador Elvis es un operador binario que devuelve el operando izquierdo si no es null, y el derecho en caso contrario. Sintaxis:

val result = nullableValue ?: defaultValue

El nombre proviene de su parecido con el peinado de Elvis Presley si giras la cabeza hacia un lado: ?: son los ojos y el flequillo. Divertido, pero en el mundo de la programación este nombre se ha consolidado.

En Kotlin, este operador es parte del sistema de null safety. Permite escribir código conciso sin comprobaciones voluminosas:

// En lugar de esto:\nval length: Int\nif (str != null) {\n    length = str.length\n} else {\n    length = 0\n}\n\n// Escribimos así:\nval length = str?.length ?: 0

El truco que no mencionan en los tutoriales

Muchos piensan que ?: es simplemente una forma abreviada de if-else. Pero no es exactamente así. El compilador de Kotlin genera bytecode diferente para estas dos construcciones. Y la diferencia puede afectar al rendimiento y al comportamiento del programa.

Cómo funciona ?: bajo el capó: bytecode y JVM

Echemos un vistazo bajo el capó. Tomemos un ejemplo simple y veamos en qué lo convierte el compilador de Kotlin para JVM.

Código fuente en Kotlin

fun getLength(str: String?): Int {\n    return str?.length ?: 0\n}

Código Java descompilado (aproximadamente)

public static final int getLength(@Nullable String str) {\n    Integer var10000 = str != null ? str.length() : null;\n    return var10000 != null ? var10000 : 0;\n}

¿Ves? El compilador no solo reemplaza ?: por if-else. Crea una variable temporal de tipo Integer? (¡boxing!), y luego aplica un segundo ?:. Esto se llama doble comprobación.

¿Por qué sucede esto?

Porque str?.length devuelve Int? (Int nullable). Y ?: espera que el operando izquierdo pueda ser null. El compilador no puede "fusionar" estas dos comprobaciones en una sola: debe preservar la semántica de la llamada segura.

Como resultado, si str no es null, se realizan dos comprobaciones de null en lugar de una. Para la mayoría de las aplicaciones esto es imperceptible, pero en bucles de alta carga puede convertirse en un cuello de botella.

Optimización: cuándo el Operador Elvis es más rápido que if-else

Pero también hay buenas noticias. En algunos casos, el Operador Elvis genera un bytecode más eficiente que la comprobación manual.

Consideremos un ejemplo con retorno temprano:

// Con if-else\nfun process(value: String?): String {\n    if (value == null) return "default"\n    return value.uppercase()\n}\n\n// Con Elvis\nfun process(value: String?): String {