[class.spaceship] lacks to specify the behavior if the defined expression for synthesized three-way comparison is ill-formed #5338

xmh0511 · 2022-03-09T02:12:35Z

Consider this example:

struct C{
   int operator <=>(C const&) const noexcept = default;
   int a = 0;
};
int main(){
    using type = decltype(&C::operator<=>);
}

GCC:

<source>:8:39: error: use of deleted function 'constexpr int C::operator<=>(const C&) const'
    8 |     using type = decltype(&C::operator<=>);
      |                                       ^~~
<source>:4:8: note: 'constexpr int C::operator<=>(const C&) const' is implicitly deleted because the default definition would be ill-formed:
    4 |    int operator <=>(C const&) const noexcept = default;
      |        ^~~~~~~~
<source>:5:8: error: three-way comparison of 'C::a' has type 'std::strong_ordering', which does not convert to 'int'
    5 |    int a = 0;

GCC and Clang have a divergence implementation on the point that if the defined expression is ill-formed. Specifically, the expanded list of subobjects for an object x of type C consists of {C::a}, where the synthesized three-way comparison is defined as static_cast<int>(a<=>a) as per [class.spaceship] p1.1. Since the operand of the operator <=> in the defined expression has type int, built-in expression interpretation applies to the operator, its type is std::strong_ordering whose prvalue cannot be converted to type int. Thus, the defined expression static_cast<int>(a<=>a) is ill-formed, on this point, GCC thinks the defaulted three-way comparison function should be deleted while Clang thinks it's ok(not be deleted). However, [class.spaceship.note] p1 wants to imply something regarding this case. However, it's not a formal rule and no overload resolution performs in this case too.

The text was updated successfully, but these errors were encountered:

frederick-vs-ja · 2022-03-10T04:26:35Z

Isn't this the case for C<Weak> in P1186R3?

xmh0511 · 2022-03-10T06:22:31Z

Isn't this the case for C<Weak> in P1186R3?

Thanks, that paper has listed a large of particular cases that can expose the problem to which this issue is concerning. From [class.spaceship.note] p1, the standard prefers to consider these synthesized three-way comparisons to be ill-formed, thus I agree with the opinion thereof in that paper: Erring on the side of ill-formed helps programmers catch bugs earlier; rather than just delete the defaulted function instead.

xmh0511 · 2022-03-10T09:12:53Z

The proposal in that paper says:

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

Conversely, the current draft only talks about "is not defined". For the example given in this issue, it has a defined synthesized three-way comparison, merely the defined expression is ill-formed. The case falls into the "would be ill-formed", however, the current draft lacks to specify such a condition in the formal rules.

Improvement:

Let R be the declared return type of a defaulted three-way comparison operator function, and let
x_i be the elements of the expanded list of subobjects for an object x of type C.

[...]

Otherwise, R shall not contain a placeholder type. If the synthesized three-way comparison 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.

jensmaurer · 2022-03-10T09:52:26Z

Not an improvement. "If ill-formed, then deleted" is too far-reaching to be implementable.

See CWG2432.

frederick-vs-ja · 2022-03-10T10:08:55Z

Using "would be ill-formed" here is not an improvement but a regression.

The "would be ill-formed" part was removed by P2002R1, following the rationale described in P1630R1: no function should be instantiated when determining whether a defaulted function is deleted.

xmh0511 · 2022-03-10T10:28:12Z

@jensmaurer @frederick-vs-ja

The other opinion is, whether the defaulted function is defined as deleted, which is only determined by whether the synthesized three-way comparison is defined; This keeps the same as the current draft did. However, if once the defaulted function is odr-used or its definition is required, the prior synthesized three-way comparison is rechecked to determine whether the program is well-formed as if the synthesized three-way comparison would appear in the definition of the defaulted function.

This is consistent with what Clang has done.

jensmaurer · 2022-03-10T12:19:03Z

And that's consistent with what we do for defaulted constructors: In a first phase, we check whether the default constructor is deleted; in a second phase (when the definition is needed), we compile the actual definition (which might end up being ill-formed).

And this seems to be the intent here, too, and seems to be supported by the existing wording, so maybe it's enough to add a note.

xmh0511 · 2022-03-10T15:05:19Z

@jensmaurer For default constructor or other special member functions, we explicitly define the condition that the defaulted default constructor should be defined as deleted. For ill-formed cases, I think they are regulated by [class.base.init] together with [dcl.init]. Such as the default initialization of the member of reference type. we explicitly state such a case will be ill-formed through [dcl.init.general] p10.

The difference here is that we didn't explicitly phrase what will happen when evaluating the defaulted three-way comparison except that we may intend to imply this point by specifying the return value of the comparison in [class.spaceship] p3. Maybe, we could explicitly state the "ill-formed" story in [class.spaceship] p3:

until the first index i where the synthesized three-way comparison of type R between x_i and y_i yields a result value v_i where v_i != 0, contextually converted to bool, yields true; V is a copy of v_i.

It seems that the rule intends to say the evaluation of the default comparison will evaluate the synthesized comparison of the subobjects. However, it's not explicit. Maybe, we could say: if any synthesized three-way comparison of type R between x_i and y_i results in an invalid expression, the program is ill-formed. I think this sentence is close to what the implementation did.

jensmaurer · 2022-03-10T18:55:06Z

The point is still that the constructor descriptions rely on specifications elsewhere to get to the ill-formed cases. I'm not seeing why we need to be normatively different for the comparison operators. I do agree that the "deleted" and "use this expression" cases are a bit more interwoven for the comparison functions.

xmh0511 · 2022-03-11T02:02:45Z

@jensmaurer I think we just need to specify what expressions are in the implicit definition of a defaulted comparison operator function, all the issues mentioned above will be resolved.

Consider [except.spec] p11

The exception specification for a comparison operator function ([over.binary]) without a noexcept-specifier that is defaulted on its first declaration is potentially-throwing if and only if any expression in the implicit definition is potentially-throwing.

we seem to haven't yet defined the concept for what expressions are in the implicit definition. For a defaulted three-way comparison, the expressions presumably are these synthesized three-way comparisons for the subobjects in the object x of class C of which the defaulted function is a member, which are used to determine the return value. The same is true of defaulted equality operator function. For these defaulted functions, we just specify their return values, we never explicitly phrase that these expressions that are used to determine the return value appear within the implicit definitions.

So, I think we lack to define the concept for what expressions are in the implicit definition of a defaulted function. This can clarify [except.spec] p11, and it can naturally interpret why the invocation of the defaulted function or the context where the definition is required will cause the program ill-formed if any expression in the implicit definition is invalid.

xmh0511 mentioned this issue Nov 10, 2022

[class.spaceship] p3 The error occurs in the context of defined the return value of the defaulted three-way comparison cplusplus/CWG#169

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[class.spaceship] lacks to specify the behavior if the defined expression for synthesized three-way comparison is ill-formed #5338

[class.spaceship] lacks to specify the behavior if the defined expression for synthesized three-way comparison is ill-formed #5338

xmh0511 commented Mar 9, 2022 •

edited

Loading

frederick-vs-ja commented Mar 10, 2022

xmh0511 commented Mar 10, 2022 •

edited

Loading

xmh0511 commented Mar 10, 2022 •

edited

Loading

jensmaurer commented Mar 10, 2022

frederick-vs-ja commented Mar 10, 2022 •

edited

Loading

xmh0511 commented Mar 10, 2022 •

edited

Loading

jensmaurer commented Mar 10, 2022

xmh0511 commented Mar 10, 2022 •

edited

Loading

jensmaurer commented Mar 10, 2022

xmh0511 commented Mar 11, 2022 •

edited

Loading

[class.spaceship] lacks to specify the behavior if the defined expression for synthesized three-way comparison is ill-formed #5338

[class.spaceship] lacks to specify the behavior if the defined expression for synthesized three-way comparison is ill-formed #5338

Comments

xmh0511 commented Mar 9, 2022 • edited Loading

frederick-vs-ja commented Mar 10, 2022

xmh0511 commented Mar 10, 2022 • edited Loading

xmh0511 commented Mar 10, 2022 • edited Loading

jensmaurer commented Mar 10, 2022

frederick-vs-ja commented Mar 10, 2022 • edited Loading

xmh0511 commented Mar 10, 2022 • edited Loading

jensmaurer commented Mar 10, 2022

xmh0511 commented Mar 10, 2022 • edited Loading

jensmaurer commented Mar 10, 2022

xmh0511 commented Mar 11, 2022 • edited Loading

xmh0511 commented Mar 9, 2022 •

edited

Loading

xmh0511 commented Mar 10, 2022 •

edited

Loading

xmh0511 commented Mar 10, 2022 •

edited

Loading

frederick-vs-ja commented Mar 10, 2022 •

edited

Loading

xmh0511 commented Mar 10, 2022 •

edited

Loading

xmh0511 commented Mar 10, 2022 •

edited

Loading

xmh0511 commented Mar 11, 2022 •

edited

Loading