Hi Jens,

On Sun, May 16, 2021 at 4:26 PM Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]> wrote:
>
> we have that already, it is called `abort`, and if we also get `defer`
> in C23 we will have `panic` ;-)
>
> More seriously, I don't think we should provide more than that,
> because if we want as specific behavior in case of violation of the
> constraint, the compiler would always do the test. But one goal of
> such a thing would be to make agressive optimizations possible.

I am not sure I understand the last paragraph. Could you please rephrase?

The two functions (the UB-inducing one and the aborting one) are
orthogonal, of course. The benefit of the abort-inducing function over
`abort()` itself is that it is more explicit -- it gives the reader
the reason why there was an `abort()` there, without having to write a
comment, or a wrapper themselves, etc.

I agree that the most important one to introduce is the UB-inducing
one, but I raised the question because I believe it is important to
discuss safe vs. unsafe variants of functions we introduce (where it
makes sense).

> > - Should behavior depend on `NDEBUG`/`_DEBUG`/build "mode" or
> > similar, like Zig?
>
> Would the behavior then be different from `assert(false)` ?

`assert()` is not UB (on its own) when ignored. If you are suggesting
making it so that it is UB, I would really not want that as a user!

> I think the paper talks of something very similar that could be called
> `assume(false)` and argues against it.

`assume()` is also nice to have, even if one could be expressed in
terms of the other.

Cheers,
Miguel