On Fri, Feb 25, 2022 at 10:57 AM Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Fri, Feb 25, 2022 at 1:57 AM Chris Ryan via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> >" The choice of allowing you to specify members in the member
>> initialization list out of order from their order of initialization?
>> Honestly, I have no idea why that was ever legal."
>>
>> Quickly looking I could not find the reference for it but I did not think that it was ever legal.
>> Most every compiler I tested (on godbolt) did report it as a warning (-Wreorder) with -Wall or /Wall.
>> "Initializer order does not match the declaration order" or something like that depending on your compiler
>
>
> Yes, but the reason that the compiler gives you a warning is because the construct is (for some reason) legal C++ that the compiler must accept (despite being never-what-you-wanted). If the construct were actually forbidden by the standard, then you'd get an error instead, even without -Wall.
>
> (Also, pedantic nit: IIRC, I believe MSVC's equivalent of -Wall is -W4; their -Wall is actually the equivalent of Clang's -Weverything.)
>
>
>> You [can] have many constructors [...] but only one destructor and it needs to use the reverse order (of declaration).
>> If the destructor must be in reverse order of declaration, construction must be in order of declaration.
>
>
> Yup, exactly!
>
> I vaguely wonder if the original reason for permitting the programmer to write
> struct S {
> explicit S() : b(1), a(2) {}
> private:
> int a;
> int b;
> };
> (and the compiler to silently reorder the initializers) was somehow also related to C++'s permission for the compiler to silently reorder the layout of `a` and `b` in memory (because this is not a standard-layout class). No compiler has ever actually done that, and IIRC the permission to reorder memory layouts has been proposed-to-be-revoked and maybe even scaled back in C++23.

Small point: C++11 already revoked it in the case of `S`. C++11 forbid
reordering if all of the NSDMs had the same access class; reordering
was only permitted if there were mixed access classes for NSDMs. The
idea being that the compiler could put all of the private members next
to each other or something and thus detect breakage of privacy in some
way.

That last part is what is proposed to be removed.