On Sunday, 22 May 2022 at 11:49:27 UTC, forkit wrote:

We actually have this in D, it's just written weirdly:

// debug assertion
assert(condition);

// release assertion
if (!condition) assert(0);

It would probably be more intuitive if we could write release assertions as plain assert, and use debug assert for debug assertions. But the functionality is there.

On Monday, 23 May 2022 at 01:37:09 UTC, Paul Backus wrote:

// debug assertion
assert(condition);

// release assertion
if (!condition) assert(0);

This is probably the way to go even now. Walter is not convinced we should have an option to remove asserts from release builds in a @safe way. So I think the most reasonable convention is:

// debug assertion, use when you suspect performance impact
debug assert(condition);

// regular assertion. Should be on for most applications even in release builds, but can be omitted if you're willing to accept you don't have memory safety if an assert fails. Should be the most common assert.
assert(condition);

// Semi-strong assertion. Should be on for all applications that care about memory-safety at all. Use for custom bounds checking in `@trusted` or `@system` code.
version(D_NoBoundsChecks){} else if(!condition) assert(0)

// Strong assertion. Always on.
if(!condition) assert(0);

In fact, I think this is a good way to go even if Walter changes his mind.

On Monday, 23 May 2022 at 01:37:09 UTC, Paul Backus wrote:

// debug assertion
assert(condition);

// release assertion
if (!condition) assert(0);

Thats a prime example of one of the main things that irritate me about D. For the sake of not adding a new keyword or something like that, instead a special case is added. Asserts are removed in release mode unless it is assert(0). Its idiotic.

assert(0) isn't even an assert, it's abort().

uuugh.

Sometimes it feels like D is intent on finding the most ways to reuse the same keyword to mean different things in different contexts.

On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote:

I agree that abort() and unreachable() should be different things.

In proofs assert(false) is a potential disaster as you can deduce anything from it, kinda like claiming that what must be true is indeed not true at this point, so it can clearly never happen, and if it can never happen then anything before it can be whatever you fancy as it it clearly doesn't matter… Or something like that :-)

I guess D is borrowing from MSVC __assume(false) ?

C++23 will provide unreachable().

On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote:>

alias says hi

On Monday, 23 May 2022 at 08:46:13 UTC, Dukc wrote:

// debug assertion, use when you suspect performance impact
debug assert(condition);

// regular assertion. Should be on for most applications even in release builds, but can be omitted if you're willing to accept you don't have memory safety if an assert fails. Should be the most common assert.
assert(condition);

// Semi-strong assertion. Should be on for all applications that care about memory-safety at all. Use for custom bounds checking in `@trusted` or `@system` code.
version(D_NoBoundsChecks){} else if(!condition) assert(0)

// Strong assertion. Always on.
if(!condition) assert(0);

Good tips.
Using if(!condition) assert(0); for release assertion seems reliable.
If D ever changes this in favor of a more explicit syntax, it would need a deprecation period.