"I started learning Rust in 2015. I've been using it since 2016. I've been a compiler team member since 2017. I've been paid to write Rust code since 2018. I have needed to use `unsafe` <5 times. That's what why Rust's safety guarantees matter despite the existence of `unsafe`."
For me, I was being a bit lazy with loading some config on program startup that would never change, so I used a `static mut` which requires `unsafe` to access. Turns out I was able to figure out a way to pass my data around with an `Arc<T>`. I think either way would have worked, but I figured I should avoid the unsafe approach anyway.
https://github.com/shepmaster/stack-overflow-relay/blob/273a...
[1] https://stackoverflow.com/questions/10529284/is-there-ever-a...
hold_my_beer {
}}
My problem with the word “unsafe” is that many people seem to think unsafe code blocks necessarily have security issues. Hence the bullying of library authors even in cases where the authors did their homework.
Anything about the mechanics of the implementation is a second-order detail compared to that, as far as I’m concerned.
Also, I dislike the word "unsafe" since "unsafe code" is easily (mis)interpreted to mean "invalid/UB code", but "invalid/UB code" is officially called "unsound" rather than "unsafe". Unsafe blocks are used to call unsafe functions etc. (they pass information into unchecked operations via arguments), and unsafe trait impls are used by generic/etc. unsafe code like threading primitives (unsafe trait impls pass information into unchecked operations via return values or side effects).
unchecked would make a good keyword name for blocks calling unchecked operations, but I'm not so sure about using it for functions or traits.
For example, this is UB:
unsafe { std::hint::unreachable_unchecked() };
fn unsound(trigger: bool) {
if trigger { unsafe { std::hint::unreachable_unchecked() }; }
}The real issue here is Rust fans trying to make Rust into a type dependent language while abusing unsafe's original purpose.