[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
--- Comment #22 from David Friberg ---
(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
> #include
>
> void f(std::array, 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
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #21 from TC ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |ASSIGNED --- Comment #20 from Jonathan Wakely --- Un-suspending based on the previous comment.
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
David Friberg changed:
What|Removed |Added
CC||davveston at gmail dot com
--- Comment #19 from David Friberg ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #18 from Martin Liška --- Can the bug be marked as resolved?
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 --- Comment #17 from Jonathan Wakely --- Jason, should this be FIXED instead of SUSPENDED?
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 Andrew Pinski changed: What|Removed |Added Target Milestone|4.9.0 |---
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 --- Comment #15 from Jason Merrill --- Author: jason Date: Sat Oct 24 02:58:10 2015 New Revision: 229283 URL: https://gcc.gnu.org/viewcvs?rev=229283=gcc=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 --- Comment #16 from Jason Merrill --- 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
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
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
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.
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
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=222836root=gccview=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
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
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.
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||f.heckenb...@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
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
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
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=gccview=revrev=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
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.
