/* Page prose (fr) */
"VersionAClassic" = "# Version A (classique): GCD + completion handlers + `DispatchGroup`\n\nChaque récupération prend un **completion handler**, une closure qu'elle rappelle avec un `Result` quand le réseau (simulé) se termine. Comme les deux récupérations sont indépendantes, nous les poussons toutes les deux sur des files d'arrière-plan et nous utilisons un **`DispatchGroup`** pour savoir quand *les deux* ont rappelé. Puis nous sautons sur le principal pour combiner et rapporter.";
"VersionAClassic-2" = "**Observe l'exécution:** `Fetching menu and stock...` s'affiche en premier: les deux appels à `fetch` ont retourné immédiatement. Les deux récupérations s'exécutent en parallèle (0.6 s et 0.4 s), donc environ 0.6 seconde plus tard le groupe se vide et tu obtiens, sur le thread principal:\n\n* callout(Sortie):\n`Fetching menu and stock...`  \n`Sellable today: [\"Latte\", \"Espresso\"]`\n\nLe cold brew est filtré car son stock est `0`.\n\n* callout(Essaie): Change le stock du cold brew dans `fetchStock` de `0` à `2`. Apparaît-il maintenant dans la liste des vendables?\n\nMaintenant compte ce que cela t'a coûté:\n\n* Deux variables mutables `Result?` vivant en dehors des closures, pour faire sortir en douce chaque réponse de son completion handler.\n* Une comptabilité manuelle de `enter()`/`leave()`: un faux pas et le groupe se bloque ou plante.\n* Le résultat est deux `Result` **optionnels** au point de jonction, il te faut donc un `guard` *et* un `do`-`try`-`catch` pour passer de \"deux `Result?`\" à \"deux vraies valeurs ou une erreur.\"\n* Le saut vers le thread principal est une chose que *toi* tu as pensé à faire (`notify(queue: .main)`). Oublie-le et tu combinerais sur un thread d'arrière-plan et mettrais à jour l'UI depuis là, un bug que le compilateur ne mentionne jamais.\n\nRien de tout cela n'est faux. Mais chaque morceau est manuel, et la logique réelle, \"filtrer le menu par le stock,\" est enterrée sous le cérémonial.\n\n* callout(Aparté sur les data races): `menuResult` et `stockResult` sont écrits depuis des threads d'arrière-plan et lus dans `notify`. Cela se trouve être sûr parce que l'ordre `leave()` → `notify` du groupe garantit que les écritures se terminent avant la lecture, mais *rien ne le vérifie pour toi*. C'est exactement la classe de risque que les data races causent en général, et exactement ce que le modèle moderne élimine par construction.\n\n[Précédent](@previous)  |  page 3 sur 8  |  [Suivant: Version B: la façon moderne](@next)";
