2

This is inspired by this post where non-trivial designated initializers are not supported.

I've already read this post and some answers claim this feature is already supported.

However, using C++17 and this code:

struct s {
    int a[2];
    s (int b): a{[1]=b} {} // error
};

s foo(1);

I still get the error:

sorry, unimplemented: non-trivial designated initializers not supported

s (int b): a{[1]=b} {}

I was thinking this feature is really helpful.

So my questions:

Is there a plan to support this for future C++ versions (post C++17)?

  • If not, what is the biggest hindrance why it's not going to be supported
  • If yes, what is the problem with the current C++ version why it takes too long for this to be supported

COMPILER

GNU C++17 - Check wandbox

Joseph D.
  • 11,804
  • 3
  • 34
  • 67
  • related/dupe: https://stackoverflow.com/questions/18731707/why-does-c11-not-support-designated-initializer-lists-as-c99 – NathanOliver Jun 25 '18 at 15:14
  • In the C++ standard, there are alternatives that the C++ committee consider preferable. I'd guess that is unlikely to change, since there is not a compelling argument. With respect to gcc/g++, it comes down to a conscious decision by the compiler developers to not support designated initialisers in their C compiler as well, in favour of a compiler-specific extension. – Peter Jun 25 '18 at 15:19
  • @codekaizer Want me to close this as a duplicate then? – NathanOliver Jun 25 '18 at 15:21
  • @NathanOliver, the accepted answer there doesn't answer my question and perhaps this post can be a reference for 2018 onwards. – Joseph D. Jun 25 '18 at 15:23

1 Answers1

5

The proposal adopted to add designated initializers to C++20 (p0329r0) is limited, intentionally (Note that as an official language feature, it's specifically a C++20 feature - but gcc and clang have supported essentially this feature for a long time already):

enter image description here

C++ is a more complex language than C, and we have more things to worry about. So the rules we get are that you cannot mix designators and values, the designators appear in declaration order, are unique, and are neither nested nor array indices. This is already a very useful language feature, as-is.

If not, what is the biggest hindrance why it's not going to be supported

Motivation, probably. Do we really need that syntax? Is it a problem that needs solving? On the downside, there may be parsing ambiguities - you might be able to construct array index initializers that look a lot like lambdas. But if you think it's sufficiently worthwhile, you could write a proposal.

Barry
  • 286,269
  • 29
  • 621
  • 977
  • You probably want to use wg21.link to point to the [latest version R4](https://wg21.link/p0329) which has a nice section on [what is supported and what is not](https://twitter.com/shafikyaghmour/status/1007671942311133184). Also seems [like clang and gcc support different things in the extension in C++](https://twitter.com/shafikyaghmour/status/1007999011763073024) although maybe clang just donsen't diagnose unsupported features. – Shafik Yaghmour Jun 25 '18 at 15:58
  • @ShafikYaghmour I very explicitly wanted to point to R0 because it's R0 that has the section I screenshotted, R4 is just wording. – Barry Jun 25 '18 at 16:38
  • @Barry, thank you for explaining in detail. I agree with you about the parsing ambiguities. – Joseph D. Jun 26 '18 at 00:08