/* Page prose (de) */
"NonSendableProblem" = "# Warum eine veränderliche Klasse nicht Sendable ist und wie man das repariert\n\nNun der Fall, den das ganze Protokoll existiert, um ihn abzufangen. Stell dir eine geteilte Anzeigetafel für die tägliche Bestellzahl der Kaffeebar vor: eine Klasse, weil wir ein Objekt wollen, das alle aktualisieren:\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\nIm Sprachmodus von Swift 6 **kompiliert das nicht.** Der Fehler lautet: *\"non-Sendable type 'OrderCount' of let 'orders' cannot exit main actor-isolated context\"*, mit einem Hinweis, dass `OrderCount` *\"does not conform to the `Sendable` protocol.\"* Der Compiler sieht eine veränderliche Klasse, die gleich an eine andere Isolationsdomäne gereicht wird, und stoppt dich, *bevor* der Race überhaupt passieren kann. Das ist die Verschiebung gegenüber dem klassischen Modell: Der Data Race im Kapitel [Gefahren der Nebenläufigkeit](Concurrency%20Hazards.playgroundchapter/Overview) war eine Laufzeitüberraschung, über die du nachdenken musstest; hier ist es ein Kompilierfehler, den du nicht übersehen kannst.\n\n* callout(Probier es aus): Stell dir vor, du änderst das `Task.detached` oben in eine einfache `Task { }`. Würde der Code kompilieren? (Ja, würde er; der nächste Callout erklärt warum.)\n\n* callout(Warum das kompiliert): Code auf oberster Ebene, wie eine Playground-Seite, läuft *auf dem MainActor*. Eine einfache `Task { }` **erbt** diese MainActor-Isolation, sodass das Objekt seine Domäne nie verlässt und der Code tatsächlich kompiliert. `Task.detached` läuft *außerhalb* des MainActor, und dieser Grenzübertritt ist es, was das Teilen einer veränderlichen Klasse unsicher macht. Die Lektion: Die Gefahr taucht auf, wenn veränderlicher State **zwischen** Domänen **wechselt**, und genau dort setzt der Compiler den Stolperdraht.\n\nDu hast drei ehrliche Wege, das zu reparieren:\n\n**1. Mach sie zu einem Actor** (am besten, wenn der State veränderlich und geteilt bleiben muss):";
"NonSendableFixes" = "Actors sind automatisch Sendable; das ist ihre Aufgabe. Einen zu teilen ist immer sicher, weil der Actor jeden Zugriff serialisiert.\n\n**2. Mach sie unveränderlich** (am besten, wenn der Wert sich nach der Erstellung nie ändert):\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` + alles-`let` + Sendable-Member = eine Klasse, die du sicher teilen kannst, weil es nichts zu mutieren gibt.\n\n**3. Isoliere sie auf einen Actor** (einschließlich `@MainActor`):\n\nMarkiere den Typ mit einem globalen Actor, sodass jeder Zugriff bereits durch eine Domäne geleitet wird, was genau das ist, was `BalanceDisplay` zuvor tat.\n\nEs gibt auch eine Notluke, `@unchecked Sendable`, bei der *du* versprichst, dass der Typ sicher ist (etwa weil er seinen eigenen State mit einem Lock schützt) und der Compiler dir beim Wort glaubt. Behandle sie als letzten Ausweg: Der ganze Sinn dieses Kapitels ist, den Compiler die Prüfung machen zu lassen, nicht sie abzuschalten.\n\n[Zurück](@previous)  |  Seite 8 von 11  |  [Weiter: Sendable-Closures](@next)";
