C++20 doesn't stop someone writing new/delete/malloc/free, or using pointer arithmetic. For me to be sure your code is 'safe', I'd have to audit it visually, a

C++20 doesn't stop someone writing new/delete/malloc/free, or using pointer arithmetic. For me to be sure your code is 'safe', I'd have to audit it visually, and that's the worst of all worlds. The rigor can be put in the tooling, at the compiler level, as a flag. Then there's no 'forcing', it's just not possible to do certain things. Which is what is being advocated. Hoisting it a level further, to the build system, means downstream dependencies can (also) be compiled 'safely', or required to be safe, by default. Sticking a [[safe]] attribute into the language for regular source files would be a disaster. What's the point of one safe function in a library when the rest of it isn't safe? Having said all that, I don't disagree with anything you've written regarding idiomatic c++20 reducing safety issues, it's just that it's a problem that can be and should be addressed mechanically in the tooling. I'm just really, really, doubtful that C++ will ever get anywhere near 'safe' in the next decade, or, really, next couple of decades.