This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-11-11
(From submission #532.)
Subclause 7.6.2.9 [expr.delete] paragraph 6 specifies that the destructor must be accessible even if a destroying operator delete is used:
If the value of the operand of the delete-expression is not a null pointer value and the selected deallocation function (see below) is not a destroying operator delete, evaluating the delete-expression invokes the destructor (if any) for the object or the elements of the array being deleted. The destructor shall be accessible from the point where the delete-expression appears. In the case of an array, the elements are destroyed in order of decreasing address (that is, in reverse order of the completion of their constructor; see 11.9.3 [class.base.init]).
This does not seem to be intended.
Possible resolution:
Change in 7.6.2.9 [expr.delete] paragraph 6 as follows:
If thevaluetype of the operand of the delete-expressionis not a null pointer valueis a pointer to a class type or (possibly multidimensional) array thereof, and the selected deallocation function (see below) is not a destroying operator delete:, evaluating the delete-expression invokes the destructor (if any) for the object or the elements of the array being deleted. The destructor shall be accessible from the point where the delete-expression appears. In the case of an array, the elements are destroyed in order of decreasing address (that is, in reverse order of the completion of their constructor; see 11.9.3 [class.base.init]).
- The destructor is potentially invoked (11.4.7 [class.dtor]).
- If the pointer value is not a null pointer value, evaluating a single-object delete expression destroys the object pointed to by the operand, and evaluating an array delete expression destroys each element of the array pointed to by the operand in order of decreasing index.
CWG 2024-05-31
This area of the wording is affected by P3144 (Deprecate Delete of a Pointer to an Incomplete Type). The wording above requires a class definition due to the "potentially invoked" phrasing. See also issue 2880.