Problem with braced-init-lists and explicit ctors

Problem with braced-init-lists and explicit ctors

[Joaquin M Lopez Munoz]

Using GCC 4.8 -std=c++11. The following overload resolution is not
ambiguous as bar::bar is explicit, which is fine: 

struct foo 
{ 
  foo(int){} 
}; 

struct bar 
{ 
  explicit bar(int){} 
}; 

void f(foo){} 
void f(bar){} 

int main() 
{ 
  f(0); 
} 

But if I change the call statement to 

int main() 
{ 
  f({0}); 
} 

then I get 

main.cpp:16:8: error: call of overloaded 'f(<brace-enclosed initializer
list>)' is ambiguous 
   f({0}); 
        ^ 
main.cpp:16:8: note: candidates are: 
main.cpp:11:6: note: void f(foo) 
 void f(foo){} 
      ^ 
main.cpp:12:6: note: void f(bar) 
 void f(bar){} 
      ^ 

Is this a bug or am I missing some subtlety in the standard? Thank you, 

Joaquín M López Muñoz 
Telefónica Digital

Re: Problem with braced-init-lists and explicit ctors

[Marc Glisse]

On Sun, 2 Feb 2014, Joaquin M Lopez Munoz wrote:

> Using GCC 4.8 -std=c++11. The following overload resolution is not
> ambiguous as bar::bar is explicit, which is fine:
>
> struct foo
> {
>  foo(int){}
> };
>
> struct bar
> {
>  explicit bar(int){}
> };
>
> void f(foo){}
> void f(bar){}
>
> int main()
> {
>  f(0);
> }
>
> But if I change the call statement to
>
> int main()
> {
>  f({0});
> }
>
> then I get
>
> main.cpp:16:8: error: call of overloaded 'f(<brace-enclosed initializer
> list>)' is ambiguous
>   f({0});
>        ^
> main.cpp:16:8: note: candidates are:
> main.cpp:11:6: note: void f(foo)
> void f(foo){}
>      ^
> main.cpp:12:6: note: void f(bar)
> void f(bar){}
>      ^
>
> Is this a bug or am I missing some subtlety in the standard? Thank you,

If there is a subtlety, clang and intel are missing it since they accept 
the code. Please file this in bugzilla.

-- 
Marc Glisse

Re: Problem with braced-init-lists and explicit ctors

[Joaquin M Lopez Munoz]

Marc Glisse <marc.glisse <at> inria.fr> writes:

> 
> On Sun, 2 Feb 2014, Joaquin M Lopez Munoz wrote:
> >
> > [...]
> > Is this a bug or am I missing some subtlety in the standard? Thank you,
> 
> If there is a subtlety, clang and intel are missing it since they accept 
> the code. Please file this in bugzilla.
> 

Done:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027

Joaquín M López Muñoz
Telefónica Digital

Re: Problem with braced-init-lists and explicit ctors

[Michael Powell]

Hmm, so it seems MSVC isn't the only compiler with initializer list issues... ?

On Sun, Feb 2, 2014 at 3:26 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Sun, 2 Feb 2014, Joaquin M Lopez Munoz wrote:
>
>> Using GCC 4.8 -std=c++11. The following overload resolution is not
>> ambiguous as bar::bar is explicit, which is fine:
>>
>> struct foo
>> {
>>  foo(int){}
>> };
>>
>> struct bar
>> {
>>  explicit bar(int){}
>> };
>>
>> void f(foo){}
>> void f(bar){}
>>
>> int main()
>> {
>>  f(0);
>> }

My question is, to borrow a coined phrase, how do you "reason" about
this one? Which version of "f" would you expect to be called, and why
would that be practical anyway, potentially confusing foo with bar?

>> But if I change the call statement to
>>
>> int main()
>> {
>>  f({0});
>> }
>>
>> then I get
>>
>> main.cpp:16:8: error: call of overloaded 'f(<brace-enclosed initializer
>> list>)' is ambiguous
>>   f({0});
>>        ^
>> main.cpp:16:8: note: candidates are:
>> main.cpp:11:6: note: void f(foo)
>> void f(foo){}
>>      ^
>> main.cpp:12:6: note: void f(bar)
>> void f(bar){}
>>      ^

So in other words, my question would be, is this truly a bug? Or are
you rightly being slapped for wanting to confuse the issue? In other
words, which is the bug? A "confused" (overloaded) function signature,
or a "confused" (potentially) end-user usage.

>> Is this a bug or am I missing some subtlety in the standard? Thank you,
>
>
> If there is a subtlety, clang and intel are missing it since they accept the
> code. Please file this in bugzilla.
>
> --
> Marc Glisse

Re: Problem with braced-init-lists and explicit ctors

[Jonathan Wakely]

On 2 February 2014 21:07, Michael Powell wrote:
> Hmm, so it seems MSVC isn't the only compiler with initializer list issues... ?

G++ apparently has a bug in this area, but otherwise has excellent
support for initializer lists.

> My question is, to borrow a coined phrase, how do you "reason" about
> this one? Which version of "f" would you expect to be called,

It's not possibly to implicitly create a bar object form an int,
because it's constructor is explicit. Therefore f(foo) is the only
viable overload.

> and why
> would that be practical anyway, potentially confusing foo with bar?

That's not really relevant, the compiler has to do what the language
standard says, whether the code is useful or not.

> So in other words, my question would be, is this truly a bug?

It's a bug.

Argument passing is copy-initialization ([dcl.init]/14), so f({0}) is
copy-list-initialization, and so if overload resolution chooses an
explicit constructor it's ill-formed ([over.match.list]/1)