[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
--- Comment #9 from roland at gnu dot org ---
IMHO there's a good case to be made for never warning for designated
initializers, even for fields that have uninitialized default-construction.
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.
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};
```
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:0f8f1dee851c23bce19977b2531cf69b4da9f88f commit r14-1657-g0f8f1dee851c23bce19977b2531cf69b4da9f88f Author: Marek Polacek Date: Thu Jun 8 13:52:11 2023 -0400 doc: Clarification for -Wmissing-field-initializers The manual is incorrect in saying that the option does not warn about designated initializers, which it does in C++. Whether the divergence in behavior is desirable is another thing, but let's at least make the manual match the reality. PR c/39589 PR c++/96868 gcc/ChangeLog: * doc/invoke.texi: Clarify that -Wmissing-field-initializers doesn't warn about designated initializers in C only.
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
--- Comment #7 from Marek Polacek ---
A similar test. I'm not sure how we want -Wm-f-i to behave here.
#include
struct A {
int a;
std::optional b;
};
int main()
{
auto x = A {
.a = 123 // warns
};
}
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
--- Comment #6 from Paweł Bylica ---
The workaround is
MyObj obj = {};
which at least suggests some inconsistency in the compiler internals.
For me this warning should be disabled in C++ when designated initializers are
used and all other fields are value initialized.
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868 Andrew Pinski changed: What|Removed |Added CC||chfast at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 107434 has been marked as a duplicate of this bug. ***
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868 Pavel Sergeev changed: What|Removed |Added CC||dzhioev at gmail dot com --- Comment #4 from Pavel Sergeev --- (In reply to Jonathan Wakely from comment #3) > (In reply to Matt Godbolt from comment #2) > > Thanks: I was confused (as I think will many folks be). > > Approximately everybody is confused by -Wmissing-field-initializers which is > why people probably shouldn't use it. > > It specifically says the **initializer** is missing, not that initialization > is missing. But everybody thinks it's telling them the member is > uninitialized. > > The manual is at least clear: > > > the following code causes such a warning, because "x.h" is implicitly zero > > Unfortunately it also says: > > > This option does not warn about designated initializers > > which might be true for C, but not C++. Should it be true for C++? Do you see any reasons why it shouldn't?
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868 --- Comment #3 from Jonathan Wakely --- (In reply to Matt Godbolt from comment #2) > Thanks: I was confused (as I think will many folks be). Approximately everybody is confused by -Wmissing-field-initializers which is why people probably shouldn't use it. It specifically says the **initializer** is missing, not that initialization is missing. But everybody thinks it's telling them the member is uninitialized. The manual is at least clear: > the following code causes such a warning, because "x.h" is implicitly zero Unfortunately it also says: > This option does not warn about designated initializers which might be true for C, but not C++. Should it be true for C++?
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868 --- Comment #2 from Matt Godbolt --- Thanks: I was confused (as I think will many folks be). The examples for designated initialisers in C++20 on cppreference cite this behaviour as being useful^. Of course I understand it can be misused, and this indeed a non-default warning. Thanks for taking the time to reply! --matt ^: https://en.cppreference.com/w/cpp/language/aggregate_initialization#Designated_initializers
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
I think the warning is correct, Test::obj here is initialized from {}, but
that's not what the user might intend.
