On Sat, Feb 26, 2022 at 12:05 PM organicoman via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Sorry guys i cannot explain more than what i did already.
>
> "Destruction of an object in construction time is a totally different mechanism than destroying it after it finishes construction."

I don't know why you keep saying that as though it were either unknown
to us or meaningful in this discussion.

> We need a complier implementer to tell you why they chosen this lazy implementation, without blocking the user from the possibility of shuffling the order of initialization.

They've chosen this because the standard requires them to. And the
standard requires them to because it is *inherently good* to have
objects destroyed in the opposite order they were initialized.

Why should objects be destroyed out of their initialization order?

> End of thread.
>
>
> Just a side observation:
>
> I see a trend of people turning into standardees book worms, instead of using simple good sense and logic.

Why, because we don't agree with you?

We are not agreeing with you because we don't understand what you're
saying, or because we worship the standard or whatever else.

We are not agreeing with you because we do not buy your idea of "good
sense and logic". Your argument is founded on the idea that it is OK
to destroy subobjects of a type in an order other than the one they
were initialized in. That's the foundation of it, and the only
justification you've provided for why this is good is the fact that
you technically can write them such that it *looks like* they can be
initialized in a different order.