On Tue, Sep 24, 2019 at 9:28 AM Walt Karas via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On 2019-09-24 01:06, Walt Karas via Std-Proposals wrote:
>
> (Side question:? shouldn't the Standard require a diagnostic if a
> noexcept function calls noexcept(false) functions on some codepath?)

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.

Why?

noexcept(false) means potentially throwing, not guaranteed throwing.

What would you do with code like:

try {
    std::deque<int> d;
} catch (int) { /* ... */ }

Should that compile, even though an exception can still escape depending on the implementation of deque?  If so, how would the compiler know what exceptions deque::deque() might throw?
 
  try/catch statements would I suppose be required to have catch (...) in noexcept functions.  For point 3, is there really a guarantee this will cause termination? 

Yes.  [except.spec]:  "Whenever an exception is thrown and the search for a handler ([except.handle]) encounters the outermost block of a function with a non-throwing exception specification, the function std::terminate is called ([except.terminate]). [ Note: An implementation shall not reject an expression merely because, when executed, it throws or might throw an exception from a function with a non-throwing exception specification. — end note ]".
 
Seems like the exception could still be caught higher in the call stack, and some objects could potentially not get destroyed.

I don't understand this.  Are you saying noexcept should just be ignored (not even UB)?

Anyway, that ship sailed eight years ago.
--
 Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com>  +1-847-691-1404