This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 22.4.9 [tuple.rel] Status: New Submitter: Corentin Jabot Opened: 2022-06-28 Last modified: 2022-07-08
View other active issues in [tuple.rel].
View all other issues in [tuple.rel].
View all issues with New status.
The specification of operator<=>(tuple, tuple) (22.4.9 [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; 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
This wording is relative to N4910.
Modify 22.4.9 [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]