Why not conditional noexcept?

Question

The standard library doesn't typically use conditional noexcept. It is described in this paper:

Each library function having a wide contract, that the LWG agree cannot throw, should be marked as unconditionally noexcept.

If a library swap function, move-constructor, or move-assignment operator is conditionally-wide (i.e. can be proven to not throw by applying the noexcept operator) then it should be marked as conditionally noexcept. No other function should use a conditional noexcept specification.

But no reason is given.

Why?

Answer 1

Background: the presentation of changes in n3279 only implicitly lists the main actual change:

Functions that don't have a wide contract shouldn't have an unconditional noexcept specification.

This is the cause of most of the changes (so any function with a Requires-clause should clearly not be noexcept).

The reason is described in n3248: you cannot use exceptions to internally test pre-conditions if the function specifies that it is noexcept (since the exception cannot be caught - not even in debug-builds, one of the suggested options in n3248 was to allow a debug-mode to catch them).

So what about conditional noexcept?

The background doesn't explain why a few conditional noexcept without a Requires-clause were removed, but it indicated a general move away from potentially excessive noexcept and n3248 also states:

What are the risks associated with noexcept?

Unfortunately the feature is so new that there is very little field experience to develop a coherent set of guidelines. The risk from overly aggressive use of noexcept specifications is that programs with hidden terminate calls are produced. The risk of under-specifying noexcept specifications is that they become difficult to add in a later revision of the standard, as the noexcept operator becomes an observable part of the ABI.

Thus it seems that keeping a few conditional noexcept wasn't deemed worth those risks, compared to the benefits it would bring.