Nadir,
This answers your scenario: "... the program has undefined behavior."
Other than the accidental omission Arthur pointed out in the other mail.

11.10.3 Initializing bases and members [class.base.init]
...
16 Member functions (including virtual member functions, 11.7.3) can be
called for an object under construction. Similarly, an object under
construction can be the operand of the typeid operator (7.6.1.8) or of a
dynamic_- cast (7.6.1.7). However, if these operations are performed in a
ctor-initializer (or in a function called directly or indirectly from a
ctor-initializer) before all the mem-initializers for base classes have
completed, the program has undefined behavior.

On Thu, Feb 24, 2022 at 3:40 PM organicoman via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hmm,
> That means that tglhe following code will print nonsense.
>
> struct foo
> {
> foo()=delete;
> foo(int _a) : a(_a) { printf("foo%d\n",a);}
> };
>
> struct bar
> {
> bar()=delete;
> bar(foo f) { printf("bar%d\n",f.a);}
> };
>
> struct test
> {
> bar b;
> foo f;
> int a;
> test(): b(f), f(a), a(22) {}
> };
>
> int main()
> {
> test t;
> return 0;
> }
>
> So instead of receiving a compiler error of a default constructor deleted
> for both bar and foo, i will receive junk!!
> I seldomly read the standard, but this situation was out of discussion
> for me, since i assumed that i will logically receive a compiler error,
> and constructing a dependency graph between the data members was not that
> difficult to figure out.
> Can anyone explain the logic behind this choice of the standard?
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Jody Hagins <coachhagins_at_[hidden]>
> Date: 2/25/22 2:09 AM (GMT+04:00)
> To: std-proposals_at_[hidden]
> Cc: organicoman <organicoman_at_[hidden]>
> Subject: Re: [std-proposals] Relax condition for potentially invoked
> destructor in constructor
>
> It is possible that I misunderstand your email, but unless that is the
> case, I think your following statement is incorrect.
>
>
> But data members of an object, as the proposal points to in its example,
> can be constructed in different order, at best you will have a compiler
> warning telling you that you initialized some data member before the other.
>
>
>
>
> 11.4.19 addresses layout of data members...
>
> • [Note: Non-static data members of a (non-union) class with the same
> access control (11.9) and non-zero size (6.7.2) are allocated so that later
> members have higher addresses within a class object. The order
> of allocation of non-static data members with different access control is
> unspecified. Implementation alignment requirements might cause two adjacent
> members not to be allocated immediately after each other; so
> might requirements for space for managing virtual functions (11.7.2) and
> virtual base classes (11.7.1). —end note]
>
>
>
> 11.10.2.13 addresses initialization order.
>
> • In a non-delegating constructor, initialization proceeds in the
> following order:
> • First, and only for the constructor of the most derived class (6.7.2),
> virtual base classes are initialized in the order they appear on a
> depth-first left-to-right traversal of the directed acyclic graph of base
> classes, where “left-to-right” is the order of appearance of the base
> classes in the derived class base-specifier-list.
>
> • — Then, direct base classes are initialized in declaration order as
> they appear in the base-specifier-list (regardless of the order of
> the mem-initializers).
>
> — Then, non-static data members are initialized in the order they were
> declared in the class definition (again regardless of the order of
> the mem-initializers).
>
> — Finally, the compound-statement of the constructor body is executed.
>
>
>
>
>
>
>
> On Feb 24, 2022, at 10:40 AM, organicoman via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> Doh!
> I meant data members.
> Wow the proposal examples was so misleading, i was thinking about data
> members construction after reading the examples then i extrapolated to base
> classes.
>
> Yes, as Jason pointed, base classes initialization order is well defined.
> But data members of an object, as the proposal points to in its example,
> can be constructed in different order, at best you will have a compiler
> warning telling you that you initialized some data member before the other.
>
> class PublicInterface {
> std::unique_ptr<class Impl> pimpl_;
> };
>
> "pimpl_", is data member not a base class (subobject)
>
> Thanks Jason, nice catch, it was lucid 👌
> Nadir
>
>
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
> Date: 2/24/22 6:41 PM (GMT+04:00)
> To: std-proposals_at_[hidden]
> Cc: Jason McKesson <jmckesson_at_[hidden]>
> Subject: Re: [std-proposals] Relax condition for potentially invoked
> destructor in constructor
>
> On Thu, Feb 24, 2022 at 8:22 AM organicoman via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > But remember that the compiler is free to rearrange the construction of
> subobjects for optimization purposes,
>
> Um, no it isn't. The order of initialization of subobjects is
> well-defined ([class.base.init]/13: declaration order, base classes
> first) and not allowed to vary. Compilers are not free to re-order
> those subobject constructors.
>
> The OP's point therefore stands: if all of the constructors for
> subobjects past a certain point are not potentially throwing, then
> none of their destructors *need* to be potentially invoked.
>
> That said, I don't think it's a very *useful* idea. It makes
> "potentially invoked" a matter of exactly how you initialize an
> object, which sounds very brittle. One constructor might consider
> certain destructors to be "potentially invoked" while another may not.
> And I'm not sure what any of this would actually purchase you in terms
> of useful functionality.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>