> Importantly, there is no language transformation which rewrites one kind of operator (i.e. Equality or Ordering) in terms of a different kind of operator. The columns are strictly separate.
Why do we need a primary == operator if we have strong_ordering::equal, weak_ordering::equivalent, and partial_ordering::equivalent? Couldn't the behavior of == and != be inferred from the <=> definition?
I guess I'm asking why a == b can't be rewritten as (a <=> b) == 0.
> Weak orderings are defined as orders that can't distinguish between all members
I get that. This wasn't my question.
I want to know why I need to define operator== when reasonable behavior can be inferred from whether or not operator<=> returns strong_ordering::equal (or weak_ordering::equivalent -- the standards committee can decide if this is reasonable -- I don't really care). If I want special behavior, then sure, defining operator== might make sense, and then it should obviously take precedence.
But if the whole point of this new three way compare is to reduce the combinatorial explosion of things that you need to define, I don't understand the need to split the universe into {==, !=} and {<=>, <, <=, >, >=}, and never let them interact with each other.
The part I take issue with is the statement "The columns are strictly separate."
Maybe I've missed something, but I don't see why it needs to be like this. operator<=> seems to be a strict superset of operator==, because it returns information about when equality holds, (or when equivalence holds). Shouldn't that be sufficient? Also, what's going to break if you design a type where a.operator==(b) doesn't return true when a.operator<=>(b) returns strong_ordering::equal, or vice-versa?
Again, maybe I've missed something, but this seems like a mistake. They're removing all of the footguns except this last one. Why?
Thank you! This answers my original question. I guess all things considered, it's still not too bad. Two functions is better than 6+, and it looks like they'll be a lot harder to get wrong.
There is an explanation in the article - basically, this is done for performance reasons.
Especially for large types (e.g. collections) in-equality can short-circuit very quickly, whereas comparison may need to see a large part of the collection before being able to return.
The most pathological example is two large arrays of different size, that are element-by-element equal for the first million elements. Equality can return false after seeing the size difference, but <=> needs to reach the millionth-and-1 element before being bale to return a value.
The commission was especially concerned because the two operators would be functionally equivalent - so, it would be difficult to rely on testing to make sure the equality operator is also implemented.
Yeah, I just skimmed through the proposal, and it sounds like the post is wrong, and it works the way I think it should work.
You should get == behavior if you only define a reasonable <=>, and if you also define ==, then that definition will take precedence.
Edit: argh, no, I'm wrong. I was looking at an earlier draft. So you do have to define == as well as <=>, for mostly technical reasons. Fine, I guess that answers my question.
Why do we need a primary == operator if we have strong_ordering::equal, weak_ordering::equivalent, and partial_ordering::equivalent? Couldn't the behavior of == and != be inferred from the <=> definition?
I guess I'm asking why a == b can't be rewritten as (a <=> b) == 0.