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
