May 22
On Sunday, 22 May 2022 at 15:47:05 UTC, Siarhei Siamashka wrote:
>
> "enforce" in D is the same as "assert!" in Rust
> "assert" in D is the same as "debug_assert!" in Rust
>
> Looks like you are only unhappy about names, but all the necessary functionality is available.

'assert' comes naturally when making an 'assertion'.

assert(assert == assertion) // true

'enforce' does not. It just seems out of place to me.

May 22
On Sunday, 22 May 2022 at 12:30:21 UTC, Mike Parker wrote:
> On Sunday, 22 May 2022 at 11:51:10 UTC, forkit wrote:
>> On Sunday, 22 May 2022 at 11:49:27 UTC, forkit wrote:
>>>
>>
>> How about a compile time option to NOT remove assert in release?
>
> `-release` is shorthand for disabling bounds checking outside of `@safe`, turning off contracts, and disabling asserts. These days, you can manage the first two with `-boundscheck` and `-check`, and then asserts will still be enabled.

Oh. Useful info, thanks.

May 23

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

>

On Friday, 20 May 2022 at 06:40:30 UTC, Tejas wrote:

>

Isn't the advice to use enforce for handling/verifying input in release builds and assert for development builds though?
Yeah, it's violating DRY if a particular check needs to be done in both development and release, but then one can skip the assert and just do enforce, no?

argh!

I often forget that D removes assert in release mode :-(

If only we had Rust style asserts.

And by that, I specifically mean:

"Assertions are always checked in both debug and release builds, and cannot be disabled. See debug_assert! for assertions that are not enabled in release builds by default."

https://doc.rust-lang.org/std/macro.assert.html

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.

May 23
On Monday, 23 May 2022 at 01:37:09 UTC, Paul Backus wrote:
> On Sunday, 22 May 2022 at 11:49:27 UTC, forkit wrote:
>> [...]
>
> We actually have this in D, it's just written weirdly:
>
> ```d
> // 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.

helpful info. thanks.

Sadly, it is (as you suggest), rather counterintuitive that the same keyword gets removed in one example, and not the other.

May 23

On Monday, 23 May 2022 at 01:37:09 UTC, Paul Backus 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.

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.

May 23

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

>

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

>

On Friday, 20 May 2022 at 06:40:30 UTC, Tejas wrote:

>

Isn't the advice to use enforce for handling/verifying input in release builds and assert for development builds though?
Yeah, it's violating DRY if a particular check needs to be done in both development and release, but then one can skip the assert and just do enforce, no?

argh!

I often forget that D removes assert in release mode :-(

If only we had Rust style asserts.

And by that, I specifically mean:

"Assertions are always checked in both debug and release builds, and cannot be disabled. See debug_assert! for assertions that are not enabled in release builds by default."

https://doc.rust-lang.org/std/macro.assert.html

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.

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.

May 23

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

>

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

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

May 23

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

>

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

alias says hi

May 23

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.

May 23
On Monday, 23 May 2022 at 09:45:21 UTC, claptrap wrote:
> [...]
> Asserts are removed in release mode unless it is assert(0). Its idiotic.

Isn't that C behavior though?

69 70 71 72 73 74 75 76 77 78 79 80 81