Hacker News Reader

Comment by makapuf | Hacker News Reader

It is to be noted that designated struct initializers will be/are in C++20 (of course it has all the features, it's C++). See it here: https://en.cppreference.com/w/cpp/language/aggregate_initial...

View on HN

The C++ version is much worse. "Note: out-of-order designated initialization, nested designated initialization, mixing of designated initializers and regular initializers, and designated initialization of arrays are all supported in the C programming language, but are not allowed in C++.”

Arrays designed to be indexed by an enum is a pattern I use all the time in C and designated initializers make it a whole lot safer and reduce the likelihood of a bug when refactoring.

The out of order initialisation is not supported because it would be confusing with the order of destruction. Note that initializing the members in a constructor in a different order is allowed, but they are actually still initialized in the declaration order. That's quite confusing and most compiler warn about that. So in a way it's good the same mistake was not done in designated initialized.

I don't know why the array notation is not allowed in C++.

Apparently the array initialization clashes with lambda syntax.

Regarding all the restrictions added in C++20:

Clang supported the full C99 designated intiialization feature set in C++ without any issues long before C++20, so the decision by the C++ Committee to add those restrictions is quite baffling, considering that there is a solid implementation in the wild that has been working just fine for many years.

Unfortunately the restrictions added in C++20 make designated initialization quite pointless for any structs or classes with more than a handful items. Having to remember the order of initialization is too much hassle in this case.

That's what I thought too, until I actually used them extensively. The compiler tells you the correct order when you get it wrong, and I'm sure if you used an IDE (I don't) it would help you as well. And that was with Vulkan, everything in that API is done by creating structs with way too many members.

That sounds like a game of Tetris though, with or without IDE support ;) It would have been better if C++ treated structs like C structs, not like classes, but too late for that I guess.

This completely ignores the advantages they have in code readability and reliability.

I can well deal with a little extra effort to order the initializations for those benefits.

Now, if you complained about the burden on refactoring member orders it poses on the other hand?

Reply on news.ycombinator.com