Option, ou l'absence de null Option, or the absence of null

L'absence n'est plus un piège caché. C'est un cas dans le type.Absence is no longer a hidden trap. It's a case in the type.

Le numéro précédent s'est clos sur le « bug à un milliard de dollars » : le null, cette valeur qui prétend être de n'importe quel type sans en être aucun. Rust ne l'a jamais introduit. À la place, un simple enum à deux variantes — Some(T) ou None — qui transforme « cette donnée pourrait être absente » d'une note dans ta tête en une contrainte que le compilateur fait respecter. C'est l'enum du numéro précédent, appliqué au problème le plus universel de la programmation.The previous issue closed on the 'billion-dollar mistake': null, that value pretending to be of any type while being none. Rust never introduced it. In its place, a plain two-variant enum — Some(T) or None — turning 'this data might be absent' from a note in your head into a constraint the compiler enforces. It's the previous issue's enum, applied to the most universal problem in programming.

enum Option<T> {     // dans la bibliothèque standard, rien de magique :
    Some(T),         // il y a une valeur, la voici
    None,            // il n'y en a pas
}

// un type qui PEUT être absent le dit dans sa signature :
fn trouver(id: u32) -> Option<Utilisateur> { /* ... */ }
//                     ^^^^^^^^^^^^^^^^^^^^ « peut-être un User, peut-être rien »

Le crash qui guettait à l'exécution devient une erreur de compilation.The crash that lurked at runtime becomes a compile error.

Dans un langage à null, accéder à une valeur absente ne se voit jamais à l'écriture : le code compile, paraît correct, et explose en production sur la première donnée manquante. La NullPointerException est l'archétype du bug qui passe tous les tests et tombe chez l'utilisateur. Avec Option, ce même accès ne compile pas — l'erreur a remonté du runtime jusqu'au clavier, là où elle coûte le moins cher à corriger.In a null language, accessing an absent value never shows at writing time: the code compiles, looks fine, and blows up in production on the first missing datum. The NullPointerException is the archetype of the bug that passes every test and lands on the user. With Option, that same access won't compile — the error has moved up from runtime to keyboard, where it's cheapest to fix.

// Java / TypeScript : le type ne dit rien, le crash attend
Utilisateur u = trouver(id);     // peut être null — rien ne le signale
System.out.println(u.nom);       // 💥 NullPointerException à l'exécution

// la seule défense est la discipline : se SOUVENIR de tester
if (u != null) { ... }           // si on oublie, le compilateur se tait

Le type Utilisateur ne fait aucune différence entre « toujours là » et « peut-être null ». La seule barrière est ta mémoire : penser à tester avant d'accéder. Le compilateur, lui, ne dit rien — il laisse passer l'accès direct comme le test prudent. Des décennies de NPE viennent exactement de là : un type qui ment sur ce qu'il peut contenir, et une vérification qui dépend de la vigilance humaine.The type Utilisateur makes no difference between 'always there' and 'maybe null'. The only barrier is your memory: remembering to test before access. The compiler says nothing — it lets the direct access through just like the careful test. Decades of NPEs come exactly from this: a type lying about what it can hold, and a check that depends on human vigilance.

Ouvrir un Option sans noyer le code sous les match.Opening an Option without drowning the code in match.

Si chaque valeur facultative imposait un match complet, le code deviendrait vite illisible. Heureusement, Option vient avec une boîte à outils d'extraction : if let pour le cas unique, une famille de combinateurs pour transformer sans déballer, et l'opérateur ? pour propager l'absence en une touche. On choisit selon ce qu'on veut faire de None — fournir un défaut, transformer, enchaîner, ou abandonner tôt.If every optional value demanded a full match, code would quickly turn unreadable. Happily, Option ships with an extraction toolbox: if let for the single case, a family of combinators to transform without unwrapping, and the ? operator to propagate absence in one keystroke. You pick based on what you want to do with None — supply a default, transform, chain, or bail early.

if let Some(u) = trouver(id) {
    println!("Trouvé : {}", u.nom);   // ne s'exécute que si Some
}                                     // le cas None est implicitement ignoré

Les combinateurs — transformer sans déballerCombinators — transform without unwrapping

L'opérateur ? — propager l'absence en une toucheThe ? operator — propagate absence in one keystroke

// Sans Option : une cascade de if/null imbriqués, fragile
// Avec : une chaîne plate, chaque maillon court-circuite sur None

fn ville_du_chef(equipe: &Equipe) -> Option<String> {
    let chef = equipe.chef.as_ref()?;         // None ? on sort, renvoie None
    let adresse = chef.adresse.as_ref()?;     // pareil
    Some(adresse.ville.clone())               // arrivé ici, tout était présent
}
// as_ref() : on n'a qu'un &Equipe — sans lui, le ? tenterait de DÉPLACER
// hors d'un emprunt partagé (error[E0507]). Il rend Option<&T> au lieu d'Option<T>.

// ou en style combinateurs :
equipe.chef.as_ref()
    .and_then(|c| c.adresse.as_ref())
    .map(|a| a.ville.clone())

Le ? dit : « si c'est Some, donne-moi la valeur et continue ; si c'est None, arrête la fonction et renvoie None ». Toute la cascade de vérifications imbriquées qu'on écrirait avec des if null devient une suite plate de maillons, où l'absence court-circuite proprement. Le type suit la présence à travers toute la chaîne — et on ne lit jamais une valeur qui n'a pas survécu à chaque étape.The ? says: 'if it's Some, hand me the value and continue; if it's None, stop the function and return None'. The whole cascade of nested checks you'd write with if null becomes a flat chain of links, where absence short-circuits cleanly. The type tracks presence through the entire chain — and you never read a value that didn't survive every step.

.unwrap() : rouvrir la porte que Option venait de fermer..unwrap(): reopening the door Option just closed.

Option force à traiter l'absence — alors le débutant pressé cherche le bouton qui fait taire cette obligation. Il le trouve : .unwrap() extrait la valeur du Some… et panique si c'est None. En une méthode, on a réintroduit exactement le crash à l'exécution que tout le type servait à éliminer. unwrap n'est pas interdit, mais il a un prix : il échange une garantie de compilation contre un pari sur l'exécution. Ce prix, il faut le nommer pour le payer en conscience.Option forces you to handle absence — so the hurried beginner looks for the button that silences the obligation. They find it: .unwrap() extracts the value from Some… and panics if it's None. In one method, you've reintroduced exactly the runtime crash the whole type existed to eliminate. unwrap isn't forbidden, but it has a price: it trades a compile-time guarantee for a runtime gamble. That price must be named to be paid knowingly.

let u = trouver(id).unwrap();    // « je SAIS qu'il existe »
println!("{}", u.nom);           // …jusqu'au jour où il n'existe pas :
// thread 'main' panicked at src/main.rs:1:23:
// called `Option::unwrap()` on a `None` value

// .unwrap() rouvre exactement la porte que Option avait fermée :
// le crash à l'exécution sur une valeur absente. Le null, déguisé.

« Je sais qu'il existe » est une affirmation sur l'exécution que le compilateur ne peut pas vérifier — exactement le genre de pari qui tient en développement et casse en production. Chaque .unwrap() est un endroit où tu as repris à ta charge la garantie que le type t'offrait. Parfois c'est justifié ; souvent c'est juste le réflexe de faire taire l'erreur. Un .unwrap() non réfléchi est un null deref qui attend sa date.'I know it exists' is a claim about runtime the compiler can't verify — exactly the kind of bet that holds in development and breaks in production. Each .unwrap() is a place where you took back the guarantee the type was giving you. Sometimes it's justified; often it's just the reflex of silencing the error. A thoughtless .unwrap() is a null deref waiting for its date.

// 1. Propager : « ce n'est pas à moi de décider quoi faire de l'absence »
let u = trouver(id)?;                       // renvoie None/Err à l'appelant

// 2. Fournir un défaut sensé
let nom = trouver(id).map(|u| u.nom).unwrap_or("anonyme".into());

// 3. Si l'absence est VRAIMENT impossible, le dire — et le prouver
let premier = nums.first()
    .expect("nums est non-vide : garanti par la validation en amont");
//   ^^^^^^ le message documente l'invariant qui rend None impossible

Trois sorties honnêtes, par ordre de préférence : propager avec ? quand la décision revient à l'appelant ; fournir un défaut quand l'absence a un sens métier ; et, seulement si None est réellement impossible, .expect() avec un message qui documente l'invariant. La différence entre .unwrap() et .expect("…") n'est pas cosmétique : le message force à écrire pourquoi ça ne peut pas arriver — et si tu n'arrives pas à l'écrire, c'est que tu n'en sais rien.Three honest exits, in order of preference: propagate with ? when the decision belongs to the caller; supply a default when absence has a domain meaning; and, only if None is genuinely impossible, .expect() with a message that documents the invariant. The difference between .unwrap() and .expect("…") isn't cosmetic: the message forces you to write why it can't happen — and if you can't write it, you don't actually know.