On Fri, Feb 25, 2022 at 9:41 AM organicoman via Std-Proposals <
std-proposals_at_[hidden]> 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