/* Page prose (fr) */
"SendableClosuresIntro" = "# Closures `@Sendable`: ce qu'une tâche detached exige de toi\n\nCes erreurs ne parlent en réalité que d'une chose: une closure qui s'exécute dans un domaine d'isolation *différent* de celui où tu l'as écrite doit être **`@Sendable`**: sûre à passer et à exécuter concurremment. C'est la closure que tu passes à `Task.detached { }` (et à un `TaskGroup`). Pour rester sûre, une closure `@Sendable` est restreinte dans ce qu'elle peut capturer:\n\n* Elle peut capturer librement des valeurs **Sendable** (elles sont sûres à emporter de l'autre côté).\n* Elle **ne peut pas** capturer un type non Sendable comme une classe mutable (c'est l'erreur d'`OrderCount`).\n* Elle **ne peut pas** capturer un `var` local et le muter, parce que ce `var` vit dans le domaine externe et que la closure s'exécute dans un autre: une course par construction.\n\nCette dernière fait trébucher les gens, alors regarde-la directement:\n\n```swift\nvar runningTotal = 0\n\nTask.detached {\n    runningTotal += 1   // will not compile: mutated from another domain\n    print(runningTotal)\n}\n```\n\nLe compilateur rejette la mutation: *\"main actor-isolated var 'runningTotal' can not be mutated from a nonisolated context.\"* La correction est la même famille de réponses: ne partage pas d'état mutable à travers la frontière. Calcule une valeur et laisse la tâche la *retourner*, ou achemine la mutation à travers un actor:";
"SendableClosuresWrap" = "Une fois que tu as intériorisé \"une closure de `Task` ne peut emporter que des choses Sendable\", la plupart de ces erreurs se lisent comme des rappels utiles plutôt que des obstacles.\n\n[Précédent](@previous)  |  page 9 sur 11  |  [Suivant: Swift 6: la sûreté à la compilation](@next)";
