RFC: Change what assert does on error

[Dukc]

On Wednesday, 2 July 2025 at 23:26:36 UTC, Walter Bright wrote:
>> but it is worth nothing they tend to happen *just before* a 
>> task actually executes the problematic condition. Sure, you 
>> weren't supposed to even get to this point, but you can still 
>> reason about the likely extent of the mystery
>
> If a variable has an out of bounds value in it, it cannot be 
> determined why it is out of bounds. It may very well be out of 
> bounds because of memory corruption elsewhere due to some other 
> bug or a malware attack.

If you have malware already installed, what would crashing and 
restarting the process help? You'd need to reinstall your whole 
OS instead. Of course we can't do that on assert failure, except 
maybe if we're really talking about no less than a Boeing flight 
control computer.

Our current response is that we terminate the current process, 
assuming or hoping that the cause is within it. That's good 
enough for a default response.

You're right, I think, that a lighter response (like throwing a 
catchable exception) would be a bad response in a C or C++ 
program, as there's no mechanism limiting the fault domain within 
the program. However, in D we do have such a mechanism. If you 
call a `@safe pure` function and it triggers an assertion failure 
(or another error), you do know that the parts of the program the 
called function doesn't reach are still untouched.

Yes, potentially it could still have corrupted other parts if 
there is `@trusted` abuse. But so can buggy program potentially 
have corrupted the OS if it writes to it's config file, yet we 
are fine with restarting it. This is no different.

And yes, the bug might not be in the called function but in the 
parameters or global `immutable` data. But so can the bug in an 
asserting program be in the OS C library, yet we are fine with 
terminating only the program and not the whole OS. This is no 
different.