`modernize-use-designated-initializers` reported for pre-C++20 code

[firewave]

struct S
{
    int i1;
    int i2;
};

void f()
{
    S s{0};
}

Running with -std=c++11 produces the following warning:

<source>:9:8: warning: use designated initializer list to initialize 'S' [modernize-use-designated-initializers]
    9 |     S s{0};
      |        ^~~
      |         .i1=
<source>:1:1: note: aggregate type is defined here
    1 | struct S
      | ^

https://godbolt.org/z/EzerEWsKh

Designated initializers are not available until C++20: https://en.cppreference.com/w/cpp/language/aggregate_initialization.

CC @SimplyDanny @PiotrZSL

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Oliver Stöneberg (firewave)

```cpp struct S { int i1; int i2; };

void f()
{
S s{0};
}

Running with `-std=c++11` produces the following warning:

<source>:9:8: warning: use designated initializer list to initialize 'S' [modernize-use-designated-initializers]
9 | S s{0};
| ^~~
| .i1=
<source>:1:1: note: aggregate type is defined here
1 | struct S
| ^

https://godbolt.org/z/EzerEWsKh

Designated initializers are not available until C++20: https://en.cppreference.com/w/cpp/language/aggregate_initialization.

CC @<!-- -->SimplyDanny @<!-- -->PiotrZSL 
</details>

[EugeneZelenko]

@SimplyDanny

[SimplyDanny]

In the review, @PiotrZSL noted that designated initializers often work even with older compiler versions. That's why we decided against the restriction to C++20.

[firewave]

Interesting - I wasn't aware of that.

A short test show they actually do work in C++11 mode with Clang 3.5 and GCC 5.1 which are the oldest compilers we need to support.

But they do not work with Visual Studio until cl v19.21 (which appears to be Visual Studio 2019 16.1) and only if you enable /std:c++latest. Visual Studio 2017 is still supported until 2027 and the oldest we still have to support is VS2015.

Unfortunately there is no AppleClang in Godbolt so I cannot test if they are available in that.

[carlosgalvezp]

often work even with older compiler versions

That's not true if you enable -pedantic (a.k.a Standards conformat, which most projects should do). Please ensure this warning is only enabled on C++20, this feature is not available until then.

[PiotrZSL]

That's not true if you enable -pedantic (a.k.a Standards conformat, which most projects should do). Please ensure this warning is only enabled on C++20, this feature is not available until then.

We use it with C++17 now, and before that we used it even before C++11 as GCC extension.
With latest Clang you can use "-std=c++17 -Wall -pedantic -Wno-c++20-designator", and everything work fine.

https://godbolt.org/z/77d5jM7T3

You can use it also in C: https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

[carlosgalvezp]

Of course, that's disabling the warning :) A clang-tidy check should not require people to disable compiler warnings.

Designated initializers is a C++20 feature according to the C++ Standard. The fact that compilers implement it earlier is a compiler extension. Compiler extensions are forbidden in certain coding standards, e.g. MISRA, AUTOSAR, etc. That's why -pedantic exists, to ensure no compiler extensions are enabled and the code is Standards-conformant.

Yes, this feature is part of the C standard since long time ago, only made it into C++ in C++20 for some reason.

If this is wanted, it should be handled as an opt-in option (off by default).

[carlosgalvezp]

WDYT @AaronBallman @njames93 ?

[PiotrZSL]

I see 2 options:
a) This check is not enabled by default, so user may not enable it if not needed.
b) If user use modernize-* to enable all checks, then in theory some option like "EnableBeforeCpp20" (or something else) could be added, but still modernize-* got already other checks like modernize-use-trailing-return-type that probably user may want to disable anyway.

[AaronBallman]

I don't think it's a problem to recommend using designated initializers in pre-C++20 mode as that's a documented (https://clang.llvm.org/docs/LanguageExtensions.html#language-extensions-back-ported-to-previous-standards), conforming language extension we support. By default, I think we should silence modernize-use-designated-initializers in C++20 mode as that's the behavior of other modernization checks.

That said, I think it's reasonable to give users control over whether they get the recommendation in pre-C++20 mode or not. We could use a configuration option for this, or we could explore making clang-tidy aware of -pedantic mode being enabled in Clang (and disable the recommendation in -pedantic mode). For example modernize-unary-static-assert, modernize-use-nodiscard, and modernize-use-auto are all disabled in older modes but the extensions are supported by Clang in older modes. It would be nice to have a consistent option for users so they don't have to configure each check if they're comfortable relying on extensions.

[PiotrZSL]

Maybe then some generic option that would be added by default to every check to skip language checks for that check. In such case user could configure: modernize-use-auto.SkipLanguageCheck: On or something like that or something like with WarningsAsErrors option.