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.
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.