Date: Thu, 13 Aug 2020 12:30:59 +0200
* Jens Gustedt:
> Florian,
>
> on Thu, 13 Aug 2020 11:46:41 +0200 you (Florian Weimer
> <fw_at_[hidden]>) wrote:
>
>> * Jens Gustedt via Liaison:
>>
>> >
>> > It is recommended that applications that target the common
>> > C/C++ core list initializers in declaration order. Further it is
>> > recommended that implementations that target that core
>> > diagnose situations that would be problematic for the other
>> > language, such as initializers not appearing in declaration order or
>> > initializer expressions that require sequencing.
>>
>> I think you should also recommend that standards specify the order of
>> struct fields, and not just that the fields exist.
>
> Interesting idea. I have not followed that vein of making
> recommendations for depending standards, yet. For the moment they are
> treated as "applications". Hm.
>
> Also we even have that problem within the C standard itself. E.g the
> structures in <time.h> have a specification that allows any order of
> the fields. And even worse, I think that some implementations even
> have them in different orders than listed.
>
> So here, a general recommendation would then also be for
> implementations to use the order as specified.
Yes, this is a good point. But it raises the question how C++
programmers can know whether it is portable to use a designated
initializer with a type from a standard header.
I think C++20 defines a few types with public data members, although
[structure.specifications] and [objects.within.classes] have not been
updated to reflect this.
> Florian,
>
> on Thu, 13 Aug 2020 11:46:41 +0200 you (Florian Weimer
> <fw_at_[hidden]>) wrote:
>
>> * Jens Gustedt via Liaison:
>>
>> >
>> > It is recommended that applications that target the common
>> > C/C++ core list initializers in declaration order. Further it is
>> > recommended that implementations that target that core
>> > diagnose situations that would be problematic for the other
>> > language, such as initializers not appearing in declaration order or
>> > initializer expressions that require sequencing.
>>
>> I think you should also recommend that standards specify the order of
>> struct fields, and not just that the fields exist.
>
> Interesting idea. I have not followed that vein of making
> recommendations for depending standards, yet. For the moment they are
> treated as "applications". Hm.
>
> Also we even have that problem within the C standard itself. E.g the
> structures in <time.h> have a specification that allows any order of
> the fields. And even worse, I think that some implementations even
> have them in different orders than listed.
>
> So here, a general recommendation would then also be for
> implementations to use the order as specified.
Yes, this is a good point. But it raises the question how C++
programmers can know whether it is portable to use a designated
initializer with a type from a standard header.
I think C++20 defines a few types with public data members, although
[structure.specifications] and [objects.within.classes] have not been
updated to reflect this.
Received on 2020-08-13 05:34:25