Hi,

I can add some historic context to related situations here. There are other
instances where a function is viable, even though calling it would be
illformed:

- Most obviously, when an access violation happens
- When a non-const reference would be bound to a bitfield
- When an explicit constructor would be called to accept an
initializer-list argument (Clang, IIRC, will not follow the spec here and
marks the candidate non-viable, even though this is a conscious design
choice).
- When an argument can be converted to a parameter in multiple ways with
none better than others (e.g. two conversion functions equally good).

There's a tradeoff to be made between making erroneous programs that
contain mistakes or typos ill-formed (lending towards ambiguity) and making
them "accidentally compile".


Vladimir Grigoriev via Std-Discussion <std-discussion_at_[hidden]>
schrieb am Di., 25. Mai 2021, 12:06:

> In the section «12.4.3.1.5 List-initialization sequence» in the second
> paragraph there is an example
>
> struct A { int x, y; };
> struct B { int y, x; };
>
> void g(A a);
> void g(B b);
>
> g({.x = 1, .y = 2});
>
> And in a comments to this example there is written that the call of the
> function g is ambiguous.
>
> On the other hand, in the paragraph there is also written that
> «If, after overload resolution, the order does not match for the selected
> overload, the initialization of the parameter will be ill-formed»
>
> So my question is why is in the C++ Standard adopted that the call is
> ambiguous instead of making the function void g( A a ) the most viable
> function because the call of the function void g( B b ) is ill formed?
>
> With best regards
> (Vlad from Moscow)
>
>