RFC: Change what assert does on error

[Richard (Rikki) Andrew Cattermole]

On 05/07/2025 12:41 AM, Sebastiaan Koppe wrote:
> On Sunday, 29 June 2025 at 18:04:51 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> Hello!
>>
>> [...]
>>
>> Destroy!
> 
> Somewhat unrelated to this discussion, but I have come of the opinion 
> that a large portion of asserts are actually people 'protecting' their 
> libraries, which, if they designed them right, wouldn't need an assert 
> in the first place.
> 
> You can typically tell where they are when you see documentation like 
> "it is forbidden to call this method before X or after Y".
> 
> Often these things can be addressed by encoding the constraints in the 
> types instead, and in the process eliminating any need for an assert at 
> all.
> 
> It would be interesting to see how many actual uses of assert in common 
> D libraries are actually the consequence of such design decisions.

This is a key reason why I think asserts have to be recoverable.

Unfortunately a very large percentage of usage of it, use it for logic 
level errors, and these must be recoverable.

Contracts are a good example of this, they are inherently recoverable 
because they are in a functions API, they are not internal unrecoverable 
situations!

Its going to be easier to take the smallest use case that is 
unrecoverable dead process, and use a different mechanism to kill the 
process in these cases.