On Sat, May 8, 2021 at 4:14 PM Nevin Liber via SG12 <sg12@lists.isocpp.org> wrote:

What about assert(b) when NDEBUG is not defined?  JF said that would become an unconditional call to std::unreachable, but calling std::unreachable invokes UB.  From the paper: "The author feels that the best way is to make the behavior of std::unreachable() be undefined." 

I believe JF was responding to your `assert(false)` situation. The standard `assert` actually already does the right thing; it's basically

    #define assert(x) (x ? void() : std::abort())

where `std::abort()` is (at least hypothetically) annotated with [[noreturn]].

    constexpr int f4(int x) { assert(x > 0); if (x == 42) return 42; }

Here, in C++14-and-later, the compiler can trace individual "attempted constant-evaluation runs" and observe that
- `f4(-1)` evaluates non-constexpr function std::abort() and therefore is not a constant expression
- `f4(42)` evaluates to 42
- `f4(1)` falls off the end of the function and therefore is not a constant expression

In JF's hypothetical future, AIUI, the compiler would also be able to do control-flow (and data-flow?) analysis and prove symbolically that
- `f4(x)` for (x <= 0) evaluates [[noreturn]] function std::abort() and therefore is OK
- `f4(x)` for (x == 42) returns a value along all codepaths and therefore is OK
- `f4(x)` for (0 < x && x != 42) falls off the end of the function and therefore is not OK
and, since there exists at least one "not OK" case, therefore the definition of `f4` is ill-formed (even if `f4` is never actually evaluated on any of the problematic inputs).

–Arthur