You could argue that the latter is the core drive to evolve the standard.

Most languages deal with this by limiting the features they have - but not C++! (or Scala, which is like Java's C++)

You should always do extensive testing before upgrading.

Yes, you can fix issues like this with a "hard fork" if you have a large enough consensus, but at that point, does the system of having smart contracts actually improve anything over the one where the software is downstream rather than the source of truth, or are you just replacing one form of "human intervention required" with a different but worse one?

> In C++, when you write an expression like a == b, the compiler chooses among available operator== implementations by comparing their match quality. A member function like a.operator==(b) usually has higher priority than a non-member function like operator==(a, b) — unless the types differ too much or are ambiguous.

This is the largest foot-bazooka ever. The point of operator overloading is that the operator in a given expression look natural, feel natural, and behave naturally (= function intuitively). If you have multiple possible operators that could apply, for the same syntax, then you're in a worse position than you originally were -- where an operator either did one particular thing, or didn't apply at all. What operator overloading does in practice is introduce ambiguity. Which is self-defeating. You are better off with C-style, named, non-overloaded functions.

You will never find this crap in actual math. "match quality" my ass.

Other than that, simply not specifying any license would be equivalent.

https://stackoverflow.com/questions/68332228/spdx-license-id...

The better question, in my opinion, is how many other known defects are just sitting there in the GNU buganizer with good reports for more than a decade.

Historically C++ only had these separate comparison operators, and operator overloading, and so if you want ordering you'd be expected to override all of the operators and do so in a consistent way. Turns out it's easy enough to get that wrong and if you do now your C++ program is often nonsense, it has no defined meaning whatsoever. For example if a < b && b < a then too bad now many built-in library functions might do absolutely anything in say C++ 17.

With the spaceship operator you're still screwed if your type provides an incoherent ordering (unlike Rust where that just means the type is less useful) but it's much more likely you'll write something which actually works.

There are times that doesn’t work, so documentation usually has a footnote that (1) certain algorithms require a partial ordering and not necessarily a total ordering, and (2) to use those algorithms, you must implement less-than, but any other comparison operator is ignored by the algorithm; instead, less-than is used to figure out greater-than and equal-to as needed. This was considered better than requiring programmers to implement a collection of comparison operators, and trusting those programmers to make those operators act consistently with each other (e.g., never say that “a” and “b” are both less-than and greater-than each other).

The spaceship operator seems to address this specific case ( https://open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0... ). According to Herb Sutter (note that his name is on the proposal), “We added the C++20 spaceship operator to the language, but we also applied it throughout the C++ standard library and that made the library specification nearly 20 pages shorter — a net reduction” ( https://herbsutter.com/2020/12/ ).

The only one that needs to compile Solidity is the person who wrote the Solidity, right? Same with non-blockchain software. So a bug in a Solidity compiler will have the same impact as a bug in any other compiler. At least with regard to executing untrusted code.

As for deprecating old C++, yes, I can see the appeal, but no, the community hasn't gone that route. C++ has always been a 'mix and match' approach, with different parts of the community using more or less of the language features, with the intention being that you can choose what to adopt when, and move older code bases forward (or not!) depending on individual concerns.

It's one of the C++ strengths, although it doesn't always feel like it.

No one needs a python 2 to 3 moment. It was not a moment, it was a painful decade or so.

There might be a better way to handle changes in C++, but being like Python is not a good way to go.