[Bug c++/51553] New: brace initialization and conversion operators

[Bug c++/51553] New: brace initialization and conversion operators

[dave at boostpro dot com]

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

             Bug #: 51553
           Summary: brace initialization and conversion operators
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dave@boostpro.com


Please consider this test case:

--------- <schnipp> --------
struct X
{
    X();
};

struct Y
{
    operator X() const;
};

struct Z
{
    explicit operator X() const;
};

X a = { Y() };  // #1. error: could not convert '{Y()}' from '<brace-enclosed
initializer list>' to 'X'
X aa = Y();     // #1a. OK

X b{ Y() };     // #2. error: no matching function for call to
'X::X(<brace-enclosed initializer list>)'
X bb(Y());      // #2a. OK

X c = { Z() };  // #3 error: could not convert '{Z()}' from '<brace-enclosed
initializer list>' to 'X'
X cc = Z();     // #3a. error: conversion from 'Z' to non-scalar type 'X'
requested

X d{ Z() };     // #4 error: no matching function for call to
'X::X(<brace-enclosed initializer list>)'
X dd( Z() );    // OK
--------- <schnapp> --------

I can't find anything in the standard that justifies a difference between the
brace- and braceless-initialization cases.  Even in case #3, the difference in
error message leads me to think the code may be failing for the wrong reasons.

[Bug c++/51553] brace initialization and conversion operators

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011-12-19
                 CC|                            |jason at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |jason at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

[Bug c++/51553] brace initialization and conversion operators

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> 2011-12-19 20:10:45 UTC ---
Author: jason
Date: Mon Dec 19 20:10:37 2011
New Revision: 182495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182495
Log:
    PR c++/51553
    * call.c (add_function_candidate): Allow conversions for the copy
    parm in list-initialization unless the argument is an init-list.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist64.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/51553] brace initialization and conversion operators

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> 2011-12-19 20:11:00 UTC ---
Author: jason
Date: Mon Dec 19 20:10:49 2011
New Revision: 182496

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182496
Log:
    PR c++/51553
    * cp-tree.h (LOOKUP_LIST_INIT_CTOR): Rename from
    LOOKUP_NO_COPY_CTOR_CONVERSION.
    (add_list_candidates): Set it earlier.
    (add_candidates): Don't check explicit on ctors when it's set.
    (add_function_candidate): Check it even when LOOKUP_ONLYCONVERTING
    is set.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist64.C

[Bug c++/51553] brace initialization and conversion operators

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.0

--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> 2011-12-19 20:16:00 UTC ---
Fixed.

[Bug c++/51553] brace initialization and conversion operators

[david.d.kretzmer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553

david.d.kretzmer at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.d.kretzmer at gmail dot com

--- Comment #4 from david.d.kretzmer at gmail dot com ---
13.3.3.1 p4 [over.best.ics]
[...] or when the initializer
list has exactly one element and a conversion to some class X or reference to
(possibly cv-qualified) X is
considered for the first parameter of a constructor of X, or by 13.3.1.4,
13.3.1.5, or 13.3.1.6 in all cases, only
standard conversion sequences and ellipsis conversion sequences are considered.

If I understand this correctly then the behavior before gcc 4.7 was actually
correct: only standard conversions are considered, conversion functions are
not.

[Bug c++/51553] brace initialization and conversion operators

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
clang and EDG give errors for 1, 2, 3, 3a and 4, exactly as GCC used to.

[Bug c++/51553] brace initialization and conversion operators

[david.d.kretzmer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553

--- Comment #6 from david.d.kretzmer at gmail dot com ---
Exactly. I first thought this is a bug in clang but then I saw this invalid bug
report: http://llvm.org/bugs/show_bug.cgi?id=17376

[Bug c++/51553] brace initialization and conversion operators

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Jason, is this resolution definitely correct? Clang and EDG agree with GCC 4.6
here, and [over.best.ics] does seem relevant.

Maybe related, maybe not. G++ also rejects:

struct A {
    explicit operator bool() const { return false; }
};
A a;
bool b = bool{a};

which Clang and EDG accept, and it certainly seems odd when bool(a) and (bool)a
are OK.