[Bug c++/54835] New: [C++11] Explicit default constructors not respected during copy-list-initialization

[Bug c++/54835] New: [C++11] Explicit default constructors not respected during copy-list-initialization

[daniel.kruegler at googlemail dot com]

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

             Bug #: 54835
           Summary: [C++11] Explicit default constructors not respected
                    during copy-list-initialization
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: daniel.kruegler@googlemail.com


gcc 4.8.0 20120930 (experimental) with the compiler flags

-Wall -pedantic -std=c++11 

accepts the following copy-list-initialization of a class type with an explicit
default constructor:

//-------------------------
struct S {
  explicit S(int = 0) {}
};

S s = {};
//-------------------------

This code should be ill-formed, because it is ruled out by [over.match.list],
in particular by the unconditional wording:

"In copy-list-initialization, if an explicit constructor is chosen, the
initialization is ill-formed."

[Bug c++/54835] [C++11] Explicit default constructors not respected during copy-list-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-01-24
     Ever Confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-24 13:32:34 UTC ---
confirmed, not a regression

[Bug c++/54835] [C++11] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> 2013-02-15 20:56:04 UTC ---
It's not clear to me that [over.match.list] applies to this initialization,
since the value-initialization bullet is separate from the bullet that
cross-references [over.match.list].  And in fact there's code in
convert_like_real specifically to avoid this diagnostic because of this
difference, and it's tested for in initlist40.C.

I'm not opposed to this behavior, but I think it would be a language change.

[Bug c++/54835] [C++11] Explicit default constructors not respected during copy-list-initialization

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-02-16 11:57:21 UTC ---
(In reply to comment #2)
> I'm not opposed to this behavior, but I think it would be a language change.

Thanks Jason. I just see now

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1518

Unless I'm mistaken, this is actually the relevant issue. I suggest to defer
this issue and mark it with CWG 1518. I'm not sure how this would be best done,
so leave it to the administrators of this list.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jason at gcc dot gnu.org
                   |gnu.org                     |
            Summary|[C++11] Explicit default    |[C++11][DR 1518] Explicit
                   |constructors not respected  |default constructors not
                   |during                      |respected during
                   |copy-list-initialization    |copy-list-initialization

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> 2013-02-16 15:02:22 UTC ---
Ah, good point.  I think we decided in Portland to go with the behavior you
expect; all that's left is the drafting (which is also for me to do).  Thanks.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> 2013-03-17 02:36:25 UTC ---
Author: jason
Date: Sun Mar 17 02:36:08 2013
New Revision: 196732

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196732
Log:
    DR 1518
    PR c++/54835
    * call.c (convert_like_real): Check for explicit constructors
    even for value-initialization.

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

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> 2013-03-23 05:11:37 UTC ---
Ah, good point.  I think we decided in Portland to go with the behavior you
expect; all that's left is the drafting (which is also for me to do).  Thanks.

Fixed for 4.9.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> 2013-03-23 05:12:08 UTC ---
x

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |f.heckenbach@fh-soft.de

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 58399 has been marked as a duplicate of this bug. ***

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> ---
I believe that the resolution of DR 1630 clarifies that value-initialization
can invoke an explicit constructor even in copy-list-initialization context, so
I should revert my change for this PR.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[daniel.kruegler at googlemail dot com]

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

--- Comment #10 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Jason Merrill from comment #9)
> I believe that the resolution of DR 1630 clarifies that value-initialization
> can invoke an explicit constructor even in copy-list-initialization context,
> so I should revert my change for this PR.

I read DR 1630 again and cannot follow that conclusion - could you clarify? It
still says "For copy-initialization, the candidate functions are all the
converting constructors (12.3.1 [class.conv.ctor]) of that class" and the issue
example uses an explicit default constructor.
>From gcc-bugs-return-485440-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 04 18:35:09 2015
Return-Path: <gcc-bugs-return-485440-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 91850 invoked by alias); 4 May 2015 18:35:09 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 91809 invoked by uid 48); 4 May 2015 18:35:06 -0000
From: "daniel.f.starke at freenet dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build
Date: Mon, 04 May 2015 18:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords: lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: daniel.f.starke at freenet dot de
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65995-4-m2KpX1Dhuq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65995-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65995-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg00280.txt.bz2
Content-length: 284

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide995

--- Comment #2 from Daniel Starke <daniel.f.starke at freenet dot de> ---
I already applied the open() patch listed there so this is definitively a
different bug. I will try again with the current trunk hopefully within this
week.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Wed May  6 02:07:34 2015
New Revision: 222836

URL: https://gcc.gnu.org/viewcvs?rev=222836&root=gcc&view=rev
Log:
        DR 1518
        DR 1630
        PR c++/54835
        PR c++/60417
        * call.c (convert_like_real): Check value-initialization before
        explicit.
        * typeck2.c (process_init_constructor_record): Don't set
        CONSTRUCTOR_IS_DIRECT_INIT.
        (process_init_constructor_array): Likewise.
        * init.c (build_vec_init): Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist-dr1518.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/cp/init.c
    trunk/gcc/cp/typeck2.c
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist40.C

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Daniel Krügler from comment #10)
> I read DR 1630 again and cannot follow that conclusion - could you clarify?
> It still says "For copy-initialization, the candidate functions are all the
> converting constructors (12.3.1 [class.conv.ctor]) of that class" and the
> issue example uses an explicit default constructor.

Yes, but the previous sentence now says "For direct-initialization or
default-initialization, the candidate functions are all the constructors of the
class of the object being initialized."  This is default-initialization by way
of value-initialization, so I think this sentence takes priority over the one
you quote.
>From gcc-bugs-return-485680-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 06 19:23:30 2015
Return-Path: <gcc-bugs-return-485680-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 129363 invoked by alias); 6 May 2015 19:23:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 129335 invoked by uid 48); 6 May 2015 19:23:25 -0000
From: "jrm at exa dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/66022] 4.8.4 build fails with stage 2 and 3 comparison error
Date: Wed, 06 May 2015 19:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.8.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jrm at exa dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66022-4-c3uNHYybbh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66022-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66022-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg00520.txt.bz2
Content-length: 2283

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf022

--- Comment #1 from James Mason <jrm at exa dot com> ---
Using the same machine and shell script (save changing the version variable
from "gcc-4.8.4" to "gcc-4.9.2"), a nearly identical failure occurs:

gmake[2]: Entering directory `/opt/BUILD-gcc-4.9.2'
gmake[3]: Entering directory `/opt/BUILD-gcc-4.9.2'
rm -f stage_current
gmake[3]: Leaving directory `/opt/BUILD-gcc-4.9.2'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/coverage.o differs
gcc/asan.o differs
gcc/gimple-ssa-strength-reduction.o differs
gcc/graphite-poly.o differs
gcc/plugin.o differs
gcc/ipa-devirt.o differs
gcc/sel-sched-ir.o differs
gcc/graphite-dependences.o differs
gcc/tree-ssa-phiopt.o differs
gcc/passes.o differs
gcc/graphite-scop-detection.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/bitmap.o differs
gcc/dwarf2cfi.o differs
gcc/graphite.o differs
gcc/sel-sched.o differs
gcc/ggc-common.o differs
gcc/store-motion.o differs
gcc/graphite-sese-to-poly.o differs
gcc/tree-sra.o differs
gcc/tree-ssa-uncprop.o differs
gcc/graphite-blocking.o differs
gcc/ira-costs.o differs
gcc/graphite-interchange.o differs
gcc/lto/lto.o differs
gcc/cfg.o differs
gcc/postreload-gcse.o differs
gcc/dse.o differs
gcc/ira-color.o differs
gcc/tree-ssa-sccvn.o differs
gcc/graphite-optimize-isl.o differs
gcc/tree-into-ssa.o differs
gcc/cselib.o differs
gcc/tree-ssa-structalias.o differs
gcc/tree-ssa-dom.o differs
gcc/tree-complex.o differs
gcc/tree-eh.o differs
gcc/tree-ssa-pre.o differs
gcc/haifa-sched.o differs
gcc/trans-mem.o differs
gcc/tree-cfg.o differs
gcc/var-tracking.o differs
gcc/tree-ssa-loop-im.o differs
gcc/sched-deps.o differs
gcc/gcse.o differs
gcc/tree-pretty-print.o differs
gcc/tree-ssa-tail-merge.o differs
gcc/lto-streamer-in.o differs
gcc/cp/class.o differs
gcc/cp/semantics.o differs
gcc/cp/error.o differs
gcc/vtable-verify.o differs
gcc/alloc-pool.o differs
gcc/tree-ssa-threadupdate.o differs
gcc/tree-ssa-strlen.o differs
gcc/loop-iv.o differs
gmake[2]: *** [compare] Error 1
gmake[2]: Leaving directory `/opt/BUILD-gcc-4.9.2'
gmake[1]: *** [stage3-bubble] Error 2
gmake[1]: Leaving directory `/opt/BUILD-gcc-4.9.2'
gmake: *** [all] Error 2

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ville.voutilainen at gmail dot com

--- Comment #13 from Jason Merrill <jason at gcc dot gnu.org> ---
*** Bug 66537 has been marked as a duplicate of this bug. ***

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |SUSPENDED
         Resolution|FIXED                       |---

--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> ---
Suspended pending resolution of DR 1518.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Sat Oct 24 02:58:10 2015
New Revision: 229283

URL: https://gcc.gnu.org/viewcvs?rev=229283&root=gcc&view=rev
Log:
        DR 1518
        DR 1630
        PR c++/54835
        PR c++/60417
        * call.c (convert_like_real): Value-initialization can't use
        explicit constructors in C++11 and up.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/explicit10.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist40.C
    trunk/gcc/testsuite/g++.dg/init/explicit1.C
    trunk/gcc/testsuite/g++.dg/init/explicit2.C

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill <jason at gcc dot gnu.org> ---
Since the last meeting it has been suggested that this effect of DR 1630 was
unintended, and the testcase should be ill-formed.  So I've changed it back.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[davveston at gmail dot com]

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

David Friberg <davveston at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davveston at gmail dot com

--- Comment #19 from David Friberg <davveston at gmail dot com> ---
Note that this bug report was marked as suspended based on the resolution of
CWG 1518 (and the related DR 1630) in June 2015, but the resolution of both
these issue were since changed. Citing 1518:

> Additional note, October, 2015:
> 
> It has been suggested that **the resolution of issue 1630 went too**
> far in allowing use of explicit constructors for default initialization, 
> and that default initialization should be considered to model copy 
> initialization instead. The resolution of this issue would provide an
> opportunity to adjust that.

P0398R0 [1] describes the final resolution to CWG 1518, after which the
following example is arguably well-formed:

 struct tag_t {
     explicit constexpr tag_t() = default;  // #3
 };

 struct S {
     constexpr S() {}
     constexpr S(S const&) {}
     S& operator=(S const&) { return *this; }
     S& operator=(tag_t) { return *this; }     // #1
 };

 int main() {
     S s{};
     s = {};  // #2: GCC error: ambiguous overload for 'operator='
 }


as (at least from C++17) #1 is not a viable overload for the assignment at #2,
as tag_t is not an aggregate and copy-list-init from empty braces will not
consider the ctor #3 as it is explicit.

The example above is rejected by GCC (various versions) for both C++17 and
C++20, whereas Clang and MSVC both accepts it (curiosly Clang accepts it also
for C++11 for C++14, which may be wrong as tag_t is an aggregate for these
case, but I'm unsure, as we are covering a lot of CWG/LWG/DR confusion for this
issue).

---

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0398r0.html

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |ASSIGNED

--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Un-suspending based on the previous comment.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[rs2740 at gmail dot com]

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

TC <rs2740 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rs2740 at gmail dot com

--- Comment #21 from TC <rs2740 at gmail dot com> ---
(In reply to David Friberg from comment #19)
> 
> P0398R0 [1] describes the final resolution to CWG 1518, after which the
> following example is arguably well-formed:
> 

It's not. Explicitness of a constructor is not considered when forming implicit
conversion sequences from a braced-init-list, and therefore the assignment is
ambiguous because {} can convert to either S or tag_t, even though the latter
is ill-formed if actually used.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[davveston at gmail dot com]

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

--- Comment #22 from David Friberg <davveston at gmail dot com> ---
(In reply to TC from comment #21)
> (In reply to David Friberg from comment #19)
> > 
> > P0398R0 [1] describes the final resolution to CWG 1518, after which the
> > following example is arguably well-formed:
> > 
> 
> It's not. Explicitness of a constructor is not considered when forming
> implicit conversion sequences from a braced-init-list, and therefore the
> assignment is ambiguous because {} can convert to either S or tag_t, even
> though the latter is ill-formed if actually used.

TC, thanks for the clarification. Just to be sure I'm not missing something, I
was under the impression that the [**emphasis**]

> For direct-initialization or default-initialization
> **that is not in the context of copy-initialization**, 
> the candidate functions are all the constructors of 
> the class of the object being initialized.

part of [over.match.ctor]/1 [1], which was added in P0398R0, intended to remove
non-converting (explicit) constructors from overload resolution in this
context, particularly resolving the issue shown in the original example of LWG
issue 251 [2]:


> That turns out to be very unfortunate, consider the following:
>
> #include <memory>
> #include <array>
>
> void f(std::array<int, 1>, int) {} // #1
> void f(std::allocator_arg_t, int) {} // #2
>
> int main()
> {
>   f({}, 666); // #3
> }
> 
> The call at #3 is ambiguous.

after which the call at #3 in the LWG example above is no longer ambiguous
(afaict). I may be missing some subtlety here, but does my example above not
fall into the same category as this one?

[1] https://timsong-cpp.github.io/cppwp/n4861/over.match.ctor#1
[2] https://cplusplus.github.io/LWG/issue2510