RustAst/docs/Zustand 5.md

Von "Guaranteed Safety" zu "Guided Safety"

Die Lösung ist nicht, die Sicherheitsanalyse abzuschaffen, sondern ihre Konsequenz zu ändern. Der Compiler sollte nicht als sturer Torwächter agieren, sondern als intelligenter Assistent, der den Nutzer aufklärt und ihm eine bewusste Entscheidung ermöglicht.

Der neue Ansatz:

1. Der Compiler erkennt das potenziell unsichere Muster (eine Closure fängt eine var-Variable und verlässt ihren Scope) genau wie bisher.
2. Statt eines harten Fehlers erzeugt er eine detaillierte Warnung.
3. Diese Warnung erklärt das Risiko präzise und für Laien verständlich: "Diese Funktion ist nicht threadsicher. Für isolierte Berechnungen wie Backtests ist das in Ordnung. Wenn Sie sie aber zwischen Threads teilen, kann es zu Fehlern kommen."
4. Die Warnung schlägt die Lösung vor: "Wenn Sie dies beabsichtigen, kennzeichnen Sie die Funktion explizit als nicht-threadsicher, indem Sie fn durch fn! ersetzen."
5. Der Nutzer ändert fn zu fn!. Die Warnung verschwindet. Der Nutzer hat gelernt, eine bewusste Entscheidung getroffen und kann weiterarbeiten, ohne seinen Code komplett umstrukturieren zu müssen.

Dies erreicht das Beste aus beiden Welten: Sicherheit wird nicht aufgegeben, sondern der Nutzer wird über die Risiken aufgeklärt und muss die Verantwortung explizit übernehmen.

---

Ich fasse das Ergebnis in einem neuen Projektplan-Eintrag zusammen.

Projektplan: "Guided Safety" und der fn!-Modifikator

• Datum: 09. Oktober 2025
• Uhrzeit: 17:47

Motivation

Die strikte "safe-by-design"-Garantie, die das "Escaping" von var-Variablen durch einen Compiler-Fehler verhindert, erweist sich für die Zielgruppe der programmiertechnisch unerfahrenen Domänen-Experten als zu restriktiv. Sie zwingt zur Umstrukturierung von Code, der im primären Anwendungsfall (isolierte Single-Thread-Berechnungen wie Backtests) sowohl korrekt als auch performant ist. Dies führt zu Frustration und mindert die Akzeptanz der Sprache.

Ziel

Das Sicherheitsmodell der Sprache wird von einer rigiden "Guaranteed Safety" zu einer benutzerfreundlichen "Guided Safety" weiterentwickelt. Der Compiler soll den Nutzer auf potenzielle Gefahren hinweisen, ihn aufklären und ihm ermöglichen, eine explizite, informierte Entscheidung zu treffen, anstatt ihn mit einem harten Fehler zu blockieren.

Ergebnis

1. Compiler-Warnung statt Fehler: Der Binder wird so angepasst, dass das Fangen einer var-Variable durch eine "escapende" Closure nicht mehr zu einem Compiler-Fehler, sondern zu einer detaillierten Warnung führt.

2. Einführung von fn!: Ein neuer Funktions-Deklarations-Syntax (fn! ...) wird eingeführt. Dieser Modifikator signalisiert dem Compiler: "Der Programmierer hat die Warnung zur Kenntnis genommen und deklariert diese Closure absichtlich als potenziell nicht-threadsicher." Das Vorhandensein von fn! unterdrückt die entsprechende Compiler-Warnung.

3. Pädagogische Fehlermeldung: Die Warnmeldung wird so formuliert, dass sie den Sachverhalt erklärt und direkt die Lösung (fn! verwenden) vorschlägt. Beispiel:

   Warnung: Die Funktion erfasst die veränderliche Variable 'sum', die außerhalb dieses Bereichs definiert wurde. Dies macht die Funktion nicht threadsicher. Für isolierte Berechnungen (z.B. in einem Backtest) ist dies unproblematisch und performant. Um zu bestätigen, dass dies beabsichtigt ist, ändern Sie (fn ...) zu (fn! ...)."

4. Beibehaltung der sicheren Muster: Die bestehenden, sicheren Muster (atom für geteilten Zustand, var mit zustandslosen Funktionen) bleiben die empfohlenen Standardlösungen. fn! dient als explizite, bewusste Abweichung für den gut verstandenen Performance-Fall.

Todo

• Die Logik im Binder anpassen, um eine Warnung anstelle eines Fehlers für "escapende var-Variablen" zu generieren.
• Den Parser um die Erkennung des fn!-Schlüsselworts erweitern.
• Die Binder-Logik erweitern, sodass fn! die Warnung unterdrückt.
• Die exakte Formulierung der neuen Warnmeldung implementieren.
• Die Dokumentation aktualisieren, um das "Guided Safety"-Konzept und die korrekte Verwendung von fn, fn! und atom zu erklären.