It's interesting to compare these opinions with those of the Google Security team that were released a little over a week ago [1].
Key quotes from the Google paper:
> We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety.
> In our experience, it is not sufficient to merely make safe abstractions available to developers on an optional basis (e.g. suggested by a style guide) as too many unsafe constructs, and hence too much risk of bugs, tend to remain. Rather, to achieve a high degree of assurance that a codebase is free of vulnerabilities, we have found it necessary to adopt a model where unsafe constructs are used only by exception, enforced by the compiler.
It seems like Herb Sutter at least partially agrees with the second point in his TL;DR:
> I just want C++ to let me enforce our already-well-known safety rules and best practices by default, and make me opt out explicitly if that’s what I want.
[1]: https://security.googleblog.com/2024/03/secure-by-design-goo...
Key quotes from the Google paper:
> We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety.
> In our experience, it is not sufficient to merely make safe abstractions available to developers on an optional basis (e.g. suggested by a style guide) as too many unsafe constructs, and hence too much risk of bugs, tend to remain. Rather, to achieve a high degree of assurance that a codebase is free of vulnerabilities, we have found it necessary to adopt a model where unsafe constructs are used only by exception, enforced by the compiler.
It seems like Herb Sutter at least partially agrees with the second point in his TL;DR:
> I just want C++ to let me enforce our already-well-known safety rules and best practices by default, and make me opt out explicitly if that’s what I want.
[1]: https://security.googleblog.com/2024/03/secure-by-design-goo...