Am 17. Mai 2021 18:33:17 MESZ schrieb Miguel Ojeda <miguel.ojeda.sandonis_at_[hidden]>:
>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 am not sure that `abort` tells anything else than this path of control flow is catastrophic. So yes, for tiny bit of additional sugar with the possible message, but that's it, I think.

>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).

Frankly, I don't see in this case how a safe version would make much sense. Such a function is the opposite of safe, we are telling the compiler that, against all evidence, this path will never be taken.

>> > - 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 you are arguing in the wrong direction ;-) One possible implementation of such a thing would be `assert(false)`.

UB is not a specific behavior, it is the absence of requirements for behavior.

But what I meant, was that having a feature that behaves fundamentally different under debugging makes it impossible to debug the feature when it is applied with all of its strength. For me that has much resemblance with a nightmare.

>> 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.

Yes, but let's do perhaps one thing at a time. `unreachable` has the advantage of being widely implemented.

Jens



Miguel,

-- 
Jens Gustedt - INRIA & ICube, Strasbourg, France