RFC: Change what assert does on error

[Jonathan M Davis]

On Friday, July 4, 2025 5:09:27 PM Mountain Daylight Time Timon Gehr via Digitalmars-d wrote:
> 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.

This is particularly true if RAII is used. For instance, the way that MFC
implemented turning the cursor into an hourglass was with RAII, so that you
just declared the thing, so when the variable was created, the cursor turned
into an hourglass, and when the scope exited, the variable was destroyed,
and the cursor went back to normal.

RAII is used less in D than in C++ (if nothing else, because we have scope
statements), but it's a design pattern that D supports, and programmers can
use it for all kinds of stuff that has absolutely nothing to do with memory
allocations.

Another relevant example would be that RAII could be used to log when a
scope is entered and exited based on when the object is created and
destroyed. If the destructors are skipped, then that logging will be
skipped, and it could easily be part of what the programmer wants in order
to be able to debug the problem (and if they don't realize that the
destructors may be skipped, the logs could be pretty confusing when the
destructor is skipped).

So, yeah, there's no reason to assume that destructors have anything to do
with allocating or freeing anything. They're just functions that are
supposed to be guaranteed to be run when a variable of that type is
destroyed. They can be thought of as just being another form of scope(exit)
except that they're tied to the type itself and so every object of that type
gets that code instead of the programmer having to type it out wherever they
want it.

- Jonathan M Davis