Ok, i need to try one last time.Your argument is founded on the idea that it is OKto destroy subobjects of a type in an order other than the one theywere initialized inPlease read my posts carefully, i never said that. I repeated many times that the destructor is indifferent of the order of initialization of member subobjects.I want to be free to initialize my members in any order i wish without triggering UB.Constructors are about user code.Destructors are about object layout.These are two orthogonal things.Orthogonal things are indifferent towards each other.Take this analogy:A constructor is a special function, so let's see how a function works.- inside a function body, we create objects.- if at any point of execution of the function code, an exception is encountered, we call the end of scope right there.- the end of scope will take care of destroying all the objects that were constructed so far.- a regular function doesn't have a destructor. Let's project this on a constructor.- initialize class subobjects in order.- initialize member subobjects in the order given by the user,- in case of exception, jump to the end of scope right there. Which will destroy all member subobjects and class subobjects constructed so far.- if not, enter the constructor body scope.- if an exception is encountered inside the body, *call the inner end of scope which will destroy the objects created inside its body, *exit to the outer end of scope which will destroy the remaining objects created previously. - if the constructor exists its body successfully, then *destroy any temporary objects created inside the body, then *make the object destructor available for call, then *carry on to the next instructions. "Longjmp"Did i use the object destructor above? NoDid i say that the destructor should be aware of the member initialization order? NoDid i used some fancy implementation? No, I'm just using the term "end of scope" as a way to summarize the steps to erase objects after exiting a scope.(i.e hitting the "}" )Did i impose on the user an order of initialization? NoIt is exactly like you have this situation:(pseudo code)Ctor(params...){// class subobjects initialization auto baseLft = baseLftType(args...); auto baseRgt = baseRgtType(args...);// subobjects member initialization auto member2 = type2(args...); auto member1 = type1(args...); ... { /* remaining Ctor body code */ }success: goto outOfScope;//longjmp to nxt instrc}I hope the pseudo code is clear. Don't take it literally, just consider it a blue print.As you can see, this pseudo Ctor handles all cases, without referring to the Dtor to do anything. In case of any exceptions, the objects to destroy are well known. If you agree so far, let's move to the destructor. I said above that the destructor is about object layout.Observe in the pseudo function above, i wrote on purpose the base classes in order, from the left to the right. As per the standard. Later on in the program execution, if the destructor is called, the layout of the object is well specified in the declaration of the class.The standard says destroy from last member subobject to first member subobject, then from right base classes to left base classes, i.e in reverse orderI have no objections against that, and it is not my subject here.My pseudo code above had just freed the destructor from knowing what's going on in the constructor, and freed the user to initialize the member subobjects in any order wished.Conclusion: With this approach, we can make C++ more intuitive and secure. Not caring about members initialization order, frees the user from compiling his code mentaly before its compiler. We can enhance C++, without changing the current standard.Where is Sy?NSent from my Galaxy
-------- Original message --------From: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Date: 2/26/22 9:12 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 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 unknownto 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 thestandard requires them to because it is *inherently good* to haveobjects 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'resaying, or because we worship the standard or whatever else.We are not agreeing with you because we do not buy your idea of "goodsense and logic". Your argument is founded on the idea that it is OKto destroy subobjects of a type in an order other than the one theywere initialized in. That's the foundation of it, and the onlyjustification you've provided for why this is good is the fact thatyou technically can write them such that it *looks like* they can beinitialized in a different order.-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals