RFC: Change what assert does on error

[Adam Wilson]

On Sunday, 6 July 2025 at 16:21:59 UTC, Walter Bright wrote:
> It's not reasonable if the software is controlling the 
> radiation dosage on a Therac-25, or is empowered to trade your 
> stocks, or is flying a 747.

The amount of software written by volume that falls into this 
category is minuscule. At best.

> Executing code after the program crashes is always a risk, and 
> the more code that is executed, the more risk. If your software 
> is powering the remote for a TV, there aren't any consequences 
> for failure.

This is the vast majority of software written in general and D in 
specific.

In general, there is no value in enforcing the strictures of the 
former on to the later. It's a business decision for them and 
they simply don't need to pay that cost.

You won't make that software any better because nobody will use 
your language to write code with it, they'll use something that 
does the sane default (for them).

You can't improve the world's overall software quality by 
throwing a hissy-fit when they won't do it your perfect way, 
because they'll just walk away and use something else altogether.

Is it not better to get some improvements out there in general 
use, even if the result is less than perfect?

You have just discovered another one of D's "big back doors" in 
terms of adoption. You're being unreasonable and people just 
quietly leave to find something reasonable.