/* Page prose (fr) */
"NonSendableProblem" = "# Pourquoi une classe mutable n'est pas Sendable, et comment la corriger\n\nMaintenant le cas que tout le protocole existe pour attraper. Imagine un tableau de score partagé pour le compte quotidien de commandes du bar à café: une classe, parce que nous voulons un seul objet que tout le monde met à jour:\n\n```swift\nfinal class OrderCount {\n    var total = 0\n}\n\nlet orders = OrderCount()\n\n// Hand the shared object to work running off the main actor:\nTask.detached {\n    orders.total += 1   // will not compile in Swift 6\n}\nprint(orders.total)\n```\n\nDans le mode de langage de Swift 6, ceci **ne compile pas.** L'erreur est: *\"non-Sendable type 'OrderCount' of let 'orders' cannot exit main actor-isolated context\"*, avec une note que `OrderCount` *\"does not conform to the `Sendable` protocol.\"* Le compilateur voit une classe mutable sur le point d'être remise à un autre domaine d'isolation et t'arrête, *avant* que la course puisse jamais se produire. C'est le changement par rapport au modèle classique: la data race du chapitre [Les dangers de la concurrence](Concurrency%20Hazards.playgroundchapter/Overview) était une surprise à l'exécution sur laquelle tu devais raisonner; ici c'est une erreur de compilation que tu ne peux pas manquer.\n\n* callout(Essaie): Imagine changer le `Task.detached` ci-dessus en une `Task { }` simple. Le code compilerait-il? (Oui; le callout suivant explique pourquoi.)\n\n* callout(Pourquoi ça compile): Le code de niveau supérieur, comme une page de Playground, s'exécute *sur le main actor*. Une `Task { }` simple **hérite** de cette isolation du main actor, donc l'objet ne quitte jamais son domaine et le code compile effectivement. `Task.detached` s'exécute *hors* du main actor, et ce franchissement de frontière est ce qui rend dangereux le partage d'une classe mutable. La leçon: le danger apparaît quand l'état mutable **passe entre** des domaines, donc c'est là que le compilateur place le fil-piège.\n\nTu as trois façons honnêtes de la corriger:\n\n**1. En faire un actor** (le mieux quand l'état doit rester mutable et partagé):";
"NonSendableFixes" = "Les actors sont Sendable automatiquement; c'est leur rôle. En partager un est toujours sûr parce que l'actor sérialise chaque accès.\n\n**2. La rendre immuable** (le mieux quand la valeur ne change jamais après création):\n\n```swift\nfinal class FrozenReceipt: Sendable {\n    let id: Int\n    let total: Int\n    init(id: Int, total: Int) {\n        self.id = id\n        self.total = total\n    }\n}\n```\n\n`final` + tout-`let` + membres Sendable = une classe que tu peux partager en toute sûreté, parce qu'il n'y a rien à muter.\n\n**3. L'isoler à un actor** (y compris `@MainActor`):\n\nÉtiquette le type avec un actor global pour que tout l'accès soit déjà canalisé à travers un seul domaine, ce qui est exactement ce que faisait `BalanceDisplay` plus tôt.\n\nIl existe aussi une échappatoire, `@unchecked Sendable`, où *toi* tu promets que le type est sûr (disons qu'il garde son propre état avec un verrou) et le compilateur te croit sur parole. Traite-la comme un dernier recours: tout l'intérêt de ce chapitre est de laisser le compilateur faire la vérification, pas de la désactiver.\n\n[Précédent](@previous)  |  page 8 sur 11  |  [Suivant: Closures Sendable](@next)";
