https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #6 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> --- (In reply to Marc Glisse from comment #5) > Ah, since you are here, and you appeared as an author of N3664 but not N3537 > (precisely when this subtlety happened), could you explain why? It isn't > discussed in the paper, complicates the design, and I cannot think of any > use for this distinction It isn't discussed in the paper because it wasn't part of the original plan / design, but was added due to committee push-back. People want some guarantees: * If they write a test for their global 'operator new' (particularly, testing failure cases, mallinfo, the effect of configuration parameters on its behavior, ...), that test should still work in the presence of the language change. * A direct function call to a user-defined function should behave as a direct function call to that user-defined function. Even if it has a non-identifier name. In the end, the language and user model we found to be most satisfying, given the above, is: new-expressions, like std::allocator, may obtain storage by calling 'operator new', but it's unspecified how often it's called and with what arguments. And the language rules are an approximation of that idea. (In reply to Marc Glisse from comment #5) > This of course doesn't at all prevent from adding a __builtin_operator_new > option in std::allocator, it only affects how motivated we should be to fix > the non-conformance. Well, in case it helps your analysis, LLVM once did what GCC does now (before there were standard rules in place), and in practice we saw it break some stuff (largely, tests for allocators, but also weird things like using 'operator new((size_t)-1)' as a way to throw bad_alloc from code that can't '#include <exception>').
