The only (arguably*) baseless claim in that quote is this part:

You do understand you’re making that claim on the post discussing the proposal of Safe C++ ?

And to underline the absurdity of your claim, would you argue that it’s impossible to write a"hello, world" program in C++ that’s not memory-safe? From that point onward, what would it take to make it violate any memory constraints? Are those things avoidable? Think about it for a second before saying nonsense about impossibilities.

If you could reliably write memory safe code in C++, why do devs put memory safety issues intontheir code bases then?

That’s a question you can ask to the guys promoting the adoption of languages marketed based on memory safety arguments. I mean, even Rust has a fair share of CVEs whose root cause is unsafe memory management.

The problem with C++ is it still allows a lot of unsafe ways of working with memory that previous projects used and people still use now.

Why do you think this is a problem? We have a tool that gives everyone the freedom to manage resources the way it suits their own needs. It even went as far as explicitly supporting garbage collectors right up to C++23. Some frameworks adopted and enforced their own memory management systems, such as Qt.

Tell me, exactly why do you think this is a problem?

From the article.

Josh Aas, co-founder and executive director of the Internet Security Research Group (ISRG), which oversees a memory safety initiative called Prossimo, last year told The Register that while it’s theoretically possible to write memory-safe C++, that’s not happening in real-world scenarios because C++ was not designed from the ground up for memory safety.

That baseless claim doesn’t pass the smell check. Just because a feature was not rolled out in the mid-90s would that mean that it’s not available today? Utter nonsense.

If your paycheck is highly dependent on pushing a specific tool, of course you have a vested interest in diving head-first in a denial pool.

But cargo cult mentality is here to stay.

That’s perfectly fine. It’s a standardization process. Its goal is to set in stone a specification that everyone agrees to. Everything needs to line up.

In the meantime, some compiler vendors provide their own contracts support. If you feel this is a mandatory feature, nothing prevents you from using vendor-specific implementations. For example, GCC has support for contracts since at least 2022, and it’s mostly in line with the stuff discussed in the standardization meetings.

Still no contracts?

In line with the release process for C++ standard specifications, where standards ship every 3 years but alternate between accepting new features and feature freeze releases, C++23 was the last release that was open to new features. This would mean C++26 is a feature freeze release following the new features introduced in C++23.

named arguments

Is this supposed to be a critical feature?

The most asinine thing i encountered is that the bracket operator on std::map writes 0 value if the key is not found.

That’s a “you’re using it wrong” problem. The operator[] is designed to "Returns a reference to the value that is mapped to a key equivalent to key, performing an insertion if such key does not already exist. "

The “0 value” just so happens to be the result you get from a default initializer whose default initialization corresponds to zero-initialization.

If you want to use a std::map to access the element associated with a key, you need to either use at and handle an exception if no such key exists, or use find.

Should focus on getting rid of undefined behavior.

What problem do you believe is presented by undefined behavior?