But the thing is, unsafe was never absolutist.
Even regular safe Rust assumes you use unsafe in a proper manner.
This build tool assumes your C++ code is safe enough to wrap around unsafe trivially.
Even regular safe Rust assumes you use unsafe in a proper manner.
This build tool assumes your C++ code is safe enough to wrap around unsafe trivially.
This build tool, as first proposed, knowingly exposed macros that can cause memory unsafety with the wrong inputs, without making you write unsafe. If a build tool makes assumptions like "you probably know what you're doing with that C++ code" without asking you to write unsafe, it is just as wrong as an implementation of unchecked indexing that wasn't marked unsafe (because "you'll probably know not to use this unless you're really in bounds."). It is clear that you consider this a trivial matter, but many people very heavily involved in the Rust community (including the people working on its soundness proofs) do not.
This was done to deal with remarks Chromium devs had against Rust C++ binding.
In lieu of that it's liberal treatment of unsafe is understandable.
I have a hard time believing those Chromium devs know what they want.
Their request allows safe Rust to introduce undefined behavior, making the unsafe Rust keyword meaningless (since now you can't even grep for the places in the code where this UB is introduced), and eliminating the actual reason they want to use Rust in the first place (to avoid undefined behavior, segfaults, CVEs, etc.).
The only thing complying with the request will achieve is hurt the language. Once the chromium devs start hitting the same CVEs and segfaults in Rust that they were hitting in C++, they will just tell the whole world that Rust is as bad as C++ and using it is not worth it.