I believe this real-life, 4-year, 1.5 million-line-of-code experiment disagrees with you directly [1]
> In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety.
[1] https://security.googleblog.com/2022/12/memory-safe-language...
unsafe fn create_null_pointer() -> *const u32 {
std::ptr::null()
}
fn main() {
let ptr = unsafe { create_null_pointer() };
// Dereferencing the null pointer outside of unsafe code
let value = unsafe { *ptr };
println!("Value: {}", value);
}
What this article is getting at is that the unsafe keyword highlights pieces of code that Google scrutinizes, not that it has functionality that "magically" encapsulates memory bugs. And yes, it's a lot better than C++. But you still need to be aware this can happen and not assume you're safe
All unsafe does is shut off the compiler for sections of the code. You can write code in an unsafe block that bubbles outside of the scope of "unsafe."*
> "you'd be surprised how many Rust engineers think unsafe somehow 'encapsulates' memory bugs inside the block itself,"
you essentially mean:
> "you'd be surprised how many Rust engineers think that they can use unsafe without regard as to whether they are maintaining Rust's safety invariants by hand in their unsafe blocks."
Yes, I do find that surprising!