Am Sonntag, den 16.05.2021, 18:45 +0100 schrieb Jonathan Wakely:
> 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_gmail.com>) 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.

There I would find an attribute much more convincing.

Best,
Martin