Proposed resolution (September, 2019)

Change 11.10.3 [class.spaceship] paragraphs 1-3, changing the running text of paragraph 2 to into a bulleted list, as follows:

The synthesized three-way comparison for comparison category of type R (17.11.2 [cmp.categories]) of glvalues a and b...

Let R be the declared return type of a defaulted three-way comparison operator function. Given an expanded list of subobjects for an object x of type C, let R_i be the type of the expression x_i <=> x_i is denoted by R_i. If , or void if overload resolution as applied to x_i <=> x_i that expression does not find a usable function, then R_i is void.

• If the declared return type of a defaulted three-way comparison operator function R is auto, then the return type is deduced as the common comparison type (see below) of R₀, R₁, ..., R_n-1. If the return type is deduced as void, the operator function is defined as deleted.

• If the declared return type of a defaulted three-way comparison operator function is R and Otherwise, if the synthesized three-way comparison for comparison category of type R between any objects x_i and x_i is not defined or would be ill-formed, the operator function is defined as deleted.

...until the first index i where the synthesized three-way comparison for comparison category of type R between x_i and y_i yields...

[Adopted as a DR at the November, 2019 meeting.]

It is unclear what the constraints are on the type R. We define the "synthesized three-way comparison for comparison category type R", but it's defined in such a way that it works for an arbitrary type R, and the uses of it do not impose a constraint that R is a comparison category type. Should it be permissible to default an operator<=> with some other return type, so long as the construction described in 11.10.3 [class.spaceship] works (specifically, so long as all subobjects have operator<=>s that can be converted to the specified return type)?