I can’t tell you about history, but I can throw in my 2 cents on why this restriction may or may not be sensible.
First note that in mathematical terms, the terminology “total order” or “partial order” both only are used to describe binary relations on a single set, i.e. always corresponding to the situation where the left-hand-side and right-hand-side types are the same. So that terminology is irrelevant for discussing this question.
If Eq
is interpreted as a notion of “mathematical equality” (not just an “equivalence relation”), then a “partial order” corresponds to T: Eq + PartialOrd
, and a “total order” corresponds to T: Ord
. That’s a lot of conditions to get a good correspondence, and PartialEq
is completely out of the equation nonetheless, so let’s not focus too much on mathematical terminology.
In terms of actual documented requirements, the only thing that differentiates T: Eq
from T: PartialEq<T>
is the additional requirement that x == x
should be true for all x
.
Now, imagine we had some sort of T: Eq<U>
trait. What would it’s additional requirement over T: PartialEq<U>
be when T
and U
are distinct types? It cannot be x == x
, because x cannot be both of type T
and U
at the same time. The only option I can think of would be to have no additional requirements at all. Possibly that seemed to use-less of an approach, so it wasn’t followed?
For Eq
and PartialEq
in isolation, Eq
with different left-hand-side and right-hand-side types is not very useful. On the other hand, since Ord
requires Eq
, restricting Eq
to operate on a single type transfers to Ord
as well. And for Ord
, there is an additional requirement that still makes sense even when the types are different, i.e. that partial_cmp
never fails.
So I conclude that there might indeed be some sense in the idea of generalizing Eq
to have a Rhs parameter, too. One reasonable extra requirement for Eq
itself over PartialEq
that I just thought of could probably be that T: Eq<U>
implementations are expected to only exist when T: Eq<T>
and U: Eq<U>
implementations exist as well. Similarly for Ord
, I guess… I’m not a big fan of these “such and such implementations must exist” requirement in the first place, because it’s unclear (to me) how exactly they should be upheld, but that’s a separate discussion.
In case the question is whether the extra Rhs
parameter could be added to Eq
now, i.e. whether that’s a breaking change, on first thought, I would say … probably not breaking!? … unless I’m missing something.