RFC: Change what assert does on error

[Timon Gehr]

On 7/5/25 00:11, Dennis wrote:
> On Friday, 4 July 2025 at 20:49:56 UTC, Timon Gehr wrote:
>> Skipping destructors may leave the program in an inconsistent and 
>> unpredictable state, including memory corruption due to lack of 
>> cleanup of stack pointers.
> 
> I'm sorry but I have to ask this question a third time now: What are you 
> doing in your destructors that affects your error handler's output?

This specific concern is not something I know I have already 
experienced, mostly because cleanup in fact happens in practice. 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.

> How 
> does *not* cleaning up result in memory corruption, instead of just an 
> irrelevant memory leak? From my perspective calling free() after the 
> program entered an invalid state is still more risky than not calling 
> it.

I'd prefer to be able to make this call myself.

> I feel like I'm missing something about your program because this:
> 
>> It writes a file with the full interaction log that leads to the crash
> 
> Doesn't sound like something that would fail when cleanup is skipped.
> 

In principle it can happen. That's a drawback. 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 am way more concerned about 
predictable language behavior. If I bracket a piece of code using a 
constructor and a destructor, I want this to be executed no matter what 
happens in the middle.

A destructor can do anything, not just call `free`. Not calling them is 
way more likely to leave behind an unexpected state than even the 
original error condition. The state can be perfectly fine, it's just 
that the code that attempted to operate on it may be buggy.