Does `equality_­comparable_with` need to require `common_reference`?

Question

The concept equality_­comparable_with<T, U> is intended to declare that objects of type T and U can be compared equal to each other, and if they are, then this has the expected meaning. That's fine.

However, this concept also requires common_reference_t<T&, U&> to exist. The primary impetus for common_reference and its attendant functionality seems to be to enable proxy iterators, to have a place to represent the relationship between reference and value_type for such iterators.

That's great, but... what does that have to do with testing if a T and a U can be compared equal to one another? Why does the standard require that T and U have a common reference relationship just to allow you to compare them equal?

This creates oddball situations where it's very difficult to have two types which don't reasonably have a common-reference relationship that are logically comparable. For example, vector<int> and pmr::vector<int> logically ought to be comparable. But they can't be because there's no reasonable common-reference between the two otherwise unrelated types.

Answer 1

This goes all the way back to the Palo Alto report, §3.3 and D.2.

For the cross-type concepts to be mathematically sound, you need to define what the cross-type comparison means. For equality_comparable_with, t == u generally means that t and u are equal, but what does it even mean for two values of different types to be equal? The design says that cross-type equality is defined by mapping them to the common (reference) type (this conversion is required to preserve the value).

Where the strong axioms of equality_comparable_with is not desirable, the standard uses the exposition-only concept weakly-equality-comparable-with, and that concept doesn't require a common reference. It is, however, a "semantic abomination" (in the words of Casey Carter) and is exposition-only for that reason: it allows having t == u and t2 == u but t != t2 (this is actually necessary for sentinels).