Valenのメモリ安全：より柔軟な借用チェッカーが実現する「共有×可変」の突破
Valen's Memory Safety: A New Kind of Borrow Checking
Valenが新たに採用した「グループ借用」は、コンパイラが参照の指す先を記憶することで、use-after-freeをコンパイル時に検出しつつ、複数の可変参照を許容する。Rustの借用チェッカーよりも制約が少なく、参照カウントやGCとの併用も可能。GoogleのCarbonやAnteなども採用を進めており、メモリ安全の新たな潮流となる可能性を秘めている。
グループ借用は「共有か可変の排他」を「use-after-freeの禁止」に緩和することで、この対立を実際に解決する。
HNでの議論
65- kvark
私には「グループ」借用というより「パス」借用のように聞こえますが、アイデアは素晴らしいです！とても目から鱗です！
一つ些細な点ですが、サブ借用に「in」キーワードが必要な理由がよくわかりません。「entity in world.entities[]」ではなく「entity &world.entities[?]」の方が一貫性があるのではないでしょうか？そうすれば常に借用記号「&」が付き、どのインデックス（範囲）が影響を受けるかについての契約を開くことができます。
- zamalek
> 借用チェックには「共有xor可変」の制約があります。オブジェクトへの参照を保持している場合、他の誰もそのオブジェクトを変更できません。
この記事はこれを問題のように書いていますが、そうではありません。この制約は、並行コードにおける特定のクラスのバグについて考える必要からあなたを解放します。これが「恐れのない並行性」の源です。R^wはライフタイムに関するものではありません。精神的には（実際は不明ですが）、use-after-freeに全く影響を与えずにRustから削除することができます。
もちろん、これは多くの完全に有効なプログラムを書けないことを意味するので、より良い解決策があることを望みますが、削除は解決策ではありません。
それについて考えなければならず（そして潜在的にバグを導入する可能性がある）ことを望むなら、それは全く問題ありません。r^wを要求しない柔軟性は非常に有用です。私はただこの誤った帰属を明確にしているだけです。
- SleepyMyroslav
これは、コードがシステム内のすべてのパスを静的に知っているコード駆動型システムにとってはクールに見えます。レンダリングの種類がコード駆動型であるレンダリングのようなものには厳密に優れているかもしれません。たとえば、あなたのワールドにスカイボックスなどを持たせることができます。しかし、ゲーム開発の「ワールド」と「エンティティ」を想定した例は完全に誤解を招きます。なぜなら、誰もがデータ駆動型のワールドに移行していると思うからです。コード例のエンティティ「advance」は「エンティティブループリント実行」と考えてください。
- melodyogonna
Mojoのoriginはこれらのセマンティクスの多くを表現できます。Nickの提案から多くを学んだと思います。たとえ直接実装されなかったとしても。以下は、2つの参照が同じリストを更新できる最初のスニペットを表現する方法の例です：https://godbolt.org/z/78bhzWjYM
- verdagon
また、これを書いているときに、いくつか気づいたことがあります：
* 関数パラメータ構文 `entities: &world.entities[]` を `entities in world.entities[]` の代わりに使うことができます。
* 「グループ」はアイデアを理解する上でそれほど中心ではないので、Group BorrowingよりもPath Borrowingの方が良い名前かもしれません。
ご意見歓迎です =)