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 👌 NadirSent 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 iswell-defined ([class.base.init]/13: declaration order, base classesfirst) and not allowed to vary. Compilers are not free to re-orderthose subobject constructors.The OP's point therefore stands: if all of the constructors forsubobjects past a certain point are not potentially throwing, thennone 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 anobject, which sounds very brittle. One constructor might considercertain destructors to be "potentially invoked" while another may not.And I'm not sure what any of this would actually purchase you in termsof useful functionality.-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals