Private operator delete triggers compile-time error with GCC and Clang but not with MSVC

Question

Motivated by this not very well asked duplicate, I believe the problem deserves a new standalone clearly titled question. The following code triggers a compilation error with GCC 8.1.0 and Clang 6.0.0, but not with MSVC 19.00:

class X {
   public:
      X() /* noexcept */ { }    
   private:
      static void operator delete(void*) { }
};

int main() { 
    X* x = new X{}; 
}

From expr.new:

If any part of the object initialization described above terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed. [ Note: This is appropriate when the called allocation function does not allocate memory; otherwise, it is likely to result in a memory leak. — end note ]

In fact, this does not imply that the compilation error should be triggered if the matching deallocation function ::operator delete cannot be found. Or, does making it private just results in something like can be found but cannot be accessed? Which compilers are right?

Answer 1

There are two questions here:

1. How is operator delete found even though it's private?

C++ first tries to find a name anywhere; checking access protection is a later phase.
Thus, your operator delete is found, but inaccessible.

2. Why must my operator delete be accessible when the constructor is noexcept?

The wording "If any part of the object initialization [...] terminates by throwing an exception" suggests that the rest of the paragraph doesn't apply because of the noexcept.

However, as suggested by "any part of...", there may be exceptions inbetween the allocation and entering the constructor (while evaluating initialisers), or after exiting the constructor (while destroying initialisers).

Consider

struct Y
{
    Y() {}
    Y(const Y&) { throw "sorry"; }
};

class X {
   public:
      X(Y y) noexcept { }    
   private:
      static void operator delete(void*) { }
};

int main() { 
    Y y;
    X* x = new X{y}; 
}

where the Y copy constructor throws before you enter X's constructor, but after allocation, so the memory needs to be released.

So I think Visual C++ is wrong (again).

Answer 2

Visual studio is being weird with the noexcept specifier. On paper, it shouldn't build. The reason is that the decllocation function is looked up independently from the allocation function.

[expr.new] / 20, 21 and 22

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, and the constructor. If the new-expression creates an array of objects of class type, the destructor is potentially invoked.

If any part of the object initialization described above terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed.

If the new-expression begins with a unary ​::​ operator, the deallocation function's name is looked up in the global scope. Otherwise, if the allocated type is a class type T or an array thereof, the deallocation function's name is looked up in the scope of T. If this lookup fails to find the name, or if the allocated type is not a class type or array thereof, the deallocation function's name is looked up in the global scope.

According to p20, the deallocation function has to be looked up since we are creating a class object. Then the deallcoation function is found successfully, and is unambiguous (it's the member). Since access specifiers are checked only after name lookup, this should cause an error. GCC and Clang are correct.