Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Rust's std::arch is mostly SIMD intrinsics, and its whole public API is marked `unsafe` because it's a low-level library that doesn't automatically check if the CPU supports a given SIMD instruction before calling it (and if not supported it will simply crash; it's not a memory safety problem). Regular programmers should rarely use std::arch directly - you'll almost always rely on auto-vectorisation for SIMD, and if not then use something higher-level like std::simd or the `wide` crate, which provide a safe API (based on compile-time flags stating what instructions the target CPU supports; preventing installation on an unsupported CPU is outside Rust's scope). If you really want to use std::arch, you'll have to call it in `unsafe {...}` blocks, which are a big sign that it needs careful code review.

C++'s std::string_view is designed to be used directly by regular programmers. It's basically a `struct { const char *s; size_t len; }` and its purpose is to replace std::string in situations where you don't want to memcpy the string, for performance. Unlike Rust's `unsafe` APIs, it doesn't do anything to make itself look unusually scary or dangerous. Yet it invites subtle memory safety bugs in trivial cases like:

std::string s = "Undefined";
std::string_view sv = s + "behaviour\n";
std::cout << sv;

(which creates a view of a temporary string, then destroys the temporary, then prints it).

I don't think those are even slightly equivalent situations.

>Ok, so a standard library in rust implemented 7455 unsafe functions in the last 2.9 years.

And that's actually a good thing. It improves memory safety.

The majority of unsafe interfaces are eventually wrapped in safe interfaces.
That is how Rust works.
The programmer almost never comes in contact with unsafe interfaces. Even on embedded systems it's really rare to have unsafe blocks.
And that is *because* all these unsafe blocks exist in core, std or other special wrapper crates that take care of providing a safe interface.
It's just that if you *don't* have such a safe wrapper with unsafe internals in std/core or somewhere else, then you have to make your own. That is the risky and hard part.

Writing unsafe code in Rust is hard. It is much harder than writing C or C++ code.
Because you must take care of all the checks and things you know from C/C++ and in addition to that you have to ensure that the safe interface to your code can never trigger UB.
Therefore, it's a good thing to have this hard to write code in central places like core/std. The more unsafe code there is in core/std, the less unsafe code there is in the applications.