Itérateurs & abstractions zéro-coût Iterators & zero-cost abstractions

La chaîne d'itérateurs compile vers exactement la boucle qu'on aurait écrite.The iterator chain compiles to exactly the loop you'd have written.

On ouvre le dernier volume, celui du coût. Et la première peur, héritée des langages à GC, vise les itérateurs. En JavaScript, arr.map().filter() crée un tableau intermédiaire à chaque étape, parcouru en entier : deux allocations, deux passes, pour une seule logique. Le réflexe qu'on en garde est de « redescendre à une boucle manuelle » dès qu'il s'agit de performance. En Rust, cette peur est infondée, et c'est le cœur du numéro. La chaîne .iter().map().filter().collect() ne crée aucune collection intermédiaire et compile, après optimisation, vers un code machine équivalent à celui de la boucle écrite à la main. C'est le sens précis de « zéro-coût » : l'abstraction se paie à la compilation (en monomorphisation et inlining, Vol 5), jamais à l'exécution. Tu écris ce qui est lisible ; tu obtiens ce qui est rapide. Les deux ne s'opposent pas.We open the last volume, the one on cost. And the first fear, inherited from GC languages, targets iterators. In JavaScript, arr.map().filter() creates an intermediate array at each step, traversed in full: two allocations, two passes, for one logic. The reflex you keep is to 'drop down to a manual loop' the moment performance matters. In Rust, that fear is unfounded, and it's the heart of the issue. The .iter().map().filter().collect() chain creates no intermediate collection and compiles, after optimization, to machine code equivalent to the hand-written loop. That's the precise meaning of 'zero-cost': the abstraction is paid at compile time (in monomorphization and inlining, Vol 5), never at runtime. You write what's readable; you get what's fast. The two aren't opposed.

// la chaîne lisible
let pairs_doubles: Vec<i32> = nombres.iter()
    .filter(|&&n| n % 2 == 0)
    .map(|&n| n * 2)
    .collect();

// la boucle « à la main » qu'on écrirait par peur du surcoût
let mut pairs_doubles = Vec::new();
for &n in &nombres {
    if n % 2 == 0 { pairs_doubles.push(n * 2); }
}
// après optimisation, les deux produisent un code machine ÉQUIVALENT. la chaîne ne coûte rien
// de plus — c'est ça, le « zéro-coût » : payé à la compilation, pas à l'exécution.

.map() ne fait rien : il décrit un calcul, et n'alloue aucun tableau..map() does nothing: it describes a computation, and allocates no array.

La raison pour laquelle la chaîne ne coûte rien tient en un mot : elle est paresseuse. C'est l'écho exact de la leçon du Vol 8 sur les Futures — appeler .map() ou .filter() n'exécute aucun travail, ne parcourt rien, n'alloue rien. Cela construit simplement un nouvel itérateur : une struct qui se souvient « j'appliquerai cette fonction quand on me tirera des éléments ». Tant qu'aucun consommateur ne demande de valeurs — collect, sum, for, count — la chaîne reste inerte. Le compilateur va jusqu'à t'avertir si tu oublies de consommer : « iterators are lazy and do nothing unless consumed ». Conséquence directe et heureuse : il n'y a pas de tableaux intermédiaires. Les adaptateurs empilés ne créent pas une collection par étape ; ils fusionnent en une seule passe qui tire chaque élément une fois, à travers toute la chaîne.The reason the chain costs nothing fits in one word: it's lazy. It's the exact echo of Vol 8's lesson on Futures — calling .map() or .filter() runs no work, traverses nothing, allocates nothing. It simply builds a new iterator: a struct that remembers 'I'll apply this function when elements are pulled from me'. As long as no consumer asks for values — collect, sum, for, count — the chain stays inert. The compiler even warns you if you forget to consume: 'iterators are lazy and do nothing unless consumed'. Direct and happy consequence: there are no intermediate arrays. Stacked adapters don't create one collection per step; they fuse into a single pass that pulls each element once, through the whole chain.

let v = vec![1, 2, 3];

v.iter().map(|x| println!("{x}"));   // ✕ n'affiche RIEN
//   warning: unused `Map` that must be used
//   note: iterators are lazy and do nothing unless consumed

// .map() ne fait qu'EMBALLER : il rend un Map<…>, une description, pas une exécution.
// rien ne tourne tant qu'un consommateur (collect, sum, for, count…) ne TIRE pas les éléments.

« Iterators are lazy and do nothing unless consumed » — la même phrase, presque mot pour mot, que pour les Future du Vol 8. Et la même logique : un adaptateur est une valeur (une struct), pas une exécution. La construire ne déclenche rien ; seul un consommateur tire les éléments et fait tourner toute la chaîne, élément par élément. C'est cette paresse qui rend la fusion possible : puisque rien ne se matérialise avant le consommateur final, le compilateur peut tout fondre en une passe unique. Lazy par conception, fusionné en conséquence.'Iterators are lazy and do nothing unless consumed' — the same sentence, almost word for word, as for Vol 8's Futures. And the same logic: an adapter is a value (a struct), not an execution. Building it triggers nothing; only a consumer pulls the elements and runs the whole chain, element by element. That laziness is what makes fusion possible: since nothing materializes before the final consumer, the compiler can melt it all into a single pass. Lazy by design, fused as a result.

Des structs imbriquées, que la monomorphisation aplatit en une boucle.Nested structs, which monomorphization flattens into one loop.

Comment une chaîne d'appels peut-elle ne rien coûter ? Le secret est que chaque adaptateur est une struct qui en enveloppe une autre. .filter(p) ne filtre rien : il rend un Filter qui détient l'itérateur précédent et le prédicat. .map(f) rend un Map qui détient ce Filter et la fonction. La chaîne entière est donc un type imbriqué — Map<Filter<Iter>, F> — et tout repose sur une seule méthode, next, que chaque couche implémente en appelant celle de la couche en dessous. Quand collect tire les éléments, l'appel descend en cascade à travers les structs. C'est ici qu'intervient la mécanique du Vol 5 : la monomorphisation génère du code concret pour chaque type, et l'inlining fond les next() imbriqués les uns dans les autres. Il ne reste, dans le binaire, qu'une boucle plate — aucune trace des couches. L'abstraction n'est pas exécutée puis optimisée : elle est effacée.How can a chain of calls cost nothing? The secret is that each adapter is a struct wrapping another. .filter(p) filters nothing: it returns a Filter holding the previous iterator and the predicate. .map(f) returns a Map holding that Filter and the function. The whole chain is thus a nested type — Map<Filter<Iter>, F> — and everything rests on a single method, next, which each layer implements by calling the one below. When collect pulls the elements, the call cascades down through the structs. Here's where Vol 5's machinery enters: monomorphization generates concrete code for each type, and inlining melts the nested next()s into one another. All that remains, in the binary, is one flat loop — no trace of the layers. The abstraction isn't executed then optimized: it's erased.

trait Iterator {
    type Item;
    fn next(&mut self) -> Option<Self::Item>;   // « donne l'élément suivant, ou None »
}
// tout le reste — map, filter, take, zip, sum… — est construit SUR ce seul next().
// chaque adaptateur implémente next() en appelant le next() de l'itérateur qu'il enveloppe.

// .map() et .filter() ne « font » rien : ils EMBALLENT l'itérateur précédent dans une struct
let chaine = nombres.iter().filter(pred).map(f);
//   type réel ≈  Map<Filter<Iter<i32>, P>, F>     ← des structs imbriquées

// collect() appelle .next() en boucle ; chaque .next() traverse les couches :
//   Map::next  →  Filter::next  →  Iter::next,  puis applique f
// monomorphisation (Vol 5) + inlining : le compilateur APLATIT toutes ces couches en
// une seule boucle, sans appel de fonction ni indirection. l'abstraction est EFFACÉE.

L'abstraction est gratuite — mais la matérialiser au mauvais endroit ne l'est pas.The abstraction is free — but materializing it at the wrong spot isn't.

Le zéro-coût concerne les adaptateurs paresseux — map, filter, take — qui fusionnent en une passe. Mais un consommateur, lui, fait un vrai travail : collect alloue une collection et la remplit. C'est là qu'on se piège, à l'inverse de la peur du chapitre 2 : non en craignant un coût qui n'existe pas, mais en en créant un sans le voir. Le cas typique : glisser un collect au milieu d'une chaîne, pour « y voir clair » ou par habitude, puis reparcourir le Vec ainsi produit. On vient de matérialiser une collection intermédiaire — exactement ce que la paresse évitait — et de parcourir les données deux fois au lieu d'une. La chaîne avait raison d'être paresseuse ; on a brisé la fusion de nos propres mains. Le coût n'est pas dans l'abstraction : il est dans le fait de la matérialiser trop tôt.Zero-cost concerns the lazy adapters — map, filter, take — that fuse into one pass. But a consumer does real work: collect allocates a collection and fills it. That's where you trap yourself, the inverse of chapter 2's fear: not by fearing a cost that doesn't exist, but by creating one without seeing it. The typical case: slipping a collect into the middle of a chain, 'to see clearly' or out of habit, then re-traversing the resulting Vec. You've just materialized an intermediate collection — exactly what laziness avoided — and traversed the data twice instead of once. The chain was right to be lazy; you broke the fusion with your own hands. The cost isn't in the abstraction: it's in materializing it too early.

let resultat: Vec<i32> = nombres.iter()
    .filter(|&&n| n > 0)
    .collect::<Vec<&i32>>()    // ✕ matérialise un Vec intermédiaire : 1 allocation + 1 passe
    .iter()                    //   …qu'on reparcourt aussitôt
    .map(|&&n| n * 2)
    .collect();
// le collect du milieu CASSE la fusion : on alloue un Vec qu'on jette, et on parcourt deux fois.

let resultat: Vec<i32> = nombres.iter()
    .filter(|&&n| n > 0)
    .map(|&n| n * 2)           // ✓ la chaîne reste PARESSEUSE de bout en bout
    .collect();                // un seul collect, à la fin : une passe, une allocation
// règle : un seul point de matérialisation, le plus tard possible. collect au milieu = stop.

La règle est limpide : un seul point de matérialisation, le plus tard possible. Garde la chaîne paresseuse jusqu'au consommateur final ; n'appelle collect que lorsque tu as réellement besoin de la collection (pour la stocker, la retourner, la parcourir plusieurs fois). Tout collect intermédiaire est un signal d'alarme : ou bien il est inutile et casse la fusion, ou bien il y a une vraie raison — et alors elle doit être explicite, pas accidentelle. La paresse fait le bon choix par défaut ; c'est en la court-circuitant qu'on paie.The rule is clear: a single materialization point, as late as possible. Keep the chain lazy until the final consumer; only call collect when you genuinely need the collection (to store it, return it, traverse it several times). Any intermediate collect is an alarm signal: either it's useless and breaks the fusion, or there's a real reason — and then it must be explicit, not accidental. Laziness makes the right choice by default; it's by short-circuiting it that you pay.