Alexander Terekhov wrote:
Sebastian Redl wrote: [...]
So throw() is deprecated. That doesn't change the fact that its behavior is very similar to what you propose for noexcept.
No, throw() injects catch(...) and I certainly don't want that for noexcept.
The only difference between that and your proposal is whether destructors between the call site and the catch are called before unexpected() is called. Which is pretty irrelevant, really.
With or without*** static checking, noexcept specifier is much better than throw().
Leaving implementation issues, such as the overhead of catch(...), aside, what exactly are the advantages of noexcept over throw() under your proposal?
I still think that the compile error for noexcept-marked functions is something we definitely want.
So that you can turn such compile errors into undefined behaviour using noexcept blocks or just swallow exceptions?
I can turn most type mismatch compile errors into undefined behavior by using reinterpret_cast. What's your point? Regards, Sebastian