On Fri, 2024-02-09 at 15:53 +0100, Johannes Schaub wrote:
> Turns out that we have an issue report for this on WG21. It is public
> with github CWG issue 486.

This doesn't look related:

https://cplusplus.github.io/CWG/issues/486.html

I assume you mistyped the issue number.

>
> I guess my question on the rationale is answered then. Seems to be
> non-intentional, as I hoped.
>
> Johannes Schaub <schaub.johannes_at_[hidden]> schrieb am Fr., 9.
> Feb. 2024, 15:08:
> >
> >
> > Lénárd Szolnoki via Std-Discussion
> > <std-discussion_at_[hidden]> schrieb am Fr., 9. Feb. 2024,
> > 14:41:
> > > On Fri, 2024-02-09 at 14:01 +0100, Johannes Schaub via Std-
> > > Discussion
> > > wrote:
> > > > According to what I read on the Eelis draft, the following
> > > > should
> > > > resolve to the nonexplicit ctor (consistency gone, since it is
> > > > different for non default ctors... what is the reason for this
> > > > inconsistency?).
> > > >
> > > > But GCC and Clang raise an ambiguity. Why do they? This seems
> > > > like a
> > > > simple example.
> > > >
> > > > struct A { explicit A() { } A(int = 0) { } }; A a = {};
> > >
> > > Overload resolution for copy-list-initialization is intentionally
> > > different from overload resolution for copy-initialization.
> > >
> > > https://eel.is/c++draft/dcl.init.list#3.5 applies. Value
> > > initialization
> > > resolves to direct initialization from `()`, which is ambiguous.
> >
> > It does not resolve to that. But it resolves to going to default
> > initialization which enumerates candidate ctors by using
> > over.match.ctor, which is sensitive to the context being copy
> > initialization (which it is, here). The resulting candidates are
> > then sent to overload resolution with the argument list resulting
> > from an initializer "()". This algorithm is wholly different that
> > your one-sentence summary.
> >

I guess that's a more sensible reading. Either way, the wording is not
good and IMO it should be consistent with [dcl.init.list]/3.7 . Would
be weird if overload resolution would have a corner case for `=
{pack...}` when `pack` happens to be empty.

Cheers,
Lénárd