[Moved to DR at 10/01 meeting.]

[Moved to DR at 10/01 meeting.]

Proposed resolution (10/00):

1. Replace 11.4.7 [class.dtor] paragraph 11 with the following:

   At the point of definition of a virtual destructor (including an implicit definition), the non-array deallocation function is looked up in the scope of the destructor's class (6.5.2 [class.member.lookup]), and, if no declaration is found, the function is looked up in the global scope. If the result of this lookup is ambiguous or inaccessible, or if the lookup selects a placement deallocation function, the program is ill-formed. [Note: this assures that a deallocation function corresponding to the dynamic type of an object is available for the delete-expression (11.4.11 [class.free]).]

2. In 11.4.11 [class.free] paragraph 4, change

   ...the deallocation function is the one found by the lookup in the definition of the dynamic type's virtual destructor (11.4.7 [class.dtor]).

   to

   ...the deallocation function is the one selected at the point of definition of the dynamic type's virtual destructor (11.4.7 [class.dtor]).

There is a mismatch between 11.4.7 [class.dtor] paragraph 11 and 11.4.11 [class.free] paragraph 4 regarding the lookup of deallocation functions in virtual destructors. 11.4.7 [class.dtor] says,

At the point of definition of a virtual destructor (including an implicit definition (11.4.5.3 [class.copy.ctor])), non-placement operator delete shall be looked up in the scope of the destructor's class (6.5.3 [basic.lookup.unqual]) and if found shall be accessible and unambiguous. [Note: this assures that an operator delete corresponding to the dynamic type of an object is available for the delete-expression (11.4.11 [class.free]). ]

The salient features to note from this description are:

1. The lookup is "in the scope of the destructor's class," which implies that only members are found (cf 6.7.7 [class.temporary]). (The cross-reference would indicate otherwise, however, since it refers to the description of looking up unqualified names; this kind of lookup "spills over" into the surrounding scope.)
2. Only non-placement operator delete is looked up. Presumably this means that a placement operator delete is ignored in the lookup.

On the other hand, 11.4.11 [class.free] says,

If a delete-expression begins with a unary :: operator, the deallocation function's name is looked up in global scope. Otherwise, if the delete-expression is used to deallocate a class object whose static type has a virtual destructor, the deallocation function is the one found by the lookup in the definition of the dynamic type's virtual destructor (11.4.7 [class.dtor]). Otherwise, if the delete-expression is used to deallocate an object of class T or array thereof, the static and dynamic types of the object shall be identical and the deallocation function's name is looked up in the scope of T. If this lookup fails to find the name, the name is looked up in the global scope. If the result of the lookup is ambiguous or inaccessible, or if the lookup selects a placement deallocation function, the program is ill-formed.

Points of interest in this description include:

1. For a class type with a virtual destructor, the lookup is described as being "in the definition of the dynamic type's virtual destructor," rather than "in the scope of the dynamic type." That is, the lookup is assumed to be an unqualified lookup, presumably terminating in the global scope.
2. The assumption is made that the lookup in the virtual destructor was successful ("...the one found...", not "...the one found..., if any"). This will not be the case if the deallocation function was not declared as a member somewhere in the inheritance hierarchy.
3. The lookup in the non-virtual-destructor case does find placement deallocation functions and can fail as a result.

Suggested resolution: Change the description of the lookup in 11.4.7 [class.dtor] paragraph 11 to match the one in 11.4.11 [class.free] paragraph 4.