Explicit constructor with default argument is in a superstate of viable/non-viable for overload resolution

[eisenwave]

https://godbolt.org/z/Gsqs1vo5P, original issue: https://stackoverflow.com/q/77788861/5740428

struct A {
  explicit A(int = 0);
  // A()= default;
} a = {};

Clang considers this ill-formed both if you comment out the second constructor uncomment it. In its current state, clang emits:

<source>:4:3: error: chosen constructor is explicit in copy-initialization
    4 | } a = {};
      |   ^   ~~
<source>:2:12: note: explicit constructor declared here
    2 |   explicit A(int = 0);
      |            ^

When uncommenting the second constructor, we get:

<source>:4:3: error: call to constructor of 'struct A' is ambiguous
    4 | } a = {};
      |   ^   ~~
<source>:2:12: note: candidate constructor
    2 |   explicit A(int = 0);
      |            ^
<source>:3:3: note: candidate constructor
    3 |   A()= default;
      |   ^

This is nonsensical. A(int) can't simultaneously

• be viable and cause an ambiguous overload, and
• be non-viable and cause = {} to be ill-formed when it's the only overload.

[eisenwave]

Could it be that this behavior is intentional? GCC emits a warning for one of the cases at least, and perhaps LLVM handles this similarly:

<source>:4:8: warning: converting to 'A' from initializer list would use explicit constructor 'A::A(int)'
    4 | } a = {};
      |        ^
<source>:2:12: note: 'A::A(int)' declared here
    2 |   explicit A(int = 0);
      |            ^
<source>:4:8: note: in C++11 and above a default constructor can be explicit
    4 | } a = {};
      |        ^

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Jan Schultke (Eisenwave)

https://godbolt.org/z/Gsqs1vo5P, original issue: https://stackoverflow.com/q/77788861/5740428 ```cpp struct A { explicit A(int = 0); // A()= default; } a = {}; ``` Clang considers this ill-formed both if you comment out the second constructor uncomment it. In its current state, clang emits: ```none <source>:4:3: error: chosen constructor is explicit in copy-initialization 4 | } a = {}; | ^ ~~ <source>:2:12: note: explicit constructor declared here 2 | explicit A(int = 0); | ^ ``` When uncommenting the second constructor, we get: ```none <source>:4:3: error: call to constructor of 'struct A' is ambiguous 4 | } a = {}; | ^ ~~ <source>:2:12: note: candidate constructor 2 | explicit A(int = 0); | ^ <source>:3:3: note: candidate constructor 3 | A()= default; | ^ ``` This is nonsensical. `A(int)` can't simultaneously - be viable and cause an ambiguous overload, and - be non-viable and cause `= {}` to be ill-formed when it's the only overload.

[cor3ntin]

There is wild implementation divergence.
Per, https://eel.is/c++draft/over.match#list-1.sentence-2 I think clang is correct.

I cannot find wording that would imply that overload resolution should ignore explicit constructors during
copy-list-initialization, nor did i find any core issues on the topic.

so, given

struct A {
  explicit A(int = 0);
  A()= default;
} a = {};

Overload resolution fails because we find two equally valid constructors.
And, given

struct A {
  explicit A(int = 0);
} a = {};

We fail because we chose an explicit copy constructor for copy-list-initialization

[eisenwave]

@cor3ntin no, Clang is wrong. See https://stackoverflow.com/a/77793082/5740428 for the full explanation.

In short, copy-list-initialization delegates to value-initialization which delegates to default-initialization.

[over.match.ctor] p1 states that default-initialization in the context of copy-initialization (i.e. also copy-list-initialization) does not consider explicit constructors to be candidates. It would also be intuitively wrong if = {} (which is copy-initialization) could pick an explicit constructor.

explicit A(int = 0) should not be part of the candidate set at all. Perhaps in the context of default-initialization normally, but not when this default-initialization is in the context of copy-initialization. This was decided in cplusplus/draft#1911

[ckwastra]

CWG2856 has been resolved, and Clang's behavior is correct under the revised wording.