On Sat, Feb 26, 2022 at 9:28 AM organicoman via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
The current implementation which assumes that the member initialization list calls the member subobjects constructors in order of declaration, otherwise garbage is produced.
This is disaster!

It's not so much an assumption as a definition, in order to keep things simple and efficient. The "disaster" is quite easily averted by "-Wall -Werror". As I said earlier, all major compilers will tell you if your initializer list is in a different order than declaration order.
 
Where is the difficulty to implement it the following way:
1- At compile time, scan the constructor member initialization list.
2- create a dependency graph.
3- make sure that class subobjects are initialized first in their order of inheritance. 
4- generate code for the constructor under compilation, which will call the member subobjects constructors in different order than their declaration order in the class, as per the user wish.

Isn't more intuitive?

You keep hand-waving away the problem of the destructor possibly being defined in a separate translation unit that cannot see the definition of the constructor. You also hand-wave away the possibility of having two constructors that end up with different initialization orders. In that case you need to record, at run-time, which constructor was used for a specific instance, so the destructor knows which order to destroy its subobjects in. Doing either is a net negative in my book.

You could invent a build system that guarantees that all translation units containing constructors are compiled first, then communicate which order they ended up deciding to initialize subobjects in, and then feed this information into all the translation units that contain destructors. I hope you see the difficulty and complexity of trying to do that (for virtually zero benefit).

As a program writer, i will be free to not watch in which order i initialize my member objects, when writing my constructor. 

It is so flexible and saves the day.

Passing "-Wall -Werror" to your compiler also saves the day, and is simpler.
 
An object constructor is sensible piece of code, making it non-intuitive could lead to disaster. 

Just imagine this scenario:
" some developer want to write the constructor of a defibrillator,  then by mistake he didn't respect the order of initialization of just one member object, now his defibrillator instead of starting at ZERO volts power, it starts at a random value. 
Two consequences,  either his code damages the machine, or kills the patient"

That's why you would be required (by law most likely) to pass "-Wall -Werror" to your compiler when building medical devices.

--
Arvid Norberg