Orphan rule & blanket impls Orphan rule & blanket impls

Une implémentation, et une seule, pour tout le programme. C'est la cohérence.One implementation, and only one, for the whole program. That's coherence.

Deux numéros durant, on a implémenté des traits comme si de rien n'était. Mais une contrainte rôdait, évoquée au n°1 : on ne peut pas implémenter n'importe quel trait pour n'importe quel type. La raison est une garantie que Rust tient à tout prix — la cohérence : pour un trait et un type donnés, il existe au plus une implémentation dans tout le programme. Sans elle, deux bibliothèques pourraient donner au même type deux comportements incompatibles pour le même trait, et le compilateur, face à un appel, ne saurait laquelle choisir. L'orphan rule est le gardien de cette unicité : tu ne peux implémenter un trait pour un type que si tu possèdes au moins l'un des deux — le trait, ou le type.For two issues, we implemented traits as if nothing could go wrong. But a constraint lurked, hinted at in n°1: you can't implement just any trait for just any type. The reason is a guarantee Rust upholds at all costs — coherence: for a given trait and type, there is at most one implementation in the whole program. Without it, two libraries could give the same type two incompatible behaviors for the same trait, and the compiler, facing a call, wouldn't know which to choose. The orphan rule is the guardian of that uniqueness: you may implement a trait for a type only if you own at least one of the two — the trait, or the type.

// La règle : pour impl Trait for Type, tu dois POSSÉDER l'un des deux.

impl Surface for Cercle { /* ... */ }   // ✓ Surface est à toi (ou Cercle l'est)
impl Display for Cercle  { /* ... */ }   // ✓ Cercle est à toi (Display est std)

impl Display for Vec<i32> { /* ... */ }  // ✕ NI Display NI Vec ne sont à toi
//   error[E0117]: only traits defined in the current crate can be
//   implemented for types defined outside of the crate (orphan rule)

// les deux « étrangers » à la fois = interdit. sinon deux crates pourraient
// donner à Vec deux impl Display différentes — et laquelle gagnerait ?

Le newtype du Vol 3 revient — cette fois pour débloquer une implémentation.Vol 3's newtype returns — this time to unlock an implementation.

Au Vol 3, le newtype servait à donner un sens et une garantie à un type primitif — Email(String). Le voici dans un rôle tout autre, et c'est la surprise du numéro : il est aussi la sortie standard de l'orphan rule. Si tu ne peux pas implémenter un trait étranger pour un type étranger, alors rends l'un des deux non étranger. Tu ne possèdes pas Vec, et tu ne possèdes pas Display ? Crée un type qui, lui, t'appartient — une simple enveloppe autour du Vec — et implémente le trait sur lui. La cohérence est respectée, parce que ce nouveau type est à toi seul : personne d'autre ne peut entrer en conflit. Le même outil, deux usages sans rapport apparent, unis par une idée : posséder le type, c'est avoir le droit de le doter de comportements.In Vol 3, the newtype gave meaning and a guarantee to a primitive type — Email(String). Here it plays an entirely different role, and that's the issue's surprise: it's also the standard exit from the orphan rule. If you can't implement a foreign trait for a foreign type, then make one of the two non-foreign. You don't own Vec, and you don't own Display? Create a type that you do own — a simple wrapper around the Vec — and implement the trait on it. Coherence is respected, because that new type is yours alone: no one else can conflict. The same tool, two seemingly unrelated uses, united by one idea: owning the type is having the right to endow it with behaviors.

// On veut afficher joliment un Vec<u8> comme du hexadécimal.
// Display et Vec sont tous deux dans std → on ne possède NI l'un NI l'autre.

impl std::fmt::Display for Vec<u8> {
    fn fmt(&self, f: &mut Formatter) -> fmt::Result {
        for b in self { write!(f, "{b:02x}")?; }
        Ok(())
    }
}
// error[E0117]: only traits defined in the current crate can be implemented
// for types defined outside of the crate. L'impl est orpheline : refusée. Impasse ? Non.

L'intention est légitime — afficher un Vec<u8> en hexadécimal — mais l'impl est orpheline : ni Display ni Vec ne t'appartiennent. Rust refuse, non parce que ce serait dangereux ici, mais parce qu'autoriser ce cas ouvrirait la porte aux conflits entre crates. La règle est volontairement large et syntaxique — « possèdes-tu l'un des deux ? » — pour rester décidable sans analyser tout le graphe de dépendances. Le refus n'est pas une impasse : c'est une invitation à passer par un type qui soit le tien.The intent is legitimate — display a Vec<u8> in hexadecimal — but the impl is orphan: neither Display nor Vec is yours. Rust refuses, not because it would be dangerous here, but because allowing this case would open the door to cross-crate conflicts. The rule is deliberately broad and syntactic — 'do you own one of the two?' — to stay decidable without analyzing the whole dependency graph. The refusal isn't a dead end: it's an invitation to go through a type that is yours.

Le blanket impl : doter d'un comportement tout un univers de types, d'un coup.The blanket impl: endow a whole universe of types with a behavior, at once.

L'orphan rule dit où l'on peut implémenter. Son pendant lumineux dit jusqu'où : le blanket impl, une implémentation non pour un type, mais pour tous les types qui satisfont une borne. impl<T: Display> MonTrait for T donne MonTrait, gratuitement, à chaque type qui sait déjà s'afficher — présents et futurs, y compris ceux que tu n'as jamais vus. C'est le mécanisme par lequel la bibliothèque standard distribue des comportements à grande échelle : tout Display devient ToString, tout type se convertit en lui-même via From. Le générique du n°1 abstraitait sur les valeurs ; le blanket impl abstrait sur les implémentations elles-mêmes.The orphan rule says where you may implement. Its bright counterpart says how far: the blanket impl, an implementation not for a type, but for all types satisfying a bound. impl<T: Display> MyTrait for T gives MyTrait, for free, to every type that already knows how to display itself — present and future, including those you've never seen. It's the mechanism by which the standard library distributes behaviors at scale: every Display becomes ToString, every type converts to itself via From. Issue n°1's generic abstracted over values; the blanket impl abstracts over implementations themselves.

// Un blanket impl : implémenter un trait pour TOUS les types qui en respectent un autre
trait Resume {
    fn resume(&self) -> String;
}

impl<T: std::fmt::Display> Resume for T {     // « pour tout T qui est Display… »
    fn resume(&self) -> String {
        format!("valeur = {self}")            // …voici une impl de Resume, gratuite
    }
}

42.resume();        // ✓ i32 est Display → il a Resume sans une ligne de plus
"salut".resume();   // ✓ &str aussi. tout l'univers des Display gagne Resume d'un coup.

// La bibliothèque standard en regorge :
impl<T: Display> ToString for T { /* ... */ }   // tout Display sait .to_string()
impl<T> From<T> for T { /* ... */ }              // tout type se convertit en lui-même
impl<T, U: From<T>> Into<U> for T { /* ... */ }  // Into est dérivé de From, partout

Le newtype qui, via Deref, rouvre tout ce qu'il devait fermer.The newtype that, via Deref, reopens everything it was meant to close.

Le newtype a un revers connu : il perd les méthodes du type qu'il emballe. Un Hex(Vec<u8>) n'a plus .len() ni .iter() — il faut les ré-exposer une à une. Devant cette corvée, la tentation est d'implémenter Deref vers le type interne : d'un coup, toutes les méthodes du Vec reviennent, comme par magie. C'est presque toujours une erreur. Deref sur un newtype défait précisément ce que le newtype apportait : la barrière. Toutes les méthodes du type emballé refont surface, y compris celles qui peuvent violer l'invariant que l'enveloppe protégeait. On a écrit un type pour contraindre, puis on a percé un trou par lequel toute contrainte s'échappe. La bonne voie est plus modeste : exposer à la main, délibérément, les seules opérations qui respectent la garantie.The newtype has a known flip side: it loses the methods of the type it wraps. A Hex(Vec<u8>) no longer has .len() or .iter() — you must re-expose them one by one. Faced with that chore, the temptation is to implement Deref to the inner type: suddenly all of Vec's methods return, as if by magic. It's almost always a mistake. Deref on a newtype undoes precisely what the newtype brought: the barrier. Every method of the wrapped type resurfaces, including those that can violate the invariant the wrapper protected. You wrote a type to constrain, then drilled a hole through which all constraint escapes. The right path is humbler: expose by hand, deliberately, only the operations that respect the guarantee.

// Le réflexe « newtype + Deref » pour récupérer TOUTES les méthodes du type emballé
struct IdsTries(Vec<u32>);   // invariant voulu : toujours trié

impl std::ops::Deref for IdsTries {
    type Target = Vec<u32>;
    fn deref(&self) -> &Vec<u32> { &self.0 }   // « rends-moi tout Vec, transparent »
}
impl std::ops::DerefMut for IdsTries {         // …et son pendant mutable, ajouté
    fn deref_mut(&mut self) -> &mut Vec<u32> { &mut self.0 }   // « pour que ça marche »
}

let mut ids = IdsTries(vec![1, 2, 5]);
ids.binary_search(&2);   // pratique… mais Deref a TOUT exposé, y compris :
ids.push(0);             // ✕ [1, 2, 5, 0] : l'invariant « trié » est rompu, en silence.
// Deref sur un newtype rouvre la porte à ce que l'enveloppe devait protéger.

L'impl Deref semble offrir le meilleur des deux mondes : un type à soi et toutes les méthodes du Vec. Mais push, swap, sort_unstable_by remontent avec le reste, et n'importe lequel peut briser l'ordre que IdsTries promettait. Le type ne garantit plus rien : c'est un Vec avec un nom différent. Deref est fait pour les pointeurs intelligents (Box, Rc — Vol 6), pas pour simuler de l'héritage sur un newtype.The impl Deref seems to offer the best of both worlds: a type of your own and all of Vec's methods. But push, swap, sort_unstable_by come back with the rest, and any of them can break the order IdsTries promised. The type guarantees nothing anymore: it's a Vec with a different name. Deref is made for smart pointers (Box, Rc — Vol 6), not to fake inheritance on a newtype.

// On expose DÉLIBÉRÉMENT ce qui respecte l'invariant — délégation choisie
struct IdsTries(Vec<u32>);

impl IdsTries {
    fn inserer(&mut self, x: u32) {            // pas de push nu : insertion qui TRIE
        let pos = self.0.binary_search(&x).unwrap_or_else(|e| e);
        self.0.insert(pos, x);
    }
    fn contient(&self, x: u32) -> bool { self.0.binary_search(&x).is_ok() }
    fn as_slice(&self) -> &[u32] { &self.0 }   // lecture seule : sûre à exposer
}
// l'enveloppe ne fuit que ce qui préserve la garantie. l'invariant tient.

On choisit ce qui traverse l'enveloppe. inserer remplace push par une opération qui maintient le tri ; la lecture (contient, as_slice) est sûre, donc exposée librement. Le type tient enfin sa promesse — « toujours trié » devient un invariant que rien ne peut rompre depuis l'extérieur. Ré-exposer à la main est plus verbeux que Deref, mais c'est exactement le travail pour lequel on a créé le newtype : décider, opération par opération, ce qui est permis.You choose what crosses the wrapper. inserer replaces push with an operation that keeps the sort; reading (contient, as_slice) is safe, so freely exposed. The type finally keeps its promise — 'always sorted' becomes an invariant nothing can break from outside. Re-exposing by hand is wordier than Deref, but it's exactly the job the newtype was created for: deciding, operation by operation, what's allowed.