Any improvements to C++'s safety are welcome, because there are huge and important existing C++ code bases.
Using C++ for a greenfield project today should require some very good justification though.
Using C++ for a greenfield project today should require some very good justification though.
Having to maintain legacy C++ applications is all the justification you need to have to understand that staring greenfield projects in C++ is quite frequently and by far the best option on the table
It makes absolutely no sense at all to multiply the tech stacks that a team needs to work on, let alone master, just because naive platitudes have been said about any novel tech stack. You do not make any application better or more secure if you get clueless developers onboarding onto new technologies and forcing them to maintain N+1 code bases and 2*n bindings.
This irrational dislike of C++ ignores the fact that adopting the latest C++ release and toggling static code analysis in your project, which nowadays comes for free, already gets any project way ahead of where naive retractors believe C++ is.
Except that security must be on by default, and it must be made hard (or shameful) to circumvent it. We all know any kind of protection is easy to bypass in C++.
I remember an article from a Julia developer quitting over the culture of using unsafe code that had installed in the community.
A mindset change is required by this profession. Too often (unverified) performance reasons have been used to justify risky code.
I'm not against improvements to C++ safety, I just think making C++ a safe language has provably failed.