On 5/19/2022 1:17 PM, Dukc wrote:
> We can do a bit better. If an assert trips, the program will go to unknown state, and there's no telling what it will do. But that's still not quite the same as undefined behaviour.

Yes, it is. Deliberately so. In fact, the program is *already* in an unknown state if it trips the assert. This has been extensively and exhaustively debated several times in this n.g. I don't really want to re-litigate it.

The compiler is allowed to assume the assert holds. Whether it actually does or not is irrelevant. If the user uses the compiler switch to turn off the asserts, the language guarantees no longer hold, and that is the user's choice.

There were a few releases where the assert's got turned off to make the compiler go faster. Inevitably, some mysterious crasher bugs appeared. Turning the asserts back on detected these. The asserts are staying on.

On 5/19/2022 11:40 PM, 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?

Asserts are *not* for validating program input. Please do not use them for that. They are for checking that the program's logic is correct. If an assert is tripped, it is a bug in the program, not a problem with user input.

On Saturday, 21 May 2022 at 03:03:41 UTC, Walter Bright wrote:
> On 5/19/2022 1:17 PM, Dukc wrote:
>> We can do a bit better. If an assert trips, the program will go to unknown state, and there's no telling what it will do. But that's still not quite the same as undefined behaviour.
>
> Yes, it is. Deliberately so. In fact, the program is *already* in an unknown state if it trips the assert.

I'm not sure if you read the rest of my post where I explained the practical difference between unknown state and undefined behaviour. Anyhow you do not address that. I did not dispute that a failed assert means unknown state.

> This has been extensively and exhaustively debated several times in this n.g. I don't really want to re-litigate it.

Can you provide links? I'm interested in the topic and if there are points brought up I have not considered, I don't want people having to re-explain them to me.

> There were a few releases where the assert's got turned off to make the compiler go faster. Inevitably, some mysterious crasher bugs appeared. Turning the asserts back on detected these. The asserts are staying on.

I do agree that was a wise solution, and would be regardless whether the spec says what it now does or what I'm proposing.

On 5/21/2022 1:56 AM, Dukc wrote:
> Can you provide links? I'm interested in the topic and if there are points brought up I have not considered, I don't want people having to re-explain them to me.

Not really (far too many messages!), but I'd try searching for "assert" and "logical assert" and "launch nuclear missiles". They're long threads.

On Saturday, 21 May 2022 at 08:56:57 UTC, Dukc wrote:
> On Saturday, 21 May 2022 at 03:03:41 UTC, Walter Bright wrote:
>> This has been extensively and exhaustively debated several times in this n.g. I don't really want to re-litigate it.
>
> Can you provide links? I'm interested in the topic and if there are points brought up I have not considered, I don't want people having to re-explain them to me.

The best explanation of this that I've found is actually from an article about error handling in a research language called Midori. The following link goes directly to the relevant section:

http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-arent-recoverable-errors

If you want to read previous discussion about this from the D community, including several posts from Walter where he explains his position in his own words, there is a very long thread from 2014 here:

https://forum.dlang.org/thread/m07gf1$18jl$1@digitalmars.com

On Saturday, 21 May 2022 at 03:05:08 UTC, Walter Bright wrote:
> On 5/19/2022 11:40 PM, 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?
>
> Asserts are *not* for validating program input. Please do not use them for that. They are for checking that the program's logic is correct. If an assert is tripped, it is a bug in the program, not a problem with user input.

I don't agree, that 'tripping an assert' == 'a bug in your program'.

It may well ward off a potential bug (by asserting before hand, to prevent a bug).

But I can do this with exceptions too.

The main reason I'd chose to catch exceptions, rather than an assert, is in a situation where I want to *both* test and handle 'expected' conditions.

I'd use an assert where I don't want to handle any 'unexpected' conditions.

I rarely use assert in any case, as the software I develop is very user friendly ;-)

But this argument is like the argument of whether you should use your left foot, or your right foot to brake.

On Sunday, 22 May 2022 at 02:51:24 UTC, forkit wrote:
>
> I'd use an assert where I don't want to handle any 'unexpected' conditions.
>

e.g. out of memory. no disk space left, etc...

On 5/21/2022 7:51 PM, forkit wrote:
> I don't agree, that 'tripping an assert' == 'a bug in your program'.

That's what they're designed for. If you want to use them for some other purpose, feel free, but you'll have to take responsibility for the results.

> e.g. out of memory. no disk space left, etc...

You're better off with:

    printf("fatal error\n");
    exit(1);

On 5/20/2022 9:14 PM, Siarhei Siamashka wrote:
> On Saturday, 21 May 2022 at 02:55:25 UTC, Walter Bright wrote:
>> On 5/20/2022 12:01 AM, Siarhei Siamashka wrote:
>>> You skipped my comment about default unstable sort in Phobos, but such decision also erodes safety to some extent.
>>
>> The language and Phobos are two different things.
> 
> I disagree. The language can't become popular without a good standard library that is bundled with it out of the box. Phobos is very much relevant to the topic of this thread and hand waving "oh, but the core language is okay" doesn't help.

The language is where the guarantees come from, not the library.