Optional / Nullable — concepts clés et travail avec les types nullables

Que sont Optional et Nullable ?

Optional en Swift et nullable en Kotlin sont des fonctionnalités linguistiques qui rendent null une partie explicite du système de types. En Swift, Optional est une enum : Optional.none (nil) et Optional.some(Wrapped). En Kotlin, nullable est indiqué par le suffixe ? dans le type : String? peut être une chaîne ou null.

Les deux approches résolvent le problème fondamental que Tony Hoare a appelé « l'erreur à un milliard de dollars » — null reference. Avant l'apparition des types optionnels, toute référence pouvait être null, et la vérification était laissée au développeur. Swift et Kotlin transfèrent cette vérification à l'étape de compilation : le code qui ignore null ne sera pas compilé.

Malgré l'objectif commun, Swift et Kotlin implémentent la null-safety différemment. Swift utilise le type algébrique Optional avec un pattern-matching complet. Kotlin intègre nullable dans le système de types au niveau du compilateur sans créer de type wrapper séparé.

Historiquement, null reference est apparu en 1965 dans le langage ALGOL W comme un moyen de représenter l'absence d'une valeur. Pendant six décennies, null est devenu la source d'innombrables défaillances — selon une étude de Tony Hoare, 30 à 50 pour cent des erreurs dans le code de production sont liées à NullPointerException. Swift avec Optional et Kotlin avec les types nullables sont devenus les premiers langages grand public à résoudre ce problème au niveau du système de types, faisant de null une partie explicite du contrat de fonction.

Optional en Swift : syntaxe et travail avec les types optionnels

En Swift, Optional est un type à part entière déclaré comme enum Optional<Wrapped>. Le sucre syntaxique ? remplace la notation complète : Int? est équivalent à Optional<Int>. Travailler avec Optional comprend plusieurs façons d'extraire la valeur.

Liaison if-let et guard-let

if let — extraction conditionnelle : si Optional contient une valeur, elle est liée à une constante dans le bloc. guard let — sortie anticipée de la fonction si Optional est nil. guard let rend le code plat, évitant les if-let imbriqués.

Optional chaining

Optional chaining (accès sécurisé séquentiel) via ? permet d'appeler une méthode ou une propriété sur un Optional sans déballage explicite. Si un maillon de la chaîne est nil, la chaîne entière retourne nil. Cela réduit le code lors du travail avec des données hiérarchiques.

Opérateur nil-coalescing

?? (nil-coalescing) — un opérateur qui retourne la valeur Optional si elle n'est pas nil, sinon une valeur par défaut. C'est une alternative concise à if-let pour fournir une valeur de repli.

var name: String? = "Alice"

// Liaison if-let
if let unwrapped = name {
    print("Bonjour, \(unwrapped)")
}

// Optional chaining
let count = name?.count

// Nil-coalescing
let display = name ?? "Invité"

// Map sur Optional
let greeting = name.map { "Hello, \($0)" }

Nullable en Kotlin : appels sécurisés et opérateur Elvis

En Kotlin, nullable fait partie du système de types, pas un type wrapper séparé. Le type String? peut contenir null, tandis que String (sans point d'interrogation) ne le peut jamais. Le compilateur suit nullable via smart cast et des annotations.

Appel sécurisé ?.

?. — l'opérateur d'appel sécurisé. Si l'objet n'est pas null, la méthode ou la propriété est appelée ; si null — null est retourné sans appel. C'est analogue à l'optional chaining en Swift, mais syntaxiquement plus court.

Opérateur Elvis ?:

?: — l'analogue Kotlin de nil-coalescing. Si l'expression de gauche n'est pas null, elle est retournée ; sinon — la valeur de droite. L'opérateur Elvis est souvent combiné avec un retour anticipé via return ou throw.

Smart cast et opérateur !!

Smart cast — le compilateur Kotlin convertit automatiquement nullable en non-null après une vérification de null dans if ou when. !! — déballage forcé (force unwrap) qui lance NullPointerException si null. Utilisez !! seulement quand null est un bogue.

val name: String? = "Alice"

// Appel sécurisé
val length = name?.length

// Opérateur Elvis
val display = name ?: "Invité"

// Smart cast après vérification
if (name != null) {
    println("Longueur : ${name.length}")
}

// Let avec lambda
name?.let { println("Bonjour, $it") }

// Force unwrap — seulement quand vous êtes sûr
val forced = name!!

Optional vs Nullable : différences clés des approches

Bien que Swift et Kotlin résolvent la même tâche, leurs approches de la null-safety sont fondamentalement différentes. Comprendre ces différences est important pour les développeurs travaillant avec les deux plates-formes.

Représentation dans le système de types

Swift utilise enum Optional — un type algébrique standard. Kotlin intègre nullable au niveau du système de types du compilateur sans créer d'objet wrapper. Cela affecte les performances : Optional en Swift est un objet sur le tas, tandis que nullable en Kotlin est une vérification de null sans allocation.

Syntaxe et expressivité

La syntaxe de Kotlin est plus courte grâce aux opérateurs intégrés ?., ?:, !!. Swift nécessite une syntaxe plus explicite : if let, guard let, map sur Optional. Cependant, Swift fournit le pattern-matching via switch, que Kotlin ne supporte pas directement pour nullable.

Modèles de null-safety dans le développement mobile

Dans le développement mobile, des modèles standard pour travailler avec les types optionnels ont émergé, réduisant le code boilerplate et augmentant la sécurité.

Map et flatMap sur Optional

Swift et Kotlin supportent map et flatMap pour Optional et nullable. Si une valeur existe, une transformation est appliquée ; si null — null est retourné. Cela élimine les vérifications if-let imbriquées.

Valeurs par défaut via Elvis

Au lieu de if-let + else, utilisez ?: ou ?? avec une valeur par défaut. Cela rend le code déclaratif : « utilisez X si disponible, sinon Y » au lieu d'une vérification procédurale.

Nullable dans Compose et SwiftUI

Dans Jetpack Compose et SwiftUI, les types optionnels contrôlent le rendu : si l'état est null — masquez le composant, sinon affichez-le. Cela suit le principe de source unique de vérité.

data class UserState(
    val name: String?,
    val email: String?
)

// Smart cast dans when avec différentes variantes
fun greeting(state: UserState): String = when {
    state.name != null && state.email != null ->
        "${state.name} (${state.email})"
    state.name != null -> state.name
    else -> "Invité"
}

// Compose : affichage selon présence
@Composable
fun UserProfile(name: String?) {
    name?.let {
        Text(text = it)
    } ?: Text(text = "Aucune donnée")
}

Pour migrer du code Java existant vers Kotlin, il est recommandé d'utiliser les annotations @Nullable et @NonNull du package androidx.annotation. Le compilateur Kotlin respecte ces annotations lors de l'interop avec Java, rendant automatiquement les types correspondants nullables ou non-null. Une migration progressive avec des annotations explicites est plus sûre que l'activation globale de la null-safety dans le projet.

Erreurs courantes lors du travail avec Optional et Nullable

La null-safety réduit le nombre d'erreurs, mais ne les élimine pas complètement. Les développeurs commettent souvent des erreurs caractéristiques lorsqu'ils travaillent avec des types optionnels.

• Force unwrap sans garantie — name! ou name!! sans certitude que la valeur n'est pas nil provoque un crash en production. Vérifiez null avant le force unwrap.
• If-let excessif — des if-let imbriqués pour trois Optional ou plus créent une pyramide de l'enfer. Utilisez guard let ou flatMap.
• Ignorer nil-coalescing — la vérification explicite via if-let avec un bloc else peut être remplacée par ?? ou ?:, ce qui réduit le code et améliore la lisibilité.
• Nullable dans les API publiques — si une fonction accepte nullable, chaque appel nécessite une vérification. Préférez non-null avec une valeur par défaut ou une surcharge.