Ternary operator applied to class with conversion operator and delete constructor causes ambiguity-CodePudding

struct A {
  A();
  A(int) = delete;
  operator int(); 
};

int main() {
  true ? A{} : 0;
}

Compile with C 20, Clang accepts it, but GCC and MSVC reject it with similar error messages

<source>(8): error C2445: result type of conditional expression is ambiguous: types 'A' and 'int' can be converted to multiple common types
<source>(8): note: could be 'A'
<source>(8): note: or       'int'

int doesn't seem to be convertible to A since the constructor is delete, but I'm not sure why GCC/MSVC still thinks it can. Which compiler is right?

(Demo)

CodePudding user response：

I think that gcc and msvc are correct in rejecting the code because a deleted function will still take part during overload resolution. This means that there are two possibilties.

First is that A{} can be converted to a int via the conversion function. Second is that even though 0 can't be converted to A , the corresponding converting constructor A::A(int) will still take part in overload resolution. Hence, there is ambiguity(about which operand to convert) and the program should not compile(as in GCC and MSVC).

From conditional operator's documentation:

[Note 2 : Properties such as access, whether an operand is a bit-field, or whether a conversion function is deleted are ignored for that determination. — end note]

CodePudding user response：

This seems to be CWG issue 1895.

Before its resolution (in 2016 with C 17) the relevant wording asked whether either operand could be "converted" to the target type formed from the other operand's type.

Going by the issue description at least, that was to be interpreted as whether a corresponding variable declaration with copy-initialization would be well-formed and therefore consider whether the used conversion operator/constructor is deleted. With that interpretation Clang is right to accept and use operator int to convert A{} to int, since conversion of 0 to A would use a deleted function. Whether that interpretation is uncontested, I don't know.

In any case, the resolution of the issue changed the wording to whether "an implicit conversion sequence can be formed", which is in line with overload resolution and definitively does not consider whether the chosen implicit conversion sequence will actually result in a conversion that is well-formed, in particular whether or not the used functions are accessible/deleted.

The note referenced in the answer by @AnoopRana was also added with that resolution to make this clear.

With the new wording, both the conversion sequences from A{} to int and 0 to A can be formed and hence the operator is ambiguous. MSVC and GCC are correct now.

Clang lists defect report 1895's implementation status as "unknown" at the current time (https://clang.llvm.org/cxx_dr_status.html) and still has an open bug matching the CWG issue description here.