The "meat" of the paper is not bad — they correctly differentiate between necessary and unnecessary uses, and try to demonstrate that unsafe is not always neces

The "meat" of the paper is not bad — they correctly differentiate between necessary and unnecessary uses, and try to demonstrate that unsafe is not always necessary for performance. However, there is a lot of sloppy wording in this paper. It has many not-quite-accurate descriptions of Rust's semantics, which could make readers misunderstand how unsafe actually works. For example: > Rust still supports pointers but considers dereferences of raw pointers undefined behaviors. Its compiler will raise an error when encountering raw pointer dereferences They probably mean that it's not allowed to dereference raw pointers in safe code, but UB is an entirely different concept. > Rust allows unsafe code […] where the safety restrictions are dropped and low-level controls are granted. As language restrictions no longer work for unsafe Rust blocks […] All restrictions of safe Rust are still enforced in `unsafe{}` blocks. The semantics of references and ownership never change. Unsafe code gains additional abilities to perform operations that could bypass/break safety invariants if written incorrectly, but that's something else than a blanket "safety restrictions are dropped". And the description of `[repr(C)]` and FFI that says they can only use raw pointers is just plain incorrect. C layout doesn't affect safety of types, and FFI can use several C-ABI-compatible safe Rust types.