Non-binary Rust: Between Safe and Unsafe
summary
Refactors thousands of lines of Bevy ECS unsafe code into small abstractions that push invariants into the type system, introducing an owning pointer type, a thin-slice pointer and lifetime-annotated wrappers using PhantomData and UnsafeCell. Work recovers borrow-checker guarantees, reduces fat-pointer overhead for tight-game performance, consolidates runtime checks into one indexing site, and actually catches a specific unsoundness; result lands as a PR about three years ago and improves maintainability.
AI-written summary · about
chapters (10)
- 0:00Safe versus unsafe Rust
- 1:03Reasons for unsafe code
- 2:06Encapsulating safety invariants
- 3:52PhantomData abstractions
- 5:59Ownership with owning pointers
- 8:04Documenting type invariants
- 10:14MustUse for unsoundness
- 12:00Pointer optimizations
- 13:50Surface complexity to prevent bugs
- 14:56Summary
related talks
19mProduction Unsafe Rust
18mAliasing Limits on Translating C to Safe Rust
30mEnsuring Rust Safety: Strategies for Managing Unsafe Rust
42mThe Edge of Safe Rust
36mBuilding on an unsafe foundation
42mWhat If We Pretended Unsafe Code Was Nice, And Then It Was?
28mDetecting Borrow and Provenance Bugs Across Unsafe Rust [...]
45mBuilding Safe and Secure Systems in Rust