I feel like you are being a bit unfair to Bjarne to to my knowledge isn't so much saying "we didn't make mistakes" as much as "we didn't make mistakes we should fix".
C++ is the juggernaut it is because it just works. Your antient C++ codebase doesn't need many changes to get up to date on a language level.
That doesn't mean it is painless to update toolchains but it does mean that the language isn't making that pain worse.
As part of maintaining this the bar for breaking old code isn't "we shouldn't have done that" or "we wouldn't have don't that" but something more like "almost all code using this is wrong anyway".
Most critiques of C++ do not raise to that level and so aren't fundamentally needing to be fixed.
Bjarne is quite happy to admit that we made mistakes, but that wasn't my criticism was it? I'm saying that Bjarne doesn't like to admit that Bjarne made mistakes.
You can't be vague and make your point here. I explained a category of "mistakes" and you simply repeated your point.
To be clear my point wasn't about who made the mistake but that some categories of mistake aren't fixable. Oftentimes people conflate "don't change it" with "it wasn't a mistake".
Found an "I made a mistake" that is very explicitly self owned. Finding counterfactuals is nearly impossible so going to leave it at that without more specificity.
> Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. With generic programming, the x.f(y) vs. f(x,y) distinction becomes a library design and usage issue (an inflexibility). With concepts, such problems get formalized. Again, the issues and solutions go back decades. Allowing virtual arguments for f(x,y,z) gives us multimethods.
Yes, Bjarne wants Unified Function Call Syntax, he has wanted UFCS since at least the 1990s, years prior to C++ 98 but was not able to get WG21 to standardize it, not least because there are a bunch of tricky questions you need to answer to add UFCS and Bjarne's answers are... not the ones everybody else prefers.
The paragraph you're citing is from C++ proposal P1962, in 2019 - it's Bjarne basically arguing, as usual, that he should get his way and blaming the committee for the resulting problems. In that section Bjarne says that OK, he has just spent an entire paper telling people that they shouldn't have the certainty they do, but why defer to him, surely he can be wrong too? This is the sole example from that text where he admits to any mistake, over 25 years ago, and he blames everybody else for the mistake anyway saying it was "fashionable" to do this even though he pointed out the problems.
We should distinguish between problems which actually aren't fixable and problems which it was decided not to fix, I don't see a lot of the former in C++, but I do see a lot of the latter. And decisions can be changed.
C++ is the juggernaut it is because it just works. Your antient C++ codebase doesn't need many changes to get up to date on a language level.
That doesn't mean it is painless to update toolchains but it does mean that the language isn't making that pain worse.
As part of maintaining this the bar for breaking old code isn't "we shouldn't have done that" or "we wouldn't have don't that" but something more like "almost all code using this is wrong anyway".
Most critiques of C++ do not raise to that level and so aren't fundamentally needing to be fixed.