If really the author meant to add noexcept, she must then be aware of the problem and properly handle exceptions anyway, as IIUC all this is merely a runtime check that leads to program abortion.
Its sadly easy to allow exceptions, they are slippery little things:
```c++ int f() try { the code; } catch(...){ now I must not allow anything to throw here; careful of IO, constructing objects, operators; sheesh, not much you CAN do; better just terminate, or return -1; } ```
The nice thing about the `noexcept` is it can catch exceptions from the `catch` clause too, so it would be good if it could be used.
So authors of C++ plugins are forced to consider the issue. But that breaks C++ API.
Though I wouldn't expect too many C++ plugins for the new API, yet, now is the best chance.
Though, I still wonder how this can change the ABI, especially in C linkage where there can't be no name mangling anyway.
I wouldn't think it would change the ABI, I would have expected the stack frame to have a flag saying this function is `noexcept` so the unwinder can see it and terminate. So its internal to the function. But it is implementation dependent, so who knows.