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

user_11638718 0
Viewed 89
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)

language-lawyer implicit-conversion c++
2 Answers

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]

user_120025700

This seems to be a variant of 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, it seems this original wording, as well as the wording around it, were somewhat ambiguous in whether or not deletedness of the used constructor/conversion operator in this conversion should be considered and the issue description seems to indicate that a strict reading lead to surprisingly inconsistent results. I don't know exactly how the interpretation in the issue would apply to your case, but I would not be surprised if it matches Clang's behavior, given the issue's author.

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.

user_177325220
Related