Previously, on Lobsters, we had a closely-related conversation. It seems like Erlang is catching up to the paradigm of two equality operators: one which is precise enough to verify identities, and one which is looser and respects IEEE 754.
It looks like I can’t reply to your comment on that earlier post, so let me reply here if you don’t mind.
I like that design!
I wonder if you could get away with using two relations like that as a variation on how Rust handles equality. Right now Rust has four traits:
<, <=, >, >=, ==, !=
As an example, floats implement PartialOrd, and ints implement Ord.
However, this gives more buckets that I think tend to show up in practice. The kinds of relations that actually show up, from what I’ve seen, are (i) Ord, (ii) Eq, and (iii) floats which are nonsense. So it seems excessive that you have to write #[derive(PartialEq, Eq, PartialOrd, Ord)] all the time.
#[derive(PartialEq, Eq, PartialOrd, Ord)]
What I’m wondering now is whether in practice you could get away with just two traits:
<, <=, >, >=, <>, <=>
With the requirement that if something implements both Eq and Ord then it’s a full order, and additionally == and != must coincide with <=> and <>, and you get a warning if you use <=> or <> because it would be more clear to use == or !=.
Though as I’m writing this it’s seeming questionable because it doesn’t cleave things along as clear mathematical boundaries. And the starting point was thinking that if you wrote == you knew you’d be getting reflexive equality and if you wrote <=> you knew you weren’t, but that doesn’t extend to < which could be either a partial or full order.
There are structures that are PartialEq/Eq but aren’t ordered - most obvious example are complex numbers where we can compare them, but not order them.