I think, the idea was along the lines of "because C++ was not memory-safe, and it has to stay compatible with how it was, there are still a lot of ways to not write memory-safely"

This makes sense, there are memory-safely features available but there are a lot of programmers that will never willingly use that features, because the olden ways are surely better

Other than that, I agree, when you're paid to fix an unfixable problem you will probably claim something like that and advocate for your solution being the only one that solves this

Just because a feature was not rolled out in the mid-90s would that mean that it’s not available today?

Adding a feature is one thing, C++ has added a lot of memory safety features over the years. 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. Removing support for these features will break existing code and piss a lot of people off in the process. It is not about adding new features, but removing the unsafe existing features that they are talking about here.

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

Even highly paid (and probably skilled) devs in the IT industry manage to mess that up pretty regularly. Even if it was: devs using memory safe languages make much fewer mistakes wrt. managing memory... so that tooling does seem to help them at least more than the C++ tooling helps the C++ devs.

I think your take is a bit extreme.

Currently their statement (regardless of the questionable justification) is largely correct, no major c++ projects have been written in a safe subset and no real work has really started yet. It isn’t practical.

I do agree with you that a safe form of c++, once fully implemented and not frustrating to use, could easily become viable, the feature can be added. But that’s still years away from practical usage in large project, and even when done, many projects will stick to the older forms, making the transition slow and frustrating.

The practical result is that he’s sort of right, if you just add the word “currently” to his statement.

Otoh, I do agree with you that rust cannot be the sole answer to this problem either, it’s almost as impractical to rewrite codebases in rust as an as-yet unfinished safe form of C++. Only time and lots of effort can fix this problem

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

it’s theoretically possible to write memory-safe C++

Maybe try to write more humbly and less fanatically, since you don't seem to be that knowledgable about anything (experienced in other threads too).

* It's "theoretically possible" to write memory-safe assembly if we bend contextual meanings enough.

I heavily disagree. C++ has a lot of problems but it's flexibility is not one of them.

Imo the biggest problem with C++ is that there are a dozens ways of doing the same thing. The std lib is not general and fast enough for everyone. Therefore it's not even "standard" .

I have seen many conferences of a proposed "cpp2" like syntax that breaks abi but imo it's the best way forward.

Rust still allows people to do (basically) whatever they want via unsafe blocks.

The goal of this proposal is to advance a superset of C++ with a rigorously safe subset.

The subset is of the proposed syntax superset. Reason being because the superset also contains explicitly unsafe syntax similar to rust.