2017-01-17 13:06 GMT+01:00 Niall Douglas
Again, only if the damn ISO standard required compilers to refuse to compile functions which could throw exceptions inside a noexcept execution context ...
I disagree here. In many applications I would consider functions noexcept even when they can, in theory, throw. Best example is "out of memory" aka "pc lit on fire". Exception handling of rare exceptions is probably among the least tested control paths, so I would often rather terminate in the case of an "unexpected exception" than go on and gamble whether my exception handling is going to die trying to overwrite my last good program state on disk.
Therefore, compiler noise like that would probably lead to random
try{...}catch(...){}
inside all noexcept functions rather quickly.
An absolutely valid point. One of the big reasons for using something like Outcome is so one can segment really serious "this is totally unexpected" type errors like bad_alloc from the routine errors.
However the point was about the quality of implementation of noexcept in C++ 11. Most on the C++ committee did (and do) not see the inversion of execution flow as anything special. They consider it as just another execution path, and hence noexcept got the unhelpful spec it did.
One thing I felt noexcept really lacked was defaulting to noexcept(auto) which means "this function gets noexcept from the things it could potentially call" i.e. if everything it could call is noexcept, it too becomes noexcept and all extern "C" functions automatically get noexcept(true) applied to them.
Just for completeness: some "C" functions do throw exceptions, like qsort if you pass it a callback that throws.
Then the compiler could examine all functions called from a noexcept(true) function and error out if you ever call anything which deduces to noexcept(false) or is noexcept(false). This behaviour would be much more useful than the present situation in persuading people to write their code correctly.
I did raise this proposal with a senior committee member once and I was told that the showstopper to that idea was the STL which would have needed many breaking changes.
And now C++ 17 has resurrected dynamic exception modifiers i.e. throws(int) is back, I guess the ship has sailed and we're stuck with what we've got.
What do you mean here? Regards, &rzej;