Newtype & type-state, ou l'état illégal qui ne compile pas Newtype & type-state, or the illegal state that won't compile

Tes propres invariants, déplacés de ta tête vers le type.Your own invariants, moved from your head into the type.

Option a montré le mouvement : prendre une règle qui vivait dans ta tête — « ça peut être absent » — et la déplacer dans le type, où le compilateur la fait respecter. Ce numéro généralise le geste à tes propres règles. Deux outils : le newtype, qui donne un sens et une garantie à un type primitif ; et le type-state, qui encode l'état d'un objet dans son type, pour que les opérations invalides n'existent tout simplement pas. La fin du Vol 3 : rendre l'illégal non pas détectable, mais impossible à écrire — dans ton domaine, pas seulement dans la bibliothèque standard.Option showed the move: take a rule that lived in your head — 'this can be absent' — and move it into the type, where the compiler enforces it. This issue generalizes the gesture to your own rules. Two tools: the newtype, which gives meaning and a guarantee to a primitive type; and type-state, which encodes an object's state into its type, so invalid operations simply don't exist. The close of Vol 3: making the illegal not detectable but impossible to write — in your domain, not just the standard library.

struct Email(String);          // un newtype : un String, mais PAS un String

impl Email {
    // le SEUL chemin de construction passe par la validation
    fn parse(s: String) -> Option<Email> {
        if s.contains('@') { Some(Email(s)) } else { None }
    }
}

// dès lors, un Email qui existe est un email validé — par construction.
// et on ne peut plus le confondre avec un mot de passe, lui aussi String.

Quand tout est String, le compilateur ne peut plus rien distinguer.When everything is a String, the compiler can no longer tell things apart.

L'« obsession du primitif » est un réflexe transparent : un email est du texte, donc String ; un âge est un nombre, donc u32 ; un identifiant aussi, donc u32. Le code compile, paraît simple — et le compilateur, qui ne voit que des String et des u32 interchangeables, ne peut plus t'empêcher d'inverser deux arguments, de passer une donnée non validée, de confondre un identifiant client et un identifiant produit. Toute la sécurité retombe sur la vigilance humaine.'Primitive obsession' is a transparent reflex: an email is text, so String; an age is a number, so u32; an id too, so u32. The code compiles, looks simple — and the compiler, seeing only interchangeable Strings and u32s, can no longer stop you swapping two arguments, passing unvalidated data, confusing a customer id with a product id. All the safety falls back on human vigilance.

// Tout est String / u32 : le compilateur ne voit que des primitifs
fn creer_compte(email: String, mdp: String, age: u32) { /* ... */ }

creer_compte(mdp, email, age);     // ✓ COMPILE — arguments inversés !
creer_compte("pasunemail".into(), "x".into(), 200);  // ✓ COMPILE — invalide

// rien ne distingue un email d'un mot de passe, un âge d'un identifiant.
// le type String dit « du texte », jamais « un email validé ».

Le compilateur ne refuse rien, parce qu'il n'a aucun moyen de savoir qu'email et mdp jouent des rôles différents : ce sont le même type. Inverser deux arguments du même type est l'un des bugs les plus pernicieux qui soient — il passe la compilation, les tests heureux, et se révèle sur des données réelles. Le type String ne porte qu'une information : « c'est du texte ». Tout le sens métier est resté dans ta tête.The compiler refuses nothing, because it has no way to know email and mdp play different roles: they're the same type. Swapping two arguments of the same type is among the most insidious bugs there is — it passes compilation, the happy tests, and surfaces on real data. The String type carries one piece of information: 'this is text'. All the domain meaning stayed in your head.

Le type-state : l'opération interdite qui n'existe tout simplement pas.Type-state: the forbidden operation that simply doesn't exist.

Le newtype encode un invariant sur une valeur. Le type-state va plus loin : il encode l'état d'un objet dans son type, et attache chaque opération à l'état où elle est légale. Une connexion fermée et une connexion ouverte ne sont pas le même type — et send() n'est défini que sur la seconde. Appeler send() sur une connexion fermée n'est pas une erreur qu'on attrape : c'est un appel à une méthode qui n'existe pas. L'erreur est éliminée à la racine, par la disponibilité même des opérations.The newtype encodes an invariant about a value. Type-state goes further: it encodes an object's state into its type, and attaches each operation to the state where it's legal. A closed connection and an open one aren't the same type — and send() is defined only on the latter. Calling send() on a closed connection isn't an error you catch: it's a call to a method that doesn't exist. The error is eliminated at the root, by the very availability of operations.

struct Connexion<E> { socket: Socket, _etat: PhantomData<E> }
struct Ouverte;          // marqueurs d'état — zéro octet à l'exécution
struct Fermee;

impl Connexion<Fermee> {
    fn new() -> Self { /* ... */ }                         // on naît Fermée
    fn ouvrir(self) -> Connexion<Ouverte> { /* ... */ }   // Fermée → Ouverte
}
impl Connexion<Ouverte> {
    fn envoyer(&self, msg: &str) { /* ... */ }            // n'existe QUE sur Ouverte
    fn fermer(self) -> Connexion<Fermee> { /* ... */ }    // Ouverte → Fermée
}

let c = Connexion::<Fermee>::new();
c.envoyer("salut");      // ✕ ne compile pas : envoyer() n'existe pas sur Fermee
let c = c.ouvrir();      // c est maintenant Connexion<Ouverte>
c.envoyer("salut");      // ✓ envoyer() existe sur Ouverte

La cérémonie de types qui coûte plus cher que le bug qu'elle prévient.The type ceremony that costs more than the bug it prevents.

Une fois qu'on a vu la puissance du newtype et du type-state, la tentation est de tout encoder. Chaque champ devient un type, chaque état un paramètre générique, chaque transition une méthode qui consomme self. Mais l'encodage a un coût : du boilerplate, des conversions, une signature plus lourde, une courbe de lecture plus raide. Quand ce coût dépasse le risque du bug évité, on a sur-conçu. Le bon design n'est pas « tout typer » — c'est typer ce qui porte un vrai danger.Once you've seen the power of newtype and type-state, the temptation is to encode everything. Every field becomes a type, every state a generic parameter, every transition a self-consuming method. But encoding has a cost: boilerplate, conversions, heavier signatures, a steeper reading curve. When that cost exceeds the risk of the bug avoided, you've over-engineered. Good design isn't 'type everything' — it's typing what carries real danger.

// Newtype sur TOUT, même ce qui n'a aucun invariant
struct Prenom(String);
struct Nom(String);
struct Rue(String);
struct Ville(String);
struct CodePostal(String);   // … et 20 autres

impl Prenom {
    fn new(s: String) -> Prenom { Prenom(s) }   // aucune validation : pure cérémonie
    fn as_str(&self) -> &str { &self.0 }
}
// 200 lignes de boilerplate pour des champs qu'aucune règle ne contraint.
// Chaque accès devient .0 ou .as_str() ; chaque appel, un emballage.

Prenom(String) sans validation ne garantit rien que String ne garantissait déjà — il ajoute juste de l'emballage. Le vrai danger qu'un newtype prévient, c'est la confusion ou la donnée invalide. Là où ces dangers n'existent pas (qui inverse un prénom et un nom de rue par accident, et quelle catastrophe si oui ?), le type ne fait que rançonner chaque ligne en .0 et conversions. Le lecteur paie une dette de cérémonie sans recevoir de garantie en échange.Prenom(String) with no validation guarantees nothing String didn't already — it just adds wrapping. The real danger a newtype prevents is confusion or invalid data. Where those dangers don't exist (who swaps a first name and a street name by accident, and what disaster if they do?), the type merely taxes every line with .0 and conversions. The reader pays a ceremony debt without getting a guarantee in return.

// On encode SEULEMENT les invariants qui portent un risque réel
struct Email(String);        // invariant fort : doit être validé
struct CodePostal(String);   // invariant : 5 chiffres — vaut un newtype

struct Adresse {             // le reste : de simples champs String
    rue: String,
    ville: String,
    code_postal: CodePostal, // seul le champ à risque est typé
}
// La cérémonie est réservée aux endroits où elle prévient un vrai bug.

On garde le newtype là où il travaille : un invariant réel (un email validé, un code postal à 5 chiffres), ou un risque de confusion coûteux (un IdClient qu'on ne veut jamais passer pour un IdProduit). Le reste reste primitif. La question n'est pas « puis-je typer ceci », mais « le bug que ce type prévient justifie-t-il son poids ». Le type-state, plus lourd encore, se réserve aux machines à états où une transition illégale serait vraiment dommageable — un protocole réseau, un cycle de vie de ressource.You keep the newtype where it works: a real invariant (a validated email, a 5-digit postcode), or a costly confusion risk (a ClientId you never want passed as a ProductId). The rest stays primitive. The question isn't 'can I type this', but 'does the bug this type prevents justify its weight'. Type-state, heavier still, is reserved for state machines where an illegal transition would be genuinely harmful — a network protocol, a resource lifecycle.