2 ms·
> but it is so much restricted that it's nearly useless. that's a pretty harsh take on it - how would you design it considering that initialization order has t
by jcelerier 6y ago
> but it is so much restricted that it's nearly useless.
that's a pretty harsh take on it - how would you design it considering that initialization order has to be respected (else a lot of use cases would break; it's definitely not uncommon to have a member of a struct to depend on a previous member being initialized) ?
I have yet to find a particularly blocking use of the feature when test-driving it - it's on the other hand a great boon for readability (and definitely puts a nail in the coffin of named function parameters proposals imho).
- flohofwoe 6y agoThe ordering requirement is indeed the biggest problem once you have structs with more than a handful of items (maybe one day Intellisense will help with this problem), but the missing array access and not being able to "chain" designators (.a.b.c = ...) are also painful omissions. Clang has demonstrated long before C++20 that it is possible to use the full C99 designated-init feature set in C++, so I really don't understand why the C++ Committee had to cut down the feature when there was already a fully working implementation. PS: as an example for where C++20 designated initialization breaks down, see for instance [1], I tried to replicate this code in C++20, but quickly gave up (with the main problem being that it is impossible to remember the correct declaration order in big "option bag" structs like this. [1] https://github.com/floooh/sokol-samples/blob/e0a93a21b17a6633574fcb8a5eba266e96b9d460/sapp/cube-sapp.c#L82-L100 https://github.com/floooh/sokol-samples/blob/e0a93a21b17a663...