Why does C++11 not support designated initializer lists as C99?

On July 15 '17 P0329R4 was accepted into the c++20 standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf
This brings limited support for c99's Designated Initializers. This limitation is described as follows by C.1.7[diff.decl].4, given:

struct A { int x, y; };
struct B { struct A a; };

The following Designated Initializations, which are valid in C, are restricted in C++:

• struct A a = { .y = 1, .x = 2 } is invalid in C++ because designators must appear in the declaration order of the data members
• int arr[3] = { [1] = 5 } is invalid in C++ because array designated initialization is not supported
• struct B b = {.a.x = 0} is invalid in C++ because designators cannot be nested
• struct A c = {.x = 1, 2} is invalid in C++ because either all or none of the data members must be initialized by designators

---

For c++17 and earlier Boost actually has support for Designated Intializers and there have been numerous proposals to add support to the c++ standard, for example: n4172 and Daryle Walker's Proposal to Add Designation to Initializers. The proposals cite implementation of c99's Designated Initializers in Visual C++, gcc, and Clang claiming:

We believe the changes will be relatively straightforward to implement

But the standard committee repeatedly rejects such proposals, stating:

EWG found various problems with the proposed approach, and didn't think it's feasible to try solving the problem, as it has been tried many times and every time it has failed

Ben Voigt's comments have helped me to see the insurmountable problems with this approach; given:

struct X {
    int c;
    char a;
    float b;
};

What order would these functions be called in in c99: struct X foo = {.a = (char)f(), .b = g(), .c = h()}? Surprisingly, in c99:

The order of evaluation of the subexpressions in any initializer is indeterminately sequenced ^[1]

(Visual C++, gcc, and Clang seem to have an agreed upon behavior as they will all make the calls in this order:)

1. h()
2. f()
3. g()

But the indeterminate nature of the standard means that if these functions had any interaction the resulting program state would also be indeterminate, and the compiler wouldn't warn you: Is there a Way to Get Warned about Misbehaving Designated Initializers?

c++ does have stringent initializer-list requirements 11.6.4[dcl.init.list]4:

Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions (17.5.3), are evaluated in the order in which they appear. That is, every value computation and side effect associated with a given initializer-clause is sequenced before every value computation and side effect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list.

So c++ support would have required this to be executed in the order:

1. f()
2. g()
3. h()

Breaking compatibility with previous c99 implementations.
As discussed above, this issue has been circumvented by the limitations on Designated Initializers accepted into c++20. They provide a standardized behavior, guaranteeing the execution order of Designated Initializers.

C++ has constructors. If it makes sense to initialize just one member then that can be expressed in the program by implementing an appropriate constructor. This is the sort of abstraction C++ promotes.

On the other hand the designated initializers feature is more about exposing and making members easy to access directly in client code. This leads to things like having a person of age 18 (years?) but with height and weight of zero.

---

In other words, designated initializers support a programming style where internals are exposed, and the client is given flexibility to decide how they want to use the type.

C++ is more interested in putting the flexibility on the side of the designer of a type instead, so designers can make it easy to use a type correctly and difficult to use incorrectly. Putting the designer in control of how a type can be initialized is part of this: the designer determines constructors, in-class initializers, etc.

A bit of hackery, so just sharing for fun.

#define with(T, ...)\
    ([&]{ T ${}; __VA_ARGS__; return $; }())

And use it like:

MyFunction(with(Params,
    $.Name = "Foo Bar",
    $.Age  = 18
));

which expands to:

MyFunction(([&] {
 Params ${};
 $.Name = "Foo Bar", $.Age = 18;
 return $;
}()));