CWG3133 [over.built] Cv-qualified types in candidate operator functions

[eisenwave]

Reference (section label): [over.built]

Issue description

While [over.built] paragraph 7 ensures that only candidates for cv-unqualified floating-point types exists, subsequent paragraphs do not. For example, there exist the candidate operator functions:

float operator*(float, float);
float operator*(const float, float);
float operator*(const volatile float, float);
float operator*(float, const float);
// ...
float operator*(const volatile float, const volatile float);

[over.built] paragraph 11 requires a candidate operator function for every integral type, not just promoted integral types:

std::strong_ordering operator<=>(const volatile bool, const volatile bool);
std::strong_ordering operator<=>(int, int);
std::strong_ordering operator<=>(const int, const int);
// ...

[over.built] paragraph 22 also does not restrict $L$ to cv-unqualified integral types. There exists a case where the vq placeholder means volatile and is combined with $L$, which is already volatile:

char& operator&=(char&, int);
volatile char& operator&=(volatile char&, int);
const volatile char& operator&=(const volatile char&, int);
volatile volatile char& operator&=(volatile volatile char&, int);
// ...

Suggested resolution

Change [over.built] paragraph 10 as follows:

 For every pair of types L and R,
 where each of L and R is a
+cv-unqualified
 floating-point or promoted integral type,
 there exist candidate operator functions of the form ...

Change [over.built] paragraph 11 as follows:

 For every
+promoted
 integral type T there exists a candidate operator function of the form ...

Change [over.built] paragraph 12 as follows:

 For every pair of
+cv-unqualified
 floating-point types L and R,
 there exists a candidate operator function of the form ...

Change [over.built] paragraph 18 as follows:

 For every triple (L , vq, R ),
 where L is an arithmetic type,
 and R is a
+cv-unqualified
 floating-point or promoted integral type,
 there exist candidate operator functions of the form ...

Change [over.built] paragraph 22 as follows:

 For every triple (L , vq, R ), where L is
-an
+a cv-unqualified
 integral type,
 and R is a promoted integral type,
 there exist candidate operator functions of the form

Change [over.built] paragraph 24 as follows:

 For every pair of types L and R,
 where each of L and R is a
+cv-unqualified
 floating-point or promoted integral type,
 there exist candidate operator functions of the form ...

[jensmaurer]

After the usual type adjustments, those top-level cv-qualifiers aren't observable, I believe. Also, "volatile volatile" is certainly combined into a single "volatile" by the usual rules.

Requiring a <=> overload for all integral types is intentional, as far as I understand. Absent further evidence (e.g. from the original paper), I would not want to mix this into the almost-editorial other fixes here.

[eisenwave]

I agree that most of these cases aren't actually observable since the same candidate is being generated.

Not forcing promotion there is also fine; "cv-unqualified integral type" would work.

In the long run, it may become not-so editorial because volatile in function parameters is already deprecated AFAIK, and may be removed in the future, which would mean we're generating ill-formed candidates here.

[jensmaurer]

CWG3133