RFC: Change what assert does on error

[Walter Bright]

On 6/30/2025 2:18 PM, Sebastiaan Koppe wrote:
> Just know that the idea of exiting directly when something asserts on 
> the pretense that continueing makes things worse breaks down in multi-threaded 
> programs.

An assert tripping means that you've got a bug in the program, and the program 
has entered an unanticipated, unknown state. Anything can happen in an unknown 
state, for instance, installing malware. As the threads all share the same 
memory space, doing something other than aborting the process is highly unsafe.

Depending on one's tolerance for risk, it might favor the user with a message 
about what went wrong before aborting (like a backtrace).

But continuing to run other threads as if nothing happened is, bluntly, just 
wrong. There's no such thing as a fault tolerant computer program.

D is flexible enough to allow the programmer to do whatever he wants with an 
assert failure, but I strongly recommend against attempting to continue as if 
everything was normal.

BTW, when I worked at Boeing on flight controls, the approved behavior of any 
electronic device was when it self-detected a fault, it immediately activated a 
dedicated circuit that electrically isolated the failed device, and engaged the 
backup system. It's the only way to fly.