On 5/21/2022 12:06 PM, Paul Backus wrote:
> 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

https://github.com/dlang/dlang.org/pull/3307

On Sunday, 22 May 2022 at 03:10:45 UTC, H. S. Teoh wrote:
>

An assert is useful in the context of a proposition about a program, where the proposition is asserted to hold.

That is all it is really.

I think people try to make more of it, than they should ;-)

e.g.

assert(something != NULL);

But I can handle this same proposition without an assert.

Some history:

https://people.eecs.berkeley.edu/~necula/Papers/FloydMeaning.pdf

https://dl.acm.org/doi/pdf/10.1145/987531.987535

On Saturday, 21 May 2022 at 19:06:58 UTC, Paul Backus wrote:
> 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
>
> ....

A research operating system.

The language was initially called M# and later System C#.

On Saturday, 21 May 2022 at 19:06:58 UTC, Paul Backus wrote:

>
> 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

I have always had problems with this classification because real world systems are modular, and bugs in a module are often treated as exceptions by another module. That is, many systems using plugins try to recover from bugs in a plugin. In a sense, the plugin itself becomes an input that the host has to validate.

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

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

How about a compile time option to NOT remove assert in release?

On Sunday, 22 May 2022 at 09:33:25 UTC, Max Samukha wrote:
> On Saturday, 21 May 2022 at 19:06:58 UTC, Paul Backus wrote:
>
>>
>> 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
>
> I have always had problems with this classification because real world systems are modular, and bugs in a module are often treated as exceptions by another module. That is, many systems using plugins try to recover from bugs in a plugin. In a sense, the plugin itself becomes an input that the host has to validate.

If there is no isolation boundary between the plugin and the host, then the host cannot reliably recover from bugs in the plugin. The next section of the article, "Reliability, Fault-Tolerance, and Isolation," goes into much more detail about this.

On 5/22/2022 2:33 AM, Max Samukha wrote:
> I have always had problems with this classification because real world systems are modular, and bugs in a module are often treated as exceptions by another module. That is, many systems using plugins try to recover from bugs in a plugin. In a sense, the plugin itself becomes an input that the host has to validate.

This is a faulty system design. There's nothing stopping modules from corrupting the memory of the caller.

The correct approach is to run those modules as separate processes, where they can only corrupt themselves. It's why operating systems support processes and interprocess communications.