Responses inline

  On Tuesday, September 24, 2019, 10:44:13 AM CDT, Thiago Macieira <thiago_at_[hidden]> wrote:
 
 On Tuesday, 24 September 2019 07:28:09 PDT Walt Karas via Std-Proposals wrote:
> Andrey Semashev via Std-Proposals wrote:
> No, because that function (1) may not actually throw, (2) may be inside
> a try block or may not be called in runtime and (3) program termination
> in case of an exception may be intended.
> 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?

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?
 

> 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.

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