On Thu, 5 Feb 2026 at 11:33, Ville Voutilainen
<[email protected]> wrote:
>
> On Thu, 5 Feb 2026 at 13:28, Jonathan Wakely <[email protected]> wrote:
> > Iain, Nina, is there a reason we need the new problematic constructor,
> > or can we just do this instead? If we do need the constructor, does it
> > need to take const void* or could it use const __impl* instead?
>
> No, there is no such reason. It was deemed slightly cleaner to invoke
> a private constructor
> from a friend than mucking with a data member directly from a friend,
> but we didn't realize/remember
> when ruminating on that that it messes with overload resolution
> despite being private.
I've just realised that even if the private ctor is marked explicit,
it would still cause ambiguities for a braced-init-list containing a
pointer, e.g. the second call to f here:
struct S { S(char const *); };
void f(S);
void f(source_location);
void
test01()
{
f(""); // { dg-bogus "ambiguous" }
f({""}); // { dg-bogus "ambiguous" }
}
I'll update the testcase to check this before I push the patch.
(The case above is ambiguous even with an explicit ctor because C++ is
broken, and "uniform init" always considers all constructors, even
explicit ones where there is no type being named ... I hate this.)
