On Fri, Feb 25, 2022 at 9:41 AM organicoman via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
[...]

So calling "test()" construtor, in my logic, will do the following:
- i want to initialize "b", but what does "f" refer to?
- ok let's find "f" and initialize it,
- good found "f", but what "a" refers to?
-look for "a",
-ok "a" is an 'int', initialized to be equal to 22.
- let's back track,
 - "f", inited
 - "b" , inited
- "test" constructed 
Now in case any of the members throw an exception,  then all the members data that were fully constructed are allowed to call their destructor. Exactly as per the standard "potentially constructed -> potentially call destructor"

That was my mental model, and that was how i would implement it.

Keep in mind that objects are guaranteed to be destroyed in the opposite order of construction. If you have multiple constructors that may construct your subobjects in different orders, you must also allocate run-time memory to record the order of initialization in order for your destructor to destroy the objects in the correct order. That's an unacceptable cost to a lot of people.

When you think about it, even allowing you to define a construction order different from the declaration order causes a similar problem. in case the destructor is implicitly defined, in a translation unit where it may not have access to the constructor's initialization order.

--
Arvid Norberg