On Sat, May 8, 2021 at 2:50 PM Jonathan Wakely <firstname.lastname@example.org
On Sat, May 8, 2021 at 2:18 PM Jonathan Wakely <email@example.com
I think adding std::unreachable(); after the assertion would work for that purpose.
If I'm reading it correctly, the paper says that unreachable is not allowed in a constant expression (because calling it is UB).
It means that unreachable() cannot be called during constant evaluation. It is allowed in a constexpr function as long as it's not reached. That's the same as falling off the end of a function, isn't it? I don't think it changes anything.
During constant evaluation, if you reach the end of a non-void function it's an error. Reaching a call to unreachable would be the same.
That is a breaking change for calling assert in a constexpr context [assertions.assert]. And even if we fix the one in the standard, how can users write their own?
No, because I'm not suggesting adding it to assert. I said add it after the assertion, i.e. in the function containing the assertion.
For assert(false), sure they can, although now that would require users to change code where they have already documented the code is unreachable.
Yes, I think that's ok. More than ok, I think that's good. They documented it using something that is explicitly specified to expand to nothing when NDEBUG is defined. That has no more weight than a comment saying "// unreachable".
Compilers might choose to interpret assert(false) in some special way (just like they sometimes interpret comments like "// FALLTHRU" to suppress warnings about falling through to the next case statement). But I think the only realistic approach we can take in the standard is to say the assert has no special meaning, and that adding "std::unreachable();" would be needed.
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."
As he already said, he made no suggestion to change assert.
I think assert is entirely unrelated to this proposed feature. The feature is about falling off the end of a function, not changing what assert does.