[Bug c++/113124] New: g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[Bug c++/113124] New: g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[adobriyan at gmail dot com]

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

            Bug ID: 113124
           Summary: g++ should relax designated initialiser rules for
                    trivial classes (read: C structures) and C arrays.
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adobriyan at gmail dot com
  Target Milestone: ---

Currently, the rules do not allow reordering member initialisation:

    struct S {
        int a;
        int b;
    };
    S s{.b = 1, .a = 2}; // error

or skipping array element initialisation:

    int a[2] = {[1] = 1}; // error

First, clang++ allows it with warnings which can be silenced.

Second, both restrictions are major problem for converting C projects to C++
if C99 initialisers are used often.

I have bootable Linux compiled with g++ and it became obvious that some changes
are such pain points:
1) implicit casts from void* to T*,
2) "broken" C99 initializers (which Linux uses a lot),
3) pointer arithmetic ("void* + int" and "void* - void*").

(1) and (3) happen _a_lot_ but they aren't a problem, because they aren't a
flag day, casts can be added little by little to any project willing to convert
to C++.

However, (2) is a flag day with g++, suddenly lot of stuff won't compile.
Fixing this requires giving up _nice_ C99 feature which people are used to.
As you all know, reodering struct members doesn't force to change all
initialisers.

But at the moment of doing gcc => g++ flip every single structure becomes
trivial class(?) and restrictions apply.

Linux is _full_ of these misordered initialisations:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/fops.c?h=v6.7-rc6#n838
(the order is .llseek, .read_iter, ...)

Arrays can be even more painful:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/mem.c?h=v6.7-rc6#n685

Note, that the last element is undef ifdef, so less space is wasted,
so giving this array size requires constexpr variable and duplicating ifdefs.

Sometimes it is not obvious which elements are reordeded or missing:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ethtool/common.c?h=v6.7-rc6#n11

Reordered C99 initialisers create problems with maintaining patchset.
Reapplying on top of new version may create some rejects, which are painful for
a human to fix: members can be added/deleted/reorders in main code and then
patch is reordering some members too, so duplicate initializations can appear
if done wrong,
or more importantly, some initializers can be lost (which is null function
pointer dereference somewhere). I've started to redo every initialisers from
scratch just to minimise about of breakage, otherwise it is very easy to miss
stuff.

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[adobriyan at gmail dot com]

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

--- Comment #1 from Alexey Dobriyan <adobriyan at gmail dot com> ---
This is getting lengthy:

Please allow C99 semantics for "simple enough" stuff (read: C structs):
* allow reordering
* allow duplicating (possibly with warning), 
* allow holes in the middle of arrays (1- and multi-dimensional).

because
a) clang++ can do it
b) there is not reason no to (for simlpe structs)
c) any C to C++ converter can claim that this part of conversion is correct at
the moment of gcc/g++ flip without very painful reaudit of all initialisers.

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[adobriyan at gmail dot com]

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

--- Comment #2 from Alexey Dobriyan <adobriyan at gmail dot com> ---
this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99081
but I don't care about the warning, only about error

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Is this a reasonable extension maybe. But this is an extension to the language
after all.

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
When you say C structures here you mean the standard layout types (or the C++98
older definition of PODs)? Or do you mean structure types which has no member
functions/constructors at all?

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[adobriyan at gmail dot com]

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

--- Comment #5 from Alexey Dobriyan <adobriyan at gmail dot com> ---
My standardspeak is very bad.

I think std::is_trivial_v types should have relaxed initialisation ordering,
because all C structs and unions are std::is_trivial_v.

If I understand this stuff correctly, ordering became stricter because of
interaction with ctor ordering which is Very Important in C++.

But if there are no ctors, then there is no problem to begin with.

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

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

--- Comment #6 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Today we really don't want to introduce fancy C++ extensions.  Have you sent
this as a proposal to the standard committee?

FWIW the Linux kernel code base is not relevant because Linus has absolutely no
intention to allow using C++ there.

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[adobriyan at gmail dot com]

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

--- Comment #7 from Alexey Dobriyan <adobriyan at gmail dot com> ---
> fancy C++ extension

It is not fancy.

C99 initialisers is the only feature where Modern C beats Modern C++.

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[xry111 at gcc dot gnu.org]

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

--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Alexey Dobriyan from comment #7)
> > fancy C++ extension
> 
> It is not fancy.
> 
> C99 initialisers is the only feature where Modern C beats Modern C++.

Fancy or not you should ask the standard committee first.

If they say "hey this is useful but we'd like to see an implementation first"
we can add it as an extension.

[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-01-11
                 CC|                            |jason at gcc dot gnu.org

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> ---
Doing this for constant initializers for C compatibility makes sense to me. 
But it isn't just a matter of adjusting the diagnostic, we would also need to
actually do the sorting to make the initialization work.  Still probably not
that much work, but not trivial.