No, it's not. There is no set of guidelines that exists today that creates a memory safe subset of C++. If you claim to have one, and it have a way of verifying that a program satisfies those guidelines, I'll find you a program that has unsafe behavior.
That is your opinion, many folks at ISO C++ see it differently.
Hence why the ongoing efforts to improve static analysis tooling in regards to mechanical enforcement of C++ Core Guidelines across all major C++ compilers, IDEs and commercial static analysers.
It is perfect? Don't let perfect be the enemy of good.
In any case, anyone that cares about secure code shouldn't be touching any language that is copy-paste compatible with C, unless they can't avoid it.
I think you fundamentally misunderstand what memory safety means. "Kinda sorta better" is not memory safety. It's when you can pick out a safe subset of the language and guarantee, barring errors in the language implementation itself, that certain kinds of errors are not possible. C++ cannot do this today and implementations I have seen for C have required semi-invasive changes to the language itself.
I think you fundamentally misunderstand how static analysers and check-in hooks can be used to force everyone to play by the rules, assuming management plays ball with SecDevOps best practices.
As for the rest, I was quite clear where I stand on my last sentence.
I don't get it. You responded to a post that talks about a memory safe subset of C++ by mentioning the Core Guidelines. You are aware of what memory safety is and how this doesn't actually solve that problem (I know you are, you've been around here long enough). Then why bring it up? The answer to "is there a memory safe subset of C++" is "no". The answer to "should you write security critical software in C++" is "generally no because there is no memory safe subset of C++". The Core Guidelines is a good way to not run into the trivial pitfalls but it's not an answer. Why are you presenting it like one?
