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
[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to DR at the February, 2021 meeting.]
Paragraph 4 of 11.4.11 [class.free] speaks of looking up a deallocation function. While it is an error if a placement deallocation function alone is found by this lookup, there seems to be an assumption that a placement deallocation function and a usual deallocation function can both be declared in a given class scope without creating an ambiguity. The normal mechanism by which ambiguity is avoided when functions of the same name are declared in the same scope is overload resolution; however, there is no mention of overload resolution in the description of the lookup. In fact, there appears to be nothing in the current wording that handles this case. That is, the following example appears to be ill-formed, according to the current wording:
struct S {
void operator delete(void*);
void operator delete(void*, int);
};
void f(S* p) {
delete p; // ill-formed: ambiguous operator delete
}
Suggested resolution (Mike Miller, March 2002):
I think you might get the right effect by replacing the last sentence of 11.4.11 [class.free] paragraph 4 with something like:
After removing all placement deallocation functions, the result of the lookup shall contain an unambiguous and accessible deallocation function.
Additional notes (October, 2012):
This issue should be reconsidered in list of paper N3396, as it would add additional overloads for allocation and deallocation functions.
The term “usual deallocation function” is defined in 6.7.5.5.3 [basic.stc.dynamic.deallocation] paragraph 2; perhaps it could be used to good effect in 7.6.2.9 [expr.delete] paragraph 7. The specifications in 11.4.11 [class.free] paragraphs 4 and 5 should probably also be moved into 7.6.2.9 [expr.delete].