Opérateur Elvis en Kotlin : ?: ne fonctionne pas comme tu le pensais

Opérateur Elvis en Kotlin : pas seulement "si null, alors…"

Si vous avez déjà écrit en Kotlin et rencontré null, vous avez sûrement vu ce drôle de smiley avec une coiffure — l'opérateur ?:. On l'appelle Elvis Operator, et dans la communauté Kotlin, il est devenu un véritable mème. Mais derrière cette syntaxe simple se cache une mécanique étonnamment complexe et intéressante.

Aujourd'hui, nous allons décortiquer l'opérateur Elvis en Kotlin non pas comme un simple "sucre syntaxique", mais comme un outil puissant qui résout le problème de null-sécurité au niveau du bytecode. Vous découvrirez ce qui se passe lorsque le compilateur rencontre ?:, et pourquoi dans certains cas il est plus rapide que if-else.

Cet article est basé sur une question réelle de Stack Overflow avec des milliers de vues — nous l'avons adaptée pour un contenu éducatif approfondi. C'est parti !

Qu'est-ce que l'Elvis Operator et avec quoi le mange-t-on

Formellement, l'opérateur Elvis (Elvis Operator) est un opérateur binaire qui retourne l'opérande de gauche s'il n'est pas égal à null, et celui de droite dans le cas contraire. Syntaxe :

val result = nullableValue ?: defaultValue

Le nom vient de la ressemblance avec la coiffure d'Elvis Presley, si l'on tourne la tête de côté : ?: — ce sont les yeux et la mèche. Amusant, mais dans le monde de la programmation, ce nom a perduré.

En Kotlin, cet opérateur fait partie du système de null safety. Il permet d'écrire un code concis sans vérifications lourdes :

// Au lieu de cela :\nval length: Int\nif (str != null) {\n    length = str.length\n} else {\n    length = 0\n}\n\n// On écrit ceci :\nval length = str?.length ?: 0

Le piège dont on ne parle pas dans les tutoriels

Beaucoup pensent que ?: est simplement une écriture raccourcie de if-else. Mais ce n'est pas tout à fait vrai. Le compilateur Kotlin génère un bytecode différent pour ces deux constructions. Et cette différence peut affecter les performances et le comportement du programme.

Comment fonctionne ?: sous le capot : bytecode et JVM

Regardons sous le capot. Prenons un exemple simple et voyons en quoi le compilateur Kotlin le transforme pour la JVM.

Code source en Kotlin

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

Code Java décompilé (approximativement)

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

Vous voyez ? Le compilateur ne remplace pas simplement ?: par if-else. Il crée une variable temporaire de type Integer? (boxing !), puis applique un second ?:. C'est ce qu'on appelle une double vérification.

Pourquoi cela se produit-il ?

Parce que str?.length retourne un Int? (Int nullable). Et ?: s'attend à ce que l'opérande de gauche puisse être null. Le compilateur ne peut pas "fusionner" ces deux vérifications en une seule — il doit préserver la sémantique de l'appel sécurisé.

En conséquence, si str n'est pas null, deux vérifications de null sont effectuées au lieu d'une. Pour la plupart des applications, cela est imperceptible, mais dans des boucles à forte charge, cela peut devenir un goulot d'étranglement.

Optimisation : quand l'Elvis Operator est plus rapide que if-else

Mais il y a aussi une bonne nouvelle. Dans certains cas, l'Elvis Operator génère un bytecode plus efficace qu'une vérification manuelle.

Prenons un exemple avec un retour anticipé :

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