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:

• PartialEq for equality that is symmetric and transitive but not necessarily reflexive, with operations written ==, !=
• Eq (extends PartialEq) for things that are PartialEq and also reflexive
• PartialOrd (extends PartialEq) for partial orders, with operations written <, <=, >, >=, ==, !=. (If you write == for something that implements both PartialEq and PartialOrd, I’m not sure which is called, but they’re required by spec to behave the same.)
• Ord (extends Eq + PartialOrd) for full orders

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.

What I’m wondering now is whether in practice you could get away with just two traits:

• Ord for partial orders, with operations written <, <=, >, >=, <>, <=>. Floats implement this.
• Eq for symmetric, transitive, reflexive equality, with operations written “==” and “!=”.

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.