TL;DR: std::equality_comparable_with<T, U> requires that both T and U are convertible to the common reference of T and U. For the case of std::unique_ptr<T> and std::nullptr_t, this requires that std::unique_ptr<T> is copy-constructible, which it is not.
Buckle in. This is quite the ride. Consider me nerd-sniped.
Why don't we satisfy the concept?
std::equality_comparable_with requires:
template <class T, class U>
concept equality_comparable_with =
std::equality_comparable<T> &&
std::equality_comparable<U> &&
std::common_reference_with<
const std::remove_reference_t<T>&,
const std::remove_reference_t<U>&> &&
std::equality_comparable<
std::common_reference_t<
const std::remove_reference_t<T>&,
const std::remove_reference_t<U>&>> &&
__WeaklyEqualityComparableWith<T, U>;
That's a mouthful. Breaking apart the concept into its parts, std::equality_comparable_with<std::unique_ptr<int>, std::nullptr_t> fails for std::common_reference_with<const std::unique_ptr<int>&, const std::nullptr_t&>:
<source>:6:20: note: constraints not satisfied
In file included from <source>:1:
/…/concepts:72:13: required for the satisfaction of
'convertible_to<_Tp, typename std::common_reference<_Tp1, _Tp2>::type>'
[with _Tp = const std::unique_ptr<int, std::default_delete<int> >&; _Tp2 = const std::nullptr_t&; _Tp1 = const std::unique_ptr<int, std::default_delete<int> >&]
/…/concepts:72:30: note: the expression 'is_convertible_v<_From, _To>
[with _From = const std::unique_ptr<int, std::default_delete<int> >&; _To = std::unique_ptr<int, std::default_delete<int> >]' evaluated to 'false'
72 | concept convertible_to = is_convertible_v<_From, _To>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
(edited for legibility) Compiler Explorer link.
std::common_reference_with requires:
template < class T, class U >
concept common_reference_with =
std::same_as<std::common_reference_t<T, U>, std::common_reference_t<U, T>> &&
std::convertible_to<T, std::common_reference_t<T, U>> &&
std::convertible_to<U, std::common_reference_t<T, U>>;
std::common_reference_t<const std::unique_ptr<int>&, const std::nullptr_t&> is std::unique_ptr<int> (see compiler explorer link).
Putting this together, there is a transitive requirement that std::convertible_to<const std::unique_ptr<int>&, std::unique_ptr<int>>, which is equivalent to requiring that std::unique_ptr<int> is copy-constructible.
Why is the std::common_reference_t not a reference?
Why is std::common_reference_t<const std::unique_ptr<T>&, const std::nullptr_t&> = std::unique_ptr<T> instead of const std::unique_ptr<T>&? The documentation for std::common_reference_t for two types (sizeof...(T) is two) says:
- If
T1 and T2 are both reference types, and the simple common reference type S of T1 and T2 (as defined below) exists, then the
member type type names S;
- Otherwise, if
std::basic_common_reference<std::remove_cvref_t<T1>, std::remove_cvref_t<T2>, T1Q, T2Q>::type exists, where TiQ is a unary
alias template such that TiQ<U> is U with the addition of Ti's cv- and
reference qualifiers, then the member type type names that type;
- Otherwise, if
decltype(false? val<T1>() : val<T2>()), where val is a function template template<class T> T val();, is a valid type, then
the member type type names that type;
- Otherwise, if
std::common_type_t<T1, T2> is a valid type, then the member type type names that type;
- Otherwise, there is no member type.
const std::unique_ptr<T>& and const std::nullptr_t& don't have a simple common reference type, since the references are not immediately convertible to a common base type (i.e. false ? crefUPtr : crefNullptrT is ill-formed). There is no std::basic_common_reference specialization for std::unique_ptr<T>. The third option also fails, but we trigger std::common_type_t<const std::unique_ptr<T>&, const std::nullptr_t&>.
For std::common_type, std::common_type<const std::unique_ptr<T>&, const std::nullptr_t&> = std::common_type<std::unique_ptr<T>, std::nullptr_t>, because:
If applying std::decay to at least one of T1 and T2 produces a
different type, the member type names the same type as
std::common_type<std::decay<T1>::type, std::decay<T2>::type>::type, if
it exists; if not, there is no member type.
std::common_type<std::unique_ptr<T>, std::nullptr_t> does in fact exist; it is std::unique_ptr<T>. This is why the reference gets stripped.
Can we fix the standard to support cases like this?
This has turned into P2404, which proposes changes to std::equality_comparable_with, std::totally_ordered_with, and std::three_way_comparable_with to support move-only types.
Why do we even have these common-reference requirements?
In Does `equality_comparable_with` need to require `common_reference`?, the justification given by T.C. (originally sourced from n3351 pages 15-16) for the common-reference requirements on equality_comparable_with is:
[W]hat 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).
Just requiring the == operations that might naively be expected of the concept doesn't work, because:
[I]t allows having t == u and t2 == u but t != t2
So the common-reference requirements are there for mathematical soundness, simultaneously allowing for a possible implementation of:
using common_ref_t = std::common_reference_t<const Lhs&, const Rhs&>;
common_ref_t lhs = lhs_;
common_ref_t rhs = rhs_;
return lhs == rhs;
With the C++0X concepts that n3351 supported, this implementation would actually be used as a fallback if there was no heterogeneous operator==(T, U).
With C++20 concepts, we require a heterogeneous operator==(T, U) to exist, so this implementation will never be used.
Note that n3351 expresses that this kind of heterogeneous equality is already an extension of equality, which is only rigorously mathematically defined within a single type. Indeed, when we write heterogeneous equality operations, we are pretending that the two types share a common super-type, with the operation happening inside that common type.
Can the common-reference requirements support this case?
Perhaps the common-reference requirements for std::equality_comparable are too strict. Importantly, the mathematical requirement is only that there exists a common supertype in which this lifted operator== is an equality, but what the common reference requirements require is something stricter, additionally requiring:
- The common supertype must be the one acquired through
std::common_reference_t.
- We must be able to form a common supertype reference to both types.
Relaxing the first point is basically just providing an explicit customization point for std::equality_comparable_with in which you could explicitly opt-in a pair of types to meet the concept. For the second point, mathematically, a "reference" is meaningless. As such, this second point can also be relaxed to allow the common supertype to be implicitly convertible from both types.
Can we relax the common-reference requirements to more closely follow the intended common-supertype requirements?
This is tricky to get right. Importantly, we actually only care that the common supertype exists, but we never actually need to use it in the code. As such, we do not need to worry about efficiency or even whether the implementation would be impossible when codifying a common supertype conversion.
This can be accomplished by changing the std::common_reference_with part of equality_comparable_with:
template <class T, class U>
concept equality_comparable_with =
__WeaklyEqualityComparableWith<T, U> &&
std::equality_comparable<T> &&
std::equality_comparable<U> &&
std::equality_comparable<
std::common_reference_t<
const std::remove_reference_t<T>&,
const std::remove_reference_t<U>&>> &&
__CommonSupertypeWith<T, U>;
template <class T, class U>
concept __CommonSupertypeWith =
std::same_as<
std::common_reference_t<
const std::remove_cvref_t<T>&,
const std::remove_cvref_t<U>&>,
std::common_reference_t<
const std::remove_cvref_t<U>&,
const std::remove_cvref_t<T>&>> &&
(std::convertible_to<const std::remove_cvref_t<T>&,
std::common_reference_t<
const std::remove_cvref_t<T>&,
const std::remove_cvref_t<U>&>> ||
std::convertible_to<std::remove_cvref_t<T>&&,
std::common_reference_t<
const std::remove_cvref_t<T>&,
const std::remove_cvref_t<U>&>>) &&
(std::convertible_to<const std::remove_cvref_t<U>&,
std::common_reference_t<
const std::remove_cvref_t<T>&,
const std::remove_cvref_t<U>&>> ||
std::convertible_to<std::remove_cvref_t<U>&&,
std::common_reference_t<
const std::remove_cvref_t<T>&,
const std::remove_cvref_t<U>&>>);
In particular, the change is changing common_reference_with to this hypothetical __CommonSupertypeWith where __CommonSupertypeWith differs by allowing for std::common_reference_t<T, U> to produce a reference-stripped version of T or U and also by trying both C(T&&) and C(const T&) to create the common reference. For more details, see P2404.
How do I work around std::equality_comparable_with before this gets merged into the standard?
Change which overload you use
For all of the uses of std::equality_comparable_with (or any of the other *_with concepts) in the standard library, there is helpfully a predicate overload which you can pass a function to. That means that you can just pass std::equal_to() to the predicate overload and get the desired behavior (not std::ranges::equal_to, which is constrained, but the unconstrained std::equal_to).
This doesn't mean that it would be a good idea to not fix std::equality_comparable_with, however.
Can I extend my own types to meet std::equality_comparable_with?
The common-reference requirements use std::common_reference_t, which has a customization point of std::basic_common_reference, for the purpose of:
The class template basic_common_reference is a customization point that allows users to influence the result of common_reference for user-defined types (typically proxy references).
It is a horrible hack, but if we write a proxy reference that supports both types we want to compare, we can specialize std::basic_common_reference for our types, enabling our types to meet std::equality_comparable_with. See also How can I tell the compiler that MyCustomType is equality_comparable_with SomeOtherType? . If you choose to do this, beware; std::common_reference_t is not only used by std::equality_comparable_with or the other comparison_relation_with concepts, you risk causing cascading problems down the road. It is best if you ensure that the common reference is actually a common reference, e.g.:
template <typename T>
class custom_vector { ... };
template <typename T>
class custom_vector_ref { ... };
custom_vector_ref<T> could be a good option for a common reference between custom_vector<T> and custom_vector_ref<T>, or possibly even between custom_vector<T> and std::array<T, N>. Tread carefully.
How can I extend types I don't control std::equality_comparable_with?
You can't. Specializing std::basic_common_reference for types you don't own (either std:: types or some third-party library) is at best bad practice and at worst undefined behavior. The safest choice would be to use a proxy type you own that you can compare through or else write your own extension of std::equality_comparable_with that has an explicit customization point for your custom spelling of equality.
Okay, I get that the idea of these requirements is mathematical soundness, but how do these requirements acheive mathematical soundness, and why is it so important?
Mathematically, equality is an equivalence relation. However, equivalence relations are defined over a single set. So how can we define an equivalence relation between two sets A and B? Simply put, we instead define the equivalence relation over C = A∪B. That is to say, we take a common supertype of A and B and define the equivalence relation over this supertype.
This means that our relation c1 == c2 must be defined no matter where c1 and c2 come from, so we must have a1 == a2, a == b, and b1 == b2 (where ai is from A and bi is from B). Translating to C++, this means that all of operator==(A, A), operator==(A, B), operator==(B, B), and operator==(C, C) must be part of the same equality.
This is why iterator/sentinels do not meet std::equality_comparable_with: while operator==(iterator, sentinel) may actually be part of some equivalence relation, it is not part of the same equivalence relation as operator==(iterator, iterator) (otherwise iterator equality would only answer the question of "Are either both iterators at the end or both iterators not at the end?").
It is actually quite easy to write an operator== that is not actually equality, because you must remember that the heterogeneous equality is not the single operator==(A, B) you are writing, but is instead four different operator==s that must all be coheisve.
Wait a minute, why do we need all four operator==s; why can't we just have operator==(C, C) and operator==(A, B) for optimization purposes?
This is a valid model, and we could do this. However, C++ is not a platonic reality. Although concepts try their hardest to only accept types that truly meet the semantic requirements, it cannot actually acheive this goal. As such, if we were to only check operator==(A, B) and operator==(C, C), we run the risk that operator==(A, A) and operator==(B, B) do something different. Besides, if we can have operator==(C, C), then this means that it is trivial to write operator==(A, A) and operator==(B, B) based on what we have in operator==(C, C). That is to say, the harm of requiring operator==(A, A) and operator==(B, B) is quite low, and in return we get a higher confidence that we actually have an equality.
There are some circumstances where this runs into rough edges, however; see P2405.
How exhausting. Can't we just require that operator==(A, B) is an actual equality? I'm never going to actually use the operator==(A, A) or operator==(B, B) anyway; I only cared about being able to do the cross-type comparison.
Actually, a model where we require operator==(A, B) is an actual equality would probably work. Under this model, we would have std::equality_comparable_with<iterator, sentinel>, but what precisely that means in all known contexts could be hammered out. However, there was a reason why this is not the direction the standard went with, and before one can understand if or how to change it, they must first understand why the standard's model was chosen.
