Proposed resolution:

This wording is relative to N4910.

1. 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);
   

   -4- EffectsReturns: synth-three-way(get<i>(t), get<i>(u)) for the first i for which the result of that expression does not compare equal to 0. If no such i exists, strong_ordering::equal.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 r_tail for some tuple r is a tuple containing all but the first element of r.

   -?- Remarks: The elementary synth-three-way(get<i>(t), get<i>(u)) expressions are evaluated in order from the zeroth index upwards. No element accesses are performed after the first invocation that results in a value that does not compare equal to 0.

   -5- [Note 1: The above definition does not require t_tail (or u_tail) 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 rtail.

The specification of operator<=>(tuple, tuple) ([tuple.rel]) is described in terms of imaginary tuples (t_tail, u_tail, r_tail) 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==