No, this is a feature created for memory-unsafe languages which has turned out to be yet another memory safety attack vector. But there's no way to prevent this.
And languages which require unsafe blocks to write any real system code.
> But there's no way to prevent this
There isn't. There are only mitigations. The environment is actively hostile.
You can try to bake them in the hardware, which has huge up front design costs, and if a vulnerability is ever found, they become useless instantly.
You can try to bake them into the language, which has moderate continual design costs, but if someone simply types 'unsafe' anywhere in your codebase they become useless instantly.
You can try to enforce them in the frame work of your own code, which has moderate up front design costs, is possibly less reliable than the other methods, but they can be changed and redeployed when vulnerabilities are discovered.
These problems don't go away simply because you made a particular hardware or language choice. You can't sweep this engineering under the rug and then act like your software is more secure than anything else.
> And languages which require unsafe blocks to write any real system code.
The difference you've missed is cultural. Rust's unsafe blocks just denote code which the compiler can't check, which if you have the appropriate culture makes those blocks a focus for human oversight in a way which cannot be sustained in the legacy languages where the whole codebase has the same problem.
Also, there's a lot of security and performance critical code which isn't "real system code" by this weird definition. Whole domains where it's just greed and stupidity versus a correct solution with better performance, and yet the greed and stupidity gets ahead as often as not. Depressing.
Describe how this culture is created and enforced by the language itself. Otherwise if it does actually exist I'd worry it's simply an ephemeral phenomenon that will disappear if the language becomes more common place. You could also expect to be able to develop this culture in any other project in any other language.
Further, in my experience "lack of culture" is not why software engineers make mistakes.
> Whole domains where it's just greed and stupidity versus a correct solution with better performance,
In open source projects? If a better, correct, more performant solution existed, people would use it. If they're not, something else is causing it, and I highly doubt it's because they're just "stupid" or "greedy."
You have the cart in front of the horse. Culture drives language. This is why the WG21 musings, especially those by Bjarne himself are so amusing. Bjarne actually gave a big talk about how he can solve this and the talk includes the C word exactly once, in a quote from someone else explaining the problem which Bjarne promptly dismisses.
> Further, in my experience "lack of culture" is not why software engineers make mistakes
Culture is why the mistakes aren't caught and instead go uncorrected. The language features, the tooling, and larger engineering processes which rely on them are a product of culture.
> If a better, correct, more performant solution existed, people would use it.
This is a really common mistake on HN, the false belief that people will somehow magically know a choice would be better and always make that choice, so therefore all their choices must have been optimal - nothing about our world would suggest this could be the case and yet it's so often relied upon as if it's somehow obvious. And no it's not just stupidity, laziness is also crucial, humans are very lazy.
