On Sun, 16 May 2021, 15:34 Uecker, Martin via Liaison, <
liaison_at_[hidden]> wrote:

> Am Sonntag, den 16.05.2021, 16:26 +0200 schrieb Jₑₙₛ Gustedt via Liaison:
> > Miguel,
> >
> > on Sun, 16 May 2021 16:03:05 +0200 you (Miguel Ojeda
> > <miguel.ojeda.sandonis_at_[hidden]>) wrote:
> >
> > > On Sun, May 16, 2021 at 12:13 PM Jₑₙₛ Gustedt via Liaison
> > > <liaison_at_[hidden]> wrote:
> > > > Is there interest / attempt / opposition of porting this feature to
> > > > C?
> > >
> > > Sounds good to me.
> > >
> > > Rust and Zig also provide it equivalent facilities, although Rust
> > > provides both a safe version (panic) and an unsafe one (UB), which
> > > could be worth having; and Zig provides a single one that is a panic
> > > or UB depending on compilation mode.
> > >
> > > So a couple questions for (both) papers would be:
> > >
> > > - Should we have a non-UB variant that e.g. `abort()`s, like Rust?
> >
> > 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.
>

Agreed.


>
> > > - Should behavior depend on `NDEBUG`/`_DEBUG`/build "mode" or
> > > similar, like Zig?
> >
> > Would the behavior then be different from `assert(false)` ?
>
> It is maybe not ideal to convert 'assert' to 'assume' for
> non-debug builds, because the code could still work when
> the assertian fails bot not anymore with 'assume'.
>
> > I think the paper talks of something very similar that could be called
> > `assume(false)` and argues against it.
>
> Maybe it is just me, but I find
>
> assume(x);
>
> much clearer than
>
> if (!x)
> __builtin_unreachable();
>

That's when using it as a hint to data flow analysis, to say certain values
are never present as inputs. I agree that "assume(x)" is clear for such
cases.

But unreachable() is better than assume(false) for other uses, like the
last line of a non-void function, or a switch case. There's no need to say
"if (!x)" there, and "unreachable()" is clearer and a better expression of
intent than "assume(false)". The latter has a non-obvious meaning to a
reader not familiar with it. You need to do a mental indirection to
understand it via its effects, rather than what it says.

>