RFC: Change what assert does on error

[Dennis]

On Friday, 4 July 2025 at 23:09:27 UTC, Timon Gehr wrote:
> In principle it can happen. That's a drawback.

Well, in principle the opposite can also happen when we enter a 
state that's by definition unexpected. I'm looking for real world 
data that shows which strategy is best.

> I'd prefer to be able to make this call myself.
> (...)
> There is no upside for me. Whatever marginal gains are 
> achievable by e.g. eliding cleanup in nothrow functions, I 
> don't need them.

I understand, and I'd gladly grant you an easy way to disable 
nothrow inference or nothrow optimizations. But having D users 
split up in two camps, those who want 'consistent' finally blocks 
and those who want efficient finally blocks, is a source of 
complexity that hurts everyone in the long run.

> Anyway, it is easy to imagine a situation where you e.g. have a 
> central registry of all instances of a certain type that you 
> need to update in the destructor so no dangling pointer is left 
> behind.
> (...)
> Not calling them is way more likely to leave behind an 
> unexpected state than even the original error condition.

And this is still where I don't get why your error handler would 
even want an 'expected' state. I'd design it as defensive as 
possible, I'm not going to traverse all my program's data 
structures under the assumption that invariants hold and pointers 
are still valid. The error could have happened in the middle of 
rehashing a hash table or rebalancing a tree for all I know. And 
if that's the case, I'd rather have my crash reporter show me the 
broken data structure right before the crash, than a version that 
has 'helpfully' been corrected by scope guards or destructors.