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