Created on 2022-06-28.00:00:00 last changed 1 month ago
This wording is relative to N4910.
Modify [tuple.rel] as indicated:
template<class... TTypes, class... UTypes> constexpr common_comparison_category_t<synth-three-way-result<TTypes, UTypes>...> operator<=>(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
Effects: Performs a lexicographical comparison between t and u. For any two zero-length tuples t and u, t <=> u returns strong_ordering::equal. Otherwise, equivalent to: if (auto c = synth-three-way(get<0>(t), get<0>(u)); c != 0) return c; return ttail <=> utail;
where rtail for some tuple r is a tuple containing all but the first element of r. -5- [Note 1: The above definition does not require ttail (or utail) to be constructed. It might not even be possible, as t and u are not required to be copy constructible. Also, all comparison operator functions are short circuited; they do not perform element accesses beyond what is required to determine the result of the comparison. — end note]
[ 2022-07-08; Reflector poll ]
Set priority to 4 after reflector poll.
Some votes for NAD and preference for the current wording, adding "in order"
to clarify the order of elements in
The specification of operator<=>(tuple, tuple) ([tuple.rel]) is described in terms of imaginary tuples (ttail, utail, rtail) which is a bit confusing. Indeed, It is not clear that these imaginary tuples need to respect the order of elements of u and t, nor whether the value category of the elements in these imaginary tuples can or should be conserved. It is possible to reformulate and simplify that description so that no imaginary tuple is involved.The remark is copied from the similar wording of operator==
|2022-07-08 20:04:38||admin||set||messages: + msg12566|
|2022-07-03 12:20:01||admin||set||messages: + msg12546|