While I agree with Stroustrup that there's a rush to get memory safety bolted onto C++, it's pretty obvious he doesn't understand what good design actually is:

While I agree with Stroustrup that there's a rush to get memory safety bolted onto C++, it's pretty obvious he doesn't understand what good design actually is: > I envision compiler options and code annotations for requesting rules to be enforced. The most obvious would be to request guaranteed full type-and-resource safety. You'd think someone that worked on a compiler for decades would come to the realisation that opt-in safety is just dumb. You want everything to be safe by default, despite the performance implications, and then allow programmers to peel back safety features explicitly where they are not needed. You don't buy a gun and the safety lock as an add-on. Borrowing from Donald Norman and his Design of Everyday Things book, safe programming in C and C++ relies too much on "knowledge in the head" instead of "knowledge in the world" in order to do it correctly. You don't need the big borrow-checker hammer from Rust to be a lot better. Most CVEs (memory safety related) are about out-of-bounds writes/reads. You could mitigate a huge chunk of those problems by just doing something as sensible as having a well defined concept of slices with bounds checking turned on by default. But this seems to elude the C and the C++ committee for some weird reason.