This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 112e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
[Moved to DR at the September, 2013 meeting.]
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?
Proposed resolution (February, 2013):
Change 6.3 [basic.def.odr] paragraph 2 as follows:
...A destructor for a class is odr-used
as specified in11.4.7 [class.dtor].
Change 22.214.171.124 [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 expressioncreates an array of objects of class type, access and ambiguity control are done forthe destructor (11.4.7 [class.dtor]).
Change 11.4.7 [class.dtor] paragraph 11 as follows:
Destructors areinvoked implicitly
for constructed object
swith thread storage duration (126.96.36.199 [basic.stc.thread]) at thread exit,
for constructed temporary object
swhen thelifetime of a temporary objectends (6.7.7 [class.temporary]) ,
in several situations due to the handling of exceptions (14.4 [except.handle]).
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. Destructors can also be invoked explicitly.
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, initialization proceeds...