As pointed out in several answers and comments, the
meters == seconds case is not relevant to the title question.
So, let's focus on the title question, which stands on its own:
Is simplifying overloading always a good thing?
It was commented elsewhere that one of the arguments is convenience.
Because it can cut down on a lot of boilerplate
However, I would say that convenience is second to correctness.
When a programmer is forced to overload each of the pre-C++20 ordered comparison operators, there is a possibility that either a typo or a thinko (a misthought) could lead to an inconsistent implementation.
As an example, early in my career I once implemented a strict weak ordering operator by calling
std::greater_equal, thinking that it was the natural choice since it was the logical negation of
Here's an experiment. Try store a few instances of this object in any C++ ordered container. Alternatively, store them in a
std::vector, and then call
std::sort. Compile and run.
Infinite loop, exception, uncaught exception, or
(Remark) The latter cases are possible in debug mode. In release mode, anything could happen, with infinite loop being most likely. Truly undefined behavior other than infinite loop only happens if the container is tree-based due to tree node management failure.
The contract for
std::sort or for the order maintenance algorithms in C++ containers depend on these comparison operators being consistent at all times. For example, a strict weak ordering must be strict at all times. Note A failure to do so not only causes unspecified behavior; they actually lead to worse things such as potential infinite loops. Because algorithm implementations take advantage of the assumption that user-defined comparison operators need to be consistent, that inconsistency isn't tolerated at all. Preventing the worse outcome from noncompliant implementation imposes a runtime cost on all software, which annoys experienced programmers because experienced programmers don't make this kind of mistakes.
(A @ B) and
(B @ A) cannot be both true, when
@ is a strict weak ordering.
This is my experience many years ago. Things may have changed; new algorithm implementations might have better built-in defense against noncompliant / inconsistent comparison operator overloads. But why take the risk?