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.
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
Now, imagine we had some sort of
T: Eq<U> trait. What would it’s additional requirement over
T: PartialEq<U> be when
U are distinct types? It cannot be
x == x, because x cannot be both of type
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?
PartialEq in isolation,
Eq with different left-hand-side and right-hand-side types is not very useful. On the other hand, since
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.