Trait objects (dyn), ou la vtable et son prix Trait objects (dyn), or the vtable and its price

Quand le compilateur ne peut pas connaître le type, on l'efface.When the compiler can't know the type, you erase it.

Le numéro précédent a montré la moitié lumineuse du dispatch : les generics, résolus à la compilation, à coût nul. Mais cette résolution suppose que le compilateur connaisse le type concret de chaque appel. Parfois, c'est impossible — non par paresse, mais par nature. Un Vec<T> générique est homogène : un seul T pour tout le vecteur. Comment mettre un cercle et un rectangle dans la même collection, les traiter uniformément, alors qu'ils n'ont pas le même type ? La réponse est le trait object : dyn Surface, un type « effacé » qui ne dit plus que « ceci honore le contrat Surface ». On échange la connaissance du type concret — et le coût zéro qui allait avec — contre la liberté de mélanger.The previous issue showed dispatch's bright half: generics, resolved at compile time, at zero cost. But that resolution assumes the compiler knows each call's concrete type. Sometimes that's impossible — not from laziness, but by nature. A generic Vec<T> is homogeneous: a single T for the whole vector. How do you put a circle and a rectangle in the same collection, handle them uniformly, when they aren't the same type? The answer is the trait object: dyn Surface, an 'erased' type that says only 'this honors the Surface contract'. You trade knowing the concrete type — and the zero cost that came with it — for the freedom to mix.

// Le générique fige UN type par usage : un Vec<T> ne contient qu'un seul T.
// Pour mélanger des types qui partagent un trait, on EFFACE le type concret :

let formes: Vec<Box<dyn Surface>> = vec![
    Box::new(Cercle { r: 1.0 }),       // un Cercle…
    Box::new(Rectangle { l: 2.0, h: 3.0 }),  // …et un Rectangle, dans le MÊME Vec
];

for f in &formes {
    println!("aire = {}", f.aire());   // l'appel trouve la bonne méthode à l'exécution
}
// dyn Surface = « un quelque-chose qui est Surface, dont j'ai oublié le type exact ».

Un Vec générique ne mélange rien. Un Vec de dyn mélange tout.A generic Vec mixes nothing. A Vec of dyn mixes everything.

Voici la surprise qui révèle pourquoi dyn existe. On pourrait croire qu'un Vec<T: Surface> accepte n'importe quelle forme — après tout, ce sont toutes des Surface. C'est faux. La monomorphisation fixe un seul T pour tout le vecteur : un Vec de cercles, ou un Vec de rectangles, jamais les deux. Le générique n'abstrait pas « une forme quelconque », il abstrait « un type, choisi une fois ». Pour une collection réellement hétérogène — des formes de types divers côte à côte, chacune gardant son comportement — il n'y a qu'une voie : effacer le type concret derrière dyn. La flexibilité que le générique refuse, le trait object l'offre.Here's the surprise that reveals why dyn exists. You might think a Vec<T: Surface> accepts any shape — they're all Surfaces, after all. It's false. Monomorphization fixes a single T for the whole vector: a Vec of circles, or a Vec of rectangles, never both. The generic doesn't abstract 'some shape', it abstracts 'one type, chosen once'. For a truly heterogeneous collection — shapes of various types side by side, each keeping its behavior — there's only one path: erase the concrete type behind dyn. The flexibility the generic refuses, the trait object grants.

// Générique : un Vec<T> est HOMOGÈNE — un seul type pour tout le vecteur
fn aire_totale<T: Surface>(formes: &[T]) -> f64 {
    formes.iter().map(|f| f.aire()).sum()
}

let cercles = vec![Cercle { r: 1.0 }, Cercle { r: 2.0 }];
aire_totale(&cercles);   // ✓ T = Cercle, tout le slice est du même type

let melange = vec![Cercle { r: 1.0 }, Rectangle { l: 2.0, h: 3.0 }];
//                 ^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// ✕ NE COMPILE PAS : Vec attend un seul type, Cercle ≠ Rectangle.

Le générique brille tant que chaque collection est d'un seul type — et il échoue dès qu'on veut les mélanger. aire_totale<T> sera monomorphisée en aire_totale_cercle, aire_totale_rectangle… une version par type, chacune attendant un slice homogène. Le vec![cercle, rectangle] ne compile pas, parce qu'aucun T unique ne peut désigner les deux. Ce n'est pas un défaut : c'est la conséquence directe du coût zéro. Connaître le type pour le spécialiser, c'est renoncer à en mélanger plusieurs.The generic shines as long as each collection is of one type — and fails the moment you want to mix them. aire_totale<T> will monomorphize into aire_totale_cercle, aire_totale_rectangle… one version per type, each expecting a homogeneous slice. The vec![circle, rectangle] won't compile, because no single T can denote both. It's not a flaw: it's the direct consequence of zero cost. Knowing the type to specialize it means giving up mixing several.

La vtable : comment l'appel retrouve la bonne méthode à l'exécution.The vtable: how the call finds the right method at runtime.

Si le type est effacé, comment f.aire() sait-il quelle aire() appeler ? Par la vtable. Un trait object n'est pas un pointeur ordinaire : c'est un pointeur gras, deux mots côte à côte. Le premier pointe vers la donnée (le Cercle, le Rectangle) ; le second vers une table de méthodes — la vtable — propre au type concret, générée par le compilateur. Appeler une méthode, c'est suivre le second pointeur, y lire l'adresse de la bonne fonction, et l'appeler. Une indirection de plus qu'un appel direct. C'est précisément ce surcoût — minuscule mais non nul — qu'on échange contre la flexibilité du chapitre précédent. Et il a un corollaire : l'appel ne peut plus être inliné, ce qui pèse parfois plus que l'indirection elle-même.If the type is erased, how does f.aire() know which aire() to call? Through the vtable. A trait object isn't an ordinary pointer: it's a fat pointer, two words side by side. The first points to the data (the Cercle, the Rectangle); the second to a method table — the vtable — specific to the concrete type, generated by the compiler. Calling a method means following the second pointer, reading the right function's address there, and calling it. One indirection more than a direct call. It's precisely that overhead — tiny but non-zero — that you trade for the previous chapter's flexibility. And it has a corollary: the call can no longer be inlined, which sometimes weighs more than the indirection itself.

// Un &dyn Surface n'est PAS un simple pointeur : c'est un pointeur « gras »
//   (fat pointer) = deux mots côte à côte.

//   ┌─────────────┬─────────────┐
//   │  data ptr   │  vtable ptr │     &dyn Surface  (2 × usize)
//   └──────┬──────┴──────┬──────┘
//          │             │
//          ▼             ▼
//      [ Cercle ]   [ vtable de Cercle: { aire, drop, size, align } ]

// f.aire()  ≡  (f.vtable.aire)(f.data)
//   → on suit le vtable ptr, on y lit l'adresse de aire(), on l'appelle.
//   UNE indirection de plus qu'un appel direct — c'est ça, le « prix ».

Le Box<dyn> réflexe : payer la flexibilité qu'on n'utilise pas.The reflexive Box<dyn>: paying for flexibility you don't use.

Le piège symétrique de la généricité gratuite, c'est le dyn gratuit. dyn se lit plus court qu'une signature générique : pas de paramètre de type, pas de borne à déclarer, une signature qui « fait propre ». La tentation est de l'employer partout, y compris là où un seul type concret passe réellement. Mais on paie alors trois fois sans rien recevoir : une allocation sur le tas pour le Box, une indirection de vtable à chaque appel, et l'inlining perdu — pour une hétérogénéité que personne n'exploite. Le dyn n'est justifié que par un besoin réel : mélanger des types, ou manipuler un type qu'on ne connaîtra qu'à l'exécution. Sans ce besoin, c'est du coût pur.The symmetric trap to gratuitous genericity is gratuitous dyn. dyn reads shorter than a generic signature: no type parameter, no bound to declare, a signature that 'looks clean'. The temptation is to use it everywhere, including where a single concrete type actually flows through. But then you pay three times for nothing: a heap allocation for the Box, a vtable indirection on every call, and lost inlining — for a heterogeneity no one exploits. dyn is justified only by a real need: mixing types, or handling a type you'll only know at runtime. Without that need, it's pure cost.

// Box<dyn> par réflexe, là où un seul type passe vraiment
fn traiter(mut source: Box<dyn Read>) -> Result<Vec<u8>, Err> {
    let mut buf = Vec::new();
    source.read_to_end(&mut buf)?;   // chaque read passe par la vtable
    Ok(buf)
}

// appelé seulement avec des File. on a payé : une allocation tas (Box),
// une indirection par appel, et l'inlining perdu — pour une flexibilité
// que personne n'utilise. le dyn ne sert ici qu'à esquiver d'écrire <R: Read>.

Ici, dyn Read n'apporte aucune flexibilité utile : la fonction n'est jamais appelée qu'avec un seul type concret. Le Box force une allocation tas, chaque read traverse la vtable, et le compilateur ne peut plus inliner ni optimiser à travers — le tout pour éviter d'écrire trois caractères, <R: Read>. C'est un marché perdant : on prend tous les inconvénients du dispatch dynamique sans le seul avantage qui les rachète.Here, dyn Read brings no useful flexibility: the function is only ever called with a single concrete type. The Box forces a heap allocation, each read goes through the vtable, and the compiler can no longer inline or optimize across — all to avoid writing three characters, <R: Read>. It's a losing deal: you take all of dynamic dispatch's drawbacks without the one advantage that redeems them.

// Générique par défaut : statique, inlinable, sans allocation
fn traiter<R: Read>(mut source: R) -> Result<Vec<u8>, Err> {
    let mut buf = Vec::new();
    source.read_to_end(&mut buf)?;   // appel direct, inliné, coût zéro
    Ok(buf)
}

// dyn se réserve aux cas où on en a VRAIMENT besoin :
struct Pipeline { etapes: Vec<Box<dyn Etape>> }   // hétérogène : justifié
fn charger_plugin(nom: &str) -> Box<dyn Plugin> { /* type connu au runtime */ }

Le générique redonne l'appel direct, inlinable, sans allocation — le coût zéro du n°1. Et dyn reprend sa juste place : la Vec<Box<dyn Etape>> d'un pipeline réellement hétérogène, le Box<dyn Plugin> dont le type n'est connu qu'au chargement. La question n'est pas « statique ou dynamique par goût », mais « ai-je besoin de mélanger des types ou d'en différer un ». Oui → dyn, et son prix est mérité. Non → générique, et garde le coût zéro.The generic restores the direct, inlinable, allocation-free call — issue n°1's zero cost. And dyn takes its rightful place: the Vec<Box<dyn Etape>> of a truly heterogeneous pipeline, the Box<dyn Plugin> whose type is known only at load time. The question isn't 'static or dynamic by taste', but 'do I need to mix types or defer one'. Yes → dyn, and its price is earned. No → generic, and keep the zero cost.