Thank you for your careful reply.

I only searched for the recent ones, but anyway, I think this proposal is meaningful.

I used the STL code only want to illustrate that adding noexcept is beneficial, as P2401 says, so I think more noexcept should be encouraged.

I don't understand what this means.

I meant some functions that cannot or do not throw by default, such as operator delete or destructors. I consulted the standard, these explanations are scattered in multiple places, but cppreference.com<https://en.cppreference.com/w/cpp/language/noexcept_spec> has a list of these functions (after "functions declared without noexcept specifier except for").

This is a classification which is way too simple. What if you re-throw from a catch?

It was indeed my mistake that I did not mention re-throw. I realized it immediately after sending it. Obviously, re-throw needs to be excluded.

  1. Is it implementable? Does it require full-program analysis? Does it
risk hitting implementation-defined limits? Do you run into Rice's
theorem? A POC would be very much desirable.

For the recursive calls, I think at least the program can be rejected and required to manually specify, which is the simplest and feasible. The fact is that recursive calls are infrequent, similar to constexpr functions, I hope to solve most cases first.

  1. Would be acceptable that a "minor" modification of a noexcept(auto)
function does, in fact, change its noexcept-ness, with possibly massive
consequences for callers?

I think a macro or a function can be provided to convert the call to non-throwing. For example:

#ifdef NDEBUG
#define NOEXCEPT_OR_TERMINATE(expr) ((void)0)
#else
#define NOEXCEPT_OR_TERMINATE(expr) \
  try { \
    expr; \
  } catch (...) { \
    std::terminate(); \
  }
#endif

template< class F, class... Args >
constexpr std::invoke_result_t<F, Args...>
    no_throw_invoke( F&& f, Args&&... args ) noexcept;


At the same time, I think if the user is sure that the function does not throw an exception, it should be exactly specified as noexcept.

The effect of code that only exists in debug mode is a complex issue. I noticed that it affects contracts and undefined behavior, so this issue is actually not so closely related to this proposal.

<http://www.kdab.com/>