On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
Dukc
ajieskola at gmail.com
Thu Mar 4 23:42:58 UTC 2021
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.
More information about the Digitalmars-d-announce
mailing list