[Moved to DR at the September, 2013 meeting.]

Proposed resolution (February, 2013):

1. Change 6.3 [basic.def.odr] paragraph 2 as follows:

...A destructor for a class is odr-used as specified in if it is potentially invoked (11.4.7 [class.dtor]).

2. Change 7.6.2.8 [expr.new] paragraph 17 as follows:

If the new-expression creates an object or an array of objects of class type, access and ambiguity control are done for the allocation function, the deallocation function (11.4.11 [class.free]), and the constructor (11.4.5 [class.ctor]). If the new expression new-expression creates an array of objects of class type, access and ambiguity control are done for the destructor is potentially invoked (11.4.7 [class.dtor]).

3. Change 11.4.7 [class.dtor] paragraph 11 as follows:

Destructors are A destructor is invoked implicitly

• for a constructed objects with static storage duration (6.7.6.2 [basic.stc.static]) at program termination (6.9.3.3 [basic.start.dynamic]),

• for a constructed objects with thread storage duration (6.7.6.3 [basic.stc.thread]) at thread exit,

• for a constructed objects with automatic storage duration (6.7.6.4 [basic.stc.auto]) when the block in which an object is created exits (8.8 [stmt.dcl]),

• for a constructed temporary objects when the its lifetime of a temporary object ends (6.7.7 [class.temporary]),.

• for constructed objects allocated by a new-expression (7.6.2.8 [expr.new]), through use of a delete-expression (7.6.2.9 [expr.delete]),

• in several situations due to the handling of exceptions (14.4 [except.handle]).

In each case, the context of the invocation is the context of the construction of the object. A destructor is also invoked implicitly through use of a delete-expression (7.6.2.9 [expr.delete]) for a constructed object allocated by a new-expression (7.6.2.8 [expr.new]); the context of the invocation is the delete-expression. [Note: An array of class type contains several subobjects for each of which the destructor is invoked. —end note] A destructor can also be invoked explicitly. A destructor is potentially invoked if it is invoked or as specified in 7.6.2.8 [expr.new] and 11.9.3 [class.base.init]. A program is ill-formed if an object of class type or array thereof is declared and the destructor for the class is not accessible at the point of the declaration a destructor that is potentially invoked is deleted or not accessible from the context of the invocation. Destructors can also be invoked explicitly.

4. Add the following as a new paragraph following 11.9.3 [class.base.init] paragraph 9:

If a given non-static data member has both...

In a non-delegating constructor, the destructor for each direct or virtual base class and for each non-static data member of class type is potentially invoked (11.4.7 [class.dtor]). [Note: This provision ensures that destructors can be called for fully-constructed sub-objects in case an exception is thrown (14.3 [except.ctor]). —end note]

In a non-delegating constructor, initialization proceeds...

The current specification does not appear to say whether an implementation is permitted/required/forbidden to complain when a sub-object's destructor is inaccessible. In particular, if there is no possibility for an exception to be thrown following a given sub-object's construction, should an implementation issue an error if that sub-object's destructor is inaccessible?