* Ville Voutilainen:

> On Wed, 12 Aug 2020 at 19:50, Florian Weimer via Liaison
> <liaison_at_[hidden]> wrote:
>>
>> I tried to compile a bunch of C software with a C++ compiler, and
>> designated initializers pose a compatibility problem, even with a
>> compiler that implements P0329R4.
>>
>> Would it be possible to lift the ordering constraint? No such
>> constraint exists for mem-initializers in constructors, which have the
>> same issue regarding destruction order.
>>
>> The reason I'm asking for this is that historically, C-related
>> standard such as POSIX have not specified the order of struct members,
>> only that certain types must have certain members. This means that
>> there is no single portable order for designated initializers.
>>
>> The other issue I encountered is use of nested designators. I'm not
>> sure if theire use is actually rare.
>>
>> I'm Cc:ing the C/C++ liaison list, in case others want to chime in.
>
> There's a forum discussion thread about this here:
> https://groups.google.com/a/isocpp.org/g/std-proposals/c/FztFJLqEFwY/m/pANgM0hJAAAJ?pli=1
>
> P0329R0 discusses this as a matter that was explicitly considered by
> the authors. It was discussed
> at length in EWG in the Oulu meeting in 2016. For those who can access
> it, the discussion
> notes are at https://wiki.edg.com/bin/view/Wg21oulu/P0329R0.
>
> (Just for some background information; I'm not suggesting any value judgement.)

I can access neither URL. I may have copy of the mailing list thread.
Would you please share one message ID from the thread?

I wonder if anyone has brought up the issue that for some standards,
member order are like parameter names in function declarations:
unspecified by the standard.

> The usual advice applies. To change this, we need a proposal with
> well-thought-out rationale, with a strong recommendation that that
> rationale should include an explanation why the points made in the
> paper and in the aforementioned discussion are overshadowed by the
> benefits of the change. And since it's an incompatible change to a
> facility that's been there for two C++ standards very-soon, prepare
> to make the rationale even more convincing.

Are designated initializers part of C++17? Not sure if I understand
your “two standards” comment.

> Oh, would it be possible to lift the ordering requirement? Maybe. My
> guesstimate is that that's an uphill battle.

The goal was to increase C compatibility, but according to my
(admittedly limited) results, this was not really achieved.