std::EqualityComparable,std::EqualityComparableWith (3) - Linux Manuals

std::EqualityComparable,std::EqualityComparableWith: std::EqualityComparable,std::EqualityComparableWith

NAME

std::EqualityComparable,std::EqualityComparableWith - std::EqualityComparable,std::EqualityComparableWith

Synopsis

Defined in header <concepts>
template <class T, class U>
concept __WeaklyEqualityComparableWith = // exposition only
requires(const std::remove_reference_t<T>& t,
const std::remove_reference_t<U>& u) {
t == u; requires std::Boolean<decltype(t == u)>; (1)
t != u; requires std::Boolean<decltype(t != u)>;
u == t; requires std::Boolean<decltype(u == t)>;
u != t; requires std::Boolean<decltype(u != t)>;
};
template < class T > (2) (since C++20)
concept EqualityComparable = __WeaklyEqualityComparableWith<T, T>;
template <class T, class U>
concept EqualityComparableWith =
std::EqualityComparable<T> &&
std::EqualityComparable<U> &&
std::CommonReference<
const std::remove_reference_t<T>&, (3) (since C++20)
const std::remove_reference_t<U>&> &&
std::EqualityComparable<
std::common_reference_t<
const std::remove_reference_t<T>&,
const std::remove_reference_t<U>&>> &&
__WeaklyEqualityComparableWith<T, U>;

1) The exposition-only concept __WeaklyEqualityComparableWith<T, U> specifies that an object of type T and an object of type U can be compared for equality with each other (in either order) using both == and !=, and the results of the comparisons are consistent.
More formally, __WeaklyEqualityComparableWith<T, U> is satisfied only if given

* t, an lvalue of type const std::remove_reference_t<T> and
* u, an lvalue of type const std::remove_reference_t<U>,

the following are true:

* t == u, u == t, t != u,u != t have the same domain;
* bool(u == t) == bool(t == u);
* bool(t != u) == !bool(t == u); and
* bool(u != t) == bool(t != u).

2) The concept EqualityComparable<T> specifies that the comparison operators == and != on T reflects equality: == yields true if and only if the operands are equal.
EqualityComparable<T> is satisfied only if, given objects a and b of type T, bool(a == b) is true if and only if a and b are equal. Together with the requirement that a == b is equality preserving, this implies that == is symmetric and transitive, and further that == is reflexive for all objects a that are equal to at least one other object.
3) The concept EqualityComparableWith<T, U> specifies that the comparison operators == and != on (possibly mixed) T and U operands yield results consistent with equality. Comparing mixed operands yields results equivalent to comparing the operands converted to their common type.
Formally, EqualityComparableWith<T, U> is satisfied only if, given any lvalue t of type const std::remove_reference_t<T> and any lvalue u of type const std::remove_reference_t<U>, and let C be std::common_reference_t<const std::remove_reference_t<T>&, const std::remove_reference_t<U>&>, bool(t == u) == bool(C(t) == C(u)).

Equality preservation

An expression is equality preserving if it results in equal outputs given equal inputs.

* The inputs to an expression consist of its operands.
* The outputs of an expression consist of its result and all operands modified by the expression (if any).

Every expression required to be equality preserving is further required to be stable: two evaluations of such an expression with the same input objects must have equal outputs absent any explicit intervening modification of those input objects.
Unless noted otherwise, every expression used in a requires-expression is required to be equality preserving and stable, and the evaluation of the expression may only modify its non-constant operands. Operands that are constant must not be modified.

Implicit expression variations

A requires-expression that uses an expression that is non-modifying for some constant lvalue operand also implicitly requires additional variations of that expression that accept a non-constant lvalue or (possibly constant) rvalue for the given operand unless such an expression variation is explicitly required with differing semantics. These implicit expression variations must meet the same semantic requirements of the declared expression. The extent to which an implementation validates the syntax of the variations is unspecified.