https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
--- Comment #22 from David Friberg <davveston at gmail dot com> ---
(In reply to TC from comment #21)
> (In reply to David Friberg from comment #19)
> >
> > P0398R0 [1] describes the final resolution to CWG 1518, after which the
> > following example is arguably well-formed:
> >
>
> It's not. Explicitness of a constructor is not considered when forming
> implicit conversion sequences from a braced-init-list, and therefore the
> assignment is ambiguous because {} can convert to either S or tag_t, even
> though the latter is ill-formed if actually used.
TC, thanks for the clarification. Just to be sure I'm not missing something, I
was under the impression that the [**emphasis**]
> For direct-initialization or default-initialization
> **that is not in the context of copy-initialization**,
> the candidate functions are all the constructors of
> the class of the object being initialized.
part of [over.match.ctor]/1 [1], which was added in P0398R0, intended to remove
non-converting (explicit) constructors from overload resolution in this
context, particularly resolving the issue shown in the original example of LWG
issue 251 [2]:
> That turns out to be very unfortunate, consider the following:
>
> #include <memory>
> #include <array>
>
> void f(std::array<int, 1>, int) {} // #1
> void f(std::allocator_arg_t, int) {} // #2
>
> int main()
> {
> f({}, 666); // #3
> }
>
> The call at #3 is ambiguous.
after which the call at #3 in the LWG example above is no longer ambiguous
(afaict). I may be missing some subtlety here, but does my example above not
fall into the same category as this one?
[1] https://timsong-cpp.github.io/cppwp/n4861/over.match.ctor#1
[2] https://cplusplus.github.io/LWG/issue2510
