[Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization

[Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization

[schaub.johannes at googlemail dot com]

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

           Summary: Various non-conforming behaviors with braced-init-list
                    initialization
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: schaub.johannes@googlemail.com


According to n3225, GCC is apparently not conforming to the latest specs. The
following points out some flaws. 

    // should be invalid (takes bullet 5 of 8.5p16, for data-member a)
    // incorrectly accepted by GCC.
    struct A { int a[2]; A():a({1, 2}) { } };

The spec is not clear about what behavior the following should exhibit
according to 8.5p16. As long as it's not cleared up, GCC should reconsider
whether it's desirable to accept it, it seems:

    int a({0}); // spec is not clear. doesn't define this case?

The following is ill-formed, because it takes bullet 2 and then hits 8.5.3p1:

    int const &b({0}); // incorrectly accepted by GCC

If both of those have different meanings with regard to validity, this is very
disgusting. 

In short, the intent seems to be that a "({ ... })" initializer is only allowed
for class types, where it will hit 8.5.16p6. That's the only valid way such an
initialize can be interpreted for classes, in order not to accept the following

    struct A { explicit A(int, int); };
    A a({1, 2}); // this must be invalid, and GCC correctly rejects it.

In the end, I think the spec is very unclear about this, and GCC possibly
should reconsider some of its behavior here.

[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

[schaub.johannes at googlemail dot com]

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

Johannes Schaub <schaub.johannes at googlemail dot com> changed:

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

--- Comment #1 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-01-25 03:16:21 UTC ---
Adding Jason. AFAIK he's implemented this for GCC.

[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

[schaub.johannes at googlemail dot com]

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

--- Comment #2 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-01-25 03:37:01 UTC ---
(In reply to comment #0)
> In short, the intent seems to be that a "({ ... })" initializer is only allowed
> for class types, where it will hit 8.5.16p6. 
>

I'm sorry. I meant 8.5p16 bullet 6. I don't want to add unnecessarily more
confusion to this :)

[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

[schaub.johannes at googlemail dot com]

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

--- Comment #3 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-05-12 05:23:15 UTC ---
I think we have the FDIS clear about these cases now. To update:

    // invalid
    struct A { int a[2]; A():a({1, 2}) { } };

    // invalid
    int a({0});

    // invalid
    int const &b({0});

    struct A { explicit A(int, int); A(int, long); };

    // invalid
    A c({1, 2});

    // valid (by copy constructor).
    A d({1, 2L});

    // valid
    A e{1, 2};

    struct B { 
      template<typename ...T>
      B(initializer_list<int>, T ...); 
    };

    // invalid (the first phase only considers init-list ctors)
    // (for the second phase, no constructor is viable)
    B f{1, 2, 3};

    // valid (T deduced to <>).
    B g({1, 2, 3});

[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

[d.v.a at ngs dot ru]

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

__vic <d.v.a at ngs dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d.v.a at ngs dot ru

--- Comment #4 from __vic <d.v.a at ngs dot ru> 2011-07-29 06:08:29 UTC ---
struct A { int a[2]; A():a({1, 2}) { } };

Should be valid. Example:

class cond_variable
{
    ::pthread_cond_t cond;
public:
    constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
};

What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
accepted in any case? Uniform initialization initially address this issue.

Out of constructor one can use "=":

::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

In constructor init-list "=" is prohibited therefore "()" must play a same
role.

[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

[schaub.johannes at googlemail dot com]

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

--- Comment #5 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-07-29 12:23:35 UTC ---
(In reply to comment #4)
> struct A { int a[2]; A():a({1, 2}) { } };
> 
> Should be valid. Example:
> 
> class cond_variable
> {
>     ::pthread_cond_t cond;
> public:
>     constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
> };
> 
> What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
> accepted in any case? Uniform initialization initially address this issue.
> 

Why not say

    constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }


> Out of constructor one can use "=":
> 
> ::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
> 

You can define it as follows to make it work in both cases

    #define PTHREAD_COND_INITIALIZER {}

[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

[d.v.a at ngs dot ru]

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

--- Comment #6 from __vic <d.v.a at ngs dot ru> 2011-08-02 03:25:10 UTC ---
> 
> Why not say
> 
>     constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }
> 

What if PTHREAD_COND_INITIALIZER is a just scalar?

> 
> You can define it as follows to make it work in both cases
> 
>     #define PTHREAD_COND_INITIALIZER {}

I cannot define/redefine this value. It's already defined in system headers...

[Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.08.03 18:52:08
         AssignedTo|unassigned at gcc dot       |jason at gcc dot gnu.org
                   |gnu.org                     |
            Summary|Various non-conforming      |[DR 1214] Various
                   |behaviors with              |non-conforming behaviors
                   |braced-init-list            |with braced-init-list
                   |initialization              |initialization
     Ever Confirmed|0                           |1

[Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization

[schaub.johannes at googlemail dot com]

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

--- Comment #7 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-08-03 19:17:04 UTC ---
(In reply to comment #6)

> > 
> > You can define it as follows to make it work in both cases
> > 
> >     #define PTHREAD_COND_INITIALIZER {}
> 
> I cannot define/redefine this value. It's already defined in system headers...

Ah I wasn't aware. You can at least workaround it though.

class cond_variable
{
    struct { ::pthread_cond_t cond; } wrapper;

public:
    constexpr cond_variable() : wrapper{PTHREAD_COND_INITIALIZER} {}
};

[Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-05 19:15:27 UTC ---
Author: jason
Date: Fri Aug  5 19:15:25 2011
New Revision: 177480

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177480
Log:
    PR c++/47453
    * typeck.c (build_x_compound_expr_from_list): Also complain
    about ({...}).

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist56.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist13.C
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist50.C

[Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization

[jason at gcc dot gnu.org]

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

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

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

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-05 19:37:30 UTC ---
Implemented for 4.7.0.  Currently this diagnostic is a pedwarn, i.e. only an
error with -pedantic-errors.