On the D Blog--Symphony of Destruction: Structs, Classes, and the GC

[Steven Schveighoffer]

On 3/4/21 6:42 PM, Dukc wrote:
> On Thursday, 4 March 2021 at 13:54:48 UTC, Mike Parker wrote:
>>
>> The blog:
>> https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ 
>>
> 
> "Some examples: attempting to index an associative array can trigger an 
> attempt to allocate a RangeError if the key is not present; a failed 
> assert will result in allocation of an AssertError; calling any function 
> not annotated with @nogc means GC operations are always possible in the 
> call stack. These and any such operations should be avoided in the 
> destructors of GC-managed objects."
> 
> I don't understand this part. If an assert was failing, the program is 
> going to terminate anyway, so InvalidMemoryOperationError is no problem. 
> Well, it might obfuscate the underlying error if there is no stack 
> trace, but banning `assert`ing in anything that could be called by a 
> destructor sounds too drastic to me. Even the lowest level system code 
> tends to contain asserts in D, at least in my codebase. If asserting is 
> banned, destructors can do faily much nothing. I'd think it's much more 
> practical to redefine the assert failure handler if 
> InvalidMemoryOperationError due to a failed assert is a problem.

One further note: you want to avoid InvalidMemoryOperationError AT ALL 
COSTS if you can. Why? Because it identifies not the file or line which 
triggered the invalid memory operation, but the place where it's thrown 
in druntime (currently here: 
https://github.com/dlang/druntime/blob/306bd965ea9d83bad7e5444ff9d5e1af1a6d934a/src/core/exception.d#L539) 
with NO stack trace.

So if you get an IMOE, you will have no idea why. This is a defect in D 
in my opinion, and needs fixing. I've spent hours chasing these types of 
things down.

-Steve