Designated initializers?

[David Van Cleve]

Do we support designated initializers in Chromium C++?

struct Struct {

  int x = 3;

  int y = 4;

};

Struct my_struct {.y = 5};

[Ryan Sleevi]

https://google.github.io/styleguide/cppguide.html#Nonstandard_Extensions says no

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAMeJurf9D7kXnxMG-oXPm0uL1PYa86D1x-XyTi7G8DkU1LtxaA%40mail.gmail.com.

[Peter Kasting]

There has been a bit of debate on this one, since clang apparently allows them as an extension even in --std=c++14 mode, and there are certainly situations where they aid readability.

My personal take is: we should never intentionally rely on nonstandard behavior unless we have no alternative; this is nonstandard behavior in C++14 mode, which is what we compile in; this is used for cleanup sorts of reasons, which isn't a "no alternative" scenario; therefore, we should not use this (yet).

The current public style guide agrees, explicitly mentioning designated initializers as an example ( http://google.github.io/styleguide/cppguide.html#Nonstandard_Extensions ).

However, the current internal style guide (and thus, likely at some unspecified future point, the public style guide) allows these if they are in their C++20-compliant form despite overall only being in C++17 mode: go/cstyle#Designated_initializers .

Ways to resolve the tensions here:

(1) Argue that the time delta before Google internally can use C++20 is likely reasonably short, so the window where this is technically nonstandard is going to be minimal; Chromium differs in that C++20 is not on the foreseeable horizon for us, so allowing C++20-specific behavior is inherently more risky.

(2) Argue that Google internally can declare "we support exactly one toolchain, library implementation, etc." and thus the risk of relying on "nonstandard" behavior is lower; Chromium differs in that while we have a reasonably-minimal "officially-supported" toolchain etc., we do have other toolchains and library implementations that we accept community patches for, and we know there are downstream users.

(3) Argue that the upstream rationale is "it's OK to rely on future-standard behavior when it doesn't break things", check that such code doesn't break things for us (I think it doesn't, since I think people have added such usage already??), and decide that Chromium should allow these same initializers.

(4) Any of the above, except we wait to have that debate until the internal guide's changes move to the public guide; maybe that will take long enough that the situation will meaningfully change in the meantime.

To me (2) is probably the most compelling-on-principle general reason to not do things like this, (1) is valid-in-this-case but also probably not hugely compelling (since things aren't going to change much for designated initializers in the next several years other than perhaps to allow a broader set in C++23 or later), and while (3) grates on me I could live with it if that was consensus.

PK