[expr.new] Template VS non-template deallocation functions

[frederick-vs-ja]

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [expr.new]

Link to reflector thread (if any):

Issue description:

[expr.new] p29 currently says

If the lookup finds a single matching deallocation function, that function will be called; otherwise, no deallocation function will be called.

When there're more than one potentially matching deallocation functions, some resolution are done in [temp.deduct.decl] p2 and [temp.func.order] p1.3.

However, the following cases don't seem covered:

• one overload is a non-template function and the other is a function template specialization, and
• both overloads are non-template static member functions of a templated class and one is more constrained than the other.

Perhaps we should apply some rules from [over.match.best.general] for selection of deallocation functions.

Currently there's implementation divergence. GCC and MSVC think a non-template deallocation function overload is better than a template specialization, while Clang doesn't (demo).

Suggested resolution:

[xmh0511]

When there're more than one potentially matching deallocation functions

Doesn't it fall into the "otherwise" case? That is

otherwise, no deallocation function will be called.

Since «the lookup finds a single matching deallocation function» is false, Clang does the correct thing: no deallocation is called.

At best, we could say

If the lookup finds a single viable([over.match]) matching deallocation function, that function will be called; otherwise, no deallocation function will be called.

[frederick-vs-ja]

When there're more than one potentially matching deallocation functions

Doesn't it fall into the "otherwise" case? That is

otherwise, no deallocation function will be called.

Since «the lookup finds a single matching deallocation function» is false, Clang does the correct thing: no deallocation is called.

Perhaps such reading is correct, which sounds like that Clang is bug-conformant with the current standard wording to me.

At best, we could say

If the lookup finds a single viable([over.match]) matching deallocation function, that function will be called; otherwise, no deallocation function will be called.

This doesn't seem changing the status quo. Perhaps it would be better to say

[...] If the lookup finds a single matching deallocation function that is the best viable function ([over.match.best.general]), [...]

[xmh0511]

This doesn't seem changing the status quo. Perhaps it would be better to say

This depends on what the intended meaning is. If the intended meaning were to call the best viable function, then the "otherwise" part would be meaningless; the overload resolution is stated to fail in that case and does result in an ill-formed program.

According to the "otherwise" part, presumably, the intended meaning is that the viable function must be unique. The rule you quoted in another issue(i.e., [temp.deduct.decl] p1) is just used to form the candidate set, which is part of overload resolution.

[frederick-vs-ja]

This depends on what the intended meaning is. If the intended meaning were to call the best viable function, then the "otherwise" part would be meaningless; the overload resolution is stated to fail in that case and does result in an ill-formed program.

The "otherwise" part roughly corresponds to non-finding and ambiguous cases in overload resolution, but the actual conditions are inconsistent.

[xmh0511]

In your example, the overload resolution could succeed and be non-ambiguous in calling the function according to [over.match.best.general] p2.4, in which case the warning of Clang is

:18:16: warning: multiple suitable 'operator delete' functions for 'ThrowingDefaultCtor'; no 'operator delete' function will be invoked if initialization throws an exception [-Wambiguous-delete]

where the "suitable" corresponds to the formal wording "viable". This seems the correct reading and the intended of the wording.

[frederick-vs-ja]

In your example, the overload resolution could succeed and be non-ambiguous in calling the function according to [over.match.best.general] p2.4, in which case the warning of Clang is

:18:16: warning: multiple suitable 'operator delete' functions for 'ThrowingDefaultCtor'; no 'operator delete' function will be invoked if initialization throws an exception [-Wambiguous-delete]

where the "suitable" corresponds to the formal wording "viable". This seems the correct reading and the intended of the wording.

Clang's warning message is clear enough so I'd say it's "bug-conformant" (analog of "bug-compatible") to the current wording.

It was unclear whether "incomplete" ambiguity resolution for deallocation function is intended.

• The rule for selecting placement deallocation function was originally introduced by N0642 which didn't discussed templates. The wording was enhanced later but has never considered function templates.
• [temp.func.order] p1.3 was originally added by N1089 which only discussed function templates.

It seems possible to me that the inconsistency/incompleteness of the ambiguity resolution is just an oversight.

[xmh0511]

The matching deallocation function is defined to have identical parameter types, except for the first. This means, the best viable function is always the non-template function according to [over.match.best.general] p2.4. This renders that "otherwise" part always corresponds to a non-finding case.

Fairly, consider that there are two function template specializations for the deallocation function; they have identical parameter types, but differ in constraints, and the overload resolution at least needs to find the viable functions. Whether we need to find the best viable functions, we may need to ask CWG.

[keinflue]

The matching deallocation function is defined to have identical parameter types, except for the first. This means, the best viable function is always the non-template function according to [over.match.best.general] p2.4. This renders that "otherwise" part always corresponds to a non-finding case.

From a user perspective I think it is very surprising that it is at all possible for no deallocation to happen silently, doubly so if operator delete was written down specifically, but just happened to be ambiguous. So I think it would be a good idea to apply [over.match.best.general]p2.4 also here (which as it stands is not the case because overload resolution is not performed) and to accept that this might make currently well-formed programs ill-formed.

Fairly, consider that there are two function template specializations for the deallocation function; they have identical parameter types, but differ in constraints, and the overload resolution at least needs to find the viable functions. Whether we need to find the best viable functions, we may need to ask CWG.

This is already handled by template argument deduction and [temp.func.order] p1.3 coupled with [temp.deduct.decl] p2. Deduction fails if constraints are not satisfied and partial ordering selects the best matching constraints, failing if no best candidate can be selected among the template specializations (but not the non-template candidates).

The issue remaining mentioned in the first post is when constraints are placed on deallocation functions which are not function template specializations. Because no overload resolution is done, they are never checked, neither against one another to select a best candidate, nor even to filter the matching candidates based on constraint satisfication at all.

Example for that last scenario:

#include <cstdlib>
#include <new>

template<bool b>
struct A {
    A() { throw 0; }
    void* operator new(std::size_t n) { return std::malloc(n); }
    void operator delete(void* p) requires(b) { std::free(p); };
    void operator delete(void* p) requires(!b) { std::free(p); };
};

int main() {
  try {
    new A<false>;
  } catch(...) {}
}

This currently does not call any operator delete because the two operator delete are ambiguous even though only one has satisfied constraints.

[xmh0511]

This is already handled by template argument deduction and [temp.func.order] p1.3 coupled with [temp.deduct.decl] p2.

lookup does not include overload resolution. I meant, two constraints need to be partially ordered to determine which is best