Indeed, how is grep -r unsafe . supposed to work if there is no unsafe?
1 Like
The point of unsafe is encapsulation. Using it uncontrollably is the only way I can make sense of such a perspective.
Just as importantly, how would #[deny(unsafe_code)] work reliably? Static guarantees are very important.
Perhaps Rust is simply not designed for the use case where a large proportion of the code is unsafe. If so, your complaint for that use case is valid.
About the only case I've seen where unsafe blocks are actually a bit annoying is safely wrapping an FFI library. It's pretty trivial in comparison to the rest of the repetition you get in those cases even there though!
I use RustRover myself, and far prefer unsafe blocks than depending on IDE highlighting, you can't see that in git history etc...
Without exception, every human eventually realizes that all people, even the very best, make mistakes. It’s simply a fact of life that errors are unavoidable.
Does unsafe {} prevent mistakes? Absolutely not.
However, unsafe {} serves an important purpose: It draws attention to areas in the code where potentially dangerous operations occur.
If unsafe is scattered throughout a codebase and it feels painful to work with, then it’s actually doing its job. That pain highlights the need for better, safer abstractions and encourages improvements until the codebase becomes more robust and maintainable.
I'd say this is a little underdefined to be strictly wrong, but it's essentially misleading. unsafe {} is the line that stops you from hitting UB (linker nonsense excepted), so I'd say it pretty clearly is preventing mistakes where someone accidentally uses an unsafe API, a mutable static, etc... - that's kind of the point of Rust!