[ 2016-07, Toronto Thursday night issues processing ]

Resolved by P0003.

[ 2016-03, Jacksonville ]

STL: Core changes to remove dynamic exception specs would make this moot
Room: This is on track to be resolved by P0003, or may be moot.

Section [new.delete] and subsections shows:

void* operator new(std::size_t size);
void* operator new[](std::size_t size);

That is, without exception-specifications. (Recall that C++03 specified these functions with throw(std::bad_alloc).)

Section [res.on.exception.handling] the end of paragraph 4 says:

Any other functions defined in the C++ standard library that do not have an exception-specification may throw implementation-defined exceptions unless otherwise specified. An implementation may strengthen this implicit exception-specification by adding an explicit one.

For example, an implementation could provide C++03-compatible declarations of operator new.

Programmers are allowed to replace these operator new functions. But how can you write the definition of these functions when the exception specification can vary among implementations? For example, the declarations

void* operator new(std::size_t size) throw(std::bad_alloc);
void* operator new(std::size_t size);

are not compatible.

From what I have been able to determine, gcc has a hack for the special case of operator new to ignore the differences in (at least) the two cases I show above. But can users expect all compilers to quietly ignore the incompatibility?

The blanket permission to add any explicit exception specification could cause a problem for any user-overridable function. Different implementations could provide incompatible specifications, making portable code impossible to write.