https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
Méven <meven at kde dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |meven at kde dot org
--- Comment #10 from Méven <meven at kde dot org> ---
(In reply to Roland McGrath from comment #9)
> IMHO there's a good case to be made for never warning for designated
> initializers, even for fields that have uninitialized default-construction.
My opinion would be only pointers should warn and maybe not the smart ones as
semantically they do accept "null"/none state.
> When using a designated initializer, `= {.a=value}` doesn't leave any field
> `b` uninitialized, it initializes it as `= {}` would, i.e. safely zero for
> base types, etc. When I write `= {.a=value}` that
> default-or-zero-initialization of the other fields is exactly what I
> intended, and I know well that omitted fields in an initializer are
> different from leaving the fields uninitialized.
Indeed that's C++ semantics RAII.
>
> Clearly opinions on this vary. It seems like it merits having separable
> option configuration: `-Wmissing-field-initializers`,
> `-Wmissing-designated-field-initializers`. If that flexibility is available,
> then it's of less concern what the default state with just
> `-Wmissing-field-initializers` or `-Wextra` is.
>
> The separate question remains whether "missing initializer" vs "missing
> (explicit) initialization" should also be distinguished differently in the
> available warning states than what we have today. I don't have much opinion
> about that one as long as there's a way for me to say that:
> ```
> struct s { int a, b; };
> s foo = {.a=1};
> ```
> is acceptable without warning in C++, even if it requires a different option
> state than to accept:
> ```
> struct s { int a; int b = 0; };
> s foo = {.a=1};
> ```
This is giving a lot of users some headaches, to have to opt-in
-Wno-missing-field-initializers when it does not really bring any value in C++.
