LB--
commented
8 years ago If there is at least one order of these destructors that results in valid code, the compiler must use that order.
Erm. How about we just make the programmer specify the order in all cases...
In order to support #20 as well as give the programmer more freedom in how they arrange their code, destructors may be multiply defined to eventually be merged into one function by the compiler. Multiple destructors may also be implicitly generated by data members in member groups.
By default, the compiler will examine which data members are handled by each destructor and arrange the order of destructor calls to be in reverse order of the initialization order of the data members. If it is impossible to do this due to complex dependencies, the programmer may need to create additional destructors to resolve the conflicts, and call those destructors from the ones that originally created the conflict. In any case, the order of destruction must always be reverse order of the initialization of members.
The scope of all destructors is shared - variables declared in one destructor are available to destructors that are invoked later. Destructors which do not depend on any data members are, by default, called before destructors that do. If there is at least one order of these destructors that results in valid code, the compiler must use that order. Otherwise the programmer will be required to resolve the problem. In either case, the programmer can specify the order of some or all destructors to override the decisions made by the compiler.
Destructor names are in their own scope, and do not conflict with other names in the same (enclosing) scope. This scope is anonymous (cannot be referred to from outside) and has the highest priority while in destructor bodies.