Valen lockert den Borrow Checker: Mehr Freiheit bei Speichersicherheit
Valen's Memory Safety: A New Kind of Borrow Checking
Valen stellt einen flexiblen Borrow Checker vor, der auf dem Konzept des Group Borrowing basiert. Statt starrer shared-xor-mutable-Regeln erlaubt er mehrere veränderliche Referenzen auf dasselbe Objekt, solange keine Use-after-free-Fehler entstehen. Der Compiler merkt sich, wohin eine Referenz zeigt, und prüft zur Compile-Zeit. Das ermöglicht C++-ähnliche Muster ohne Laufzeitkosten und soll sogar Rust-Interop unterstützen.
Group borrowing actually resolves the conflict, by relaxing "shared-xor-mutable" to "no use-after-free".
- kvark
Für mich klingt das eher nach "Path"-Borrowing als nach "Group"-Borrowing, aber die Idee ist großartig! Ziemlich augenöffnend!
Eine Kleinigkeit ist, dass ich mir nicht sicher bin, warum sie das "in"-Schlüsselwort für Sub-Borrows haben mussten. Wäre es nicht konsistenter, "entity &world.entities[?]" statt "entity in world.entities[]" zu sehen? Wir würden konsistent das Borrow-Symbol "&" bekommen und die Tür für einige Verträge öffnen, welcher Index (Bereich) betroffen ist.
- zamalek
> Borrow Checking hat die "shared-xor-mutable"-Einschränkung: Wenn du eine Referenz auf ein Objekt hältst, kann niemand sonst das Objekt ändern.
Der Artikel lässt das wie ein Problem klingen. Ist es aber nicht. Diese Einschränkung befreit dich davon, über bestimmte Klassen von Bugs in nebenläufigem Code nachzudenken; daher kommt die "fearless concurrency". R^w geht es nicht um Lebensdauern – man könnte es, im Geiste (nicht sicher in der Praxis), aus Rust entfernen, ohne Use-after-Free überhaupt zu beeinflussen.
Natürlich bedeutet es, dass man viele völlig gültige Programme nicht schreiben kann, und daher würden wir hoffen, dass es eine bessere Lösung gibt, aber es zu entfernen ist keine.
Wenn du darüber nachdenken willst (und möglicherweise Bugs einführst), ist das völlig in Ordnung. Die Flexibilität, r^w nicht zu erfordern, ist extrem nützlich. Ich kläre nur diese Fehlzuschreibung auf.
- SleepyMyroslav
Das sieht cool aus für codegetriebene Systeme, bei denen der Code statisches Wissen über jeden Pfad im System hat. Es könnte strikt besser sein für Dinge wie Rendering, wo Rendering-Arten codegetrieben sind. Zum Beispiel kann deine Welt eine Skybox und so haben. Die Beispiele, die gamedev 'world' und 'entity' annehmen, sind allerdings völlig irreführend. Denn ich denke, jeder ist zu datengetriebenen Welten übergegangen. Betrachte 'entity' aus den Codebeispielen als 'entity blueprint execute'.
- melodyogonna
Mojos Origin kann viele dieser Semantiken repräsentieren. Ich denke, es wurde viel aus Nicks Vorschlag gelernt, auch wenn er nicht direkt umgesetzt wurde. Hier ist ein Beispiel, wie man den ersten Ausschnitt darstellen könnte, bei dem zwei Referenzen dieselbe Liste aktualisieren können: https://godbolt.org/z/78bhzWjYM
- verdagon
Außerdem, als ich das schrieb, fielen mir ein paar Dinge auf:
* Wir _könnten_ die Funktionsparametersyntax `entities: &world.entities[]` anstelle von `entities in world.entities[]` verwenden.
* "Groups" sind nicht wirklich zentral für das Verständnis der Idee, daher könnte Path Borrowing ein besserer Name als Group Borrowing sein.
Meinungen willkommen =)