/* Page prose (fr) */
"SuspendThenResume" = "# `withCheckedContinuation`: suspendre, puis reprendre\n\nFaisons le pont vers une API héritée qui semble réelle. Imagine un SDK plus ancien du café du coin qui récupère le spécial du jour à l'ancienne: un completion handler, livré après un délai depuis une file d'arrière-plan. Tu ne peux pas le changer; tu veux juste lui faire `await`.";
"SuspendThenResume-2" = "**Observe l'exécution:** `Asking the counter...` s'imprime en premier. Puis la page s'interrompt pendant environ quatre dixièmes de seconde: c'est `todaysSpecial()` **suspendue** à son `await`, en attente sur la continuation. Quand la completion de `fetchTodaysSpecial` se déclenche, `resume(returning:)` livre la chaîne, la fonction asynchrone se réveille, et le spécial s'imprime. Tu as enveloppé un callback dans `await` sans toucher à la vieille API.\n\n* callout(Essaie): Change le délai de `asyncAfter` à `1.5`. La ligne \"Asking the counter...\" s'imprime toujours en premier, et la pause avant le spécial ne fait que s'allonger.\n\n> **Pourquoi `@Sendable` sur la completion?** L'API héritée saute vers une file d'arrière-plan, et en Swift 6 une closure qui franchit cette frontière doit être `@Sendable` (sûre à remettre à un autre thread). C'est sur l'API *simulée* ici pour que l'exemple reste sans avertissement; les completion handlers réels de SDK que tu relies le portent déjà en général. Sendable a droit à son propre traitement dans le chapitre [Actors globaux et Sendable](Global%20Actors%20and%20Sendable.playgroundchapter/Overview).\n\n[Précédent](@previous)  |  page 2 sur 8  |  [Suivant: Échouer avec un Result](@next)";
