On Tuesday, 24 September 2019 10:13:28 PDT Walt Karas via Std-Proposals wrote:
> > But points 1 and 2 contradict the premise of the question. try/catch
> > statements would I suppose be required to have catch (...) in noexcept
> > functions.
>
> You don't need a catch (...), you just need to catch the exceptions that the
> throwing function throws in the calls that you will make.

> resp: But, if hypothetically the compiler is going to check for noexcept,
> how would it know what's thrown by a function defined outside the CU?

Sorry, I didn't understand your response.

My point was that the *programmer* knows what exceptions the called function
may throw under the conditions of the arguments passed. If all of those are
handled, then no exceptions can leak from the current function.

> And you do have a catch (...):
> > For point 3, is there really a guarantee this will cause
> > termination?
>
> Yes.
>
> resp: Isn't the typical exception handling implementation an associative
> lookup from return address in the call stack? For this implementation, if
> the return address is not in the table, does the unwind code assume a
> return from a noexcept function and terminate?

How the implementation is done shouldn't matter to you. What matters is that a
noexcept function behaves as if the entire body were inside the try block,
with a catch (...) std::terminate.

And no, exception handling implementations don't depend on function return
addresses.

> > Seems like the exception could still be caught higher in the
> > call stack, and some objects could potentially not get destroyed. It
> > seems
> > better to encourage:
> > void calls_throwing_stuff() noxecept{ // stuff}
> > to be changed to something like:
> > void calls_throwing_stuff() noxecept{ try { // stuff } catch (...)
> > std::terminate();}
>
> Why? What observable effect do you expect with this?
> resp: I guess it's of no value, since there seems to be a reasonable
> implementation of unwind that can do this implicitly. But still I think
> there is value in at least warning at compile time that a noexcept(true)
> function is calling a noexcept(false) function.

That's a Quality of Implementation (QoI) question. You can file a suggestion
for warning with your compiler. They can enable that with a compiler
extension, like a compiler-specific attribute, that enables it per function.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products