Full name of submitter: Lénárd Szolnoki

Reference: [expr.const], [except.handle]

Issue description:

Consider:

int main() {
  try {
    throw 0;
  } catch (...) {
    constexpr int x = []{
      try {
        throw;
      } catch (...)
        return 1;
      }
    }();
  }
}

This is not implementable to be well-formed, as throw; would be throwing a runtime exception within constant evaluation. However in the current wording I could not find anything that would disallow throw; in this context. My analysis is the following:

1. There is a currently handled exception at the point of throw;

[except.handle]/10:

The exception with the most recently activated handler that is still active is called the currently handled exception.

In my reading "most recently activated handler" refers to sequencing within the current thread (maybe at least a "current thread" should be added to this sentence, but I digress).

I did not find anything that would suggest that sequencing the initialization of constexpr variables would be different to non-constexpr ones, even if they are (typically) not evaluated at runtime.

2. There is nothing banning a throw; expression in [expr.const]

The blanket ban on throw expressions got removed with P3068, and got replaced with banning constructing exception objects that leak out from the constant evaluation.

There was no wording added to ban throw; when the currently handed exception was not thrown during the current constant evaluation.

Suggested resolution:

Add under [expr.const]/10.22:

• a throw-expression ([expr.throw]) with no operand, unless the currently handed exception was thrown within the evaluation of E;