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.

And technically, a range error does not allocate.

https://github.com/dlang/druntime/blob/306bd965ea9d83bad7e5444ff9d5e1af1a6d934a/src/core/exception.d#L472-L485

But there is still a possibility of allocation if you happen to rehash 
an AA.

-Steve