[Issue 17297] Object.~this not being @nogc is severely limiting @nogc applicability
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Thu Apr 6 05:47:09 PDT 2017
https://issues.dlang.org/show_bug.cgi?id=17297
b2.temp at gmx.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |b2.temp at gmx.com
--- Comment #1 from b2.temp at gmx.com ---
> Object.~this not being @nogc is severely limiting @nogc applicability
I agree.
There's two main reasons for the problem:
1/ OOP nature. One may call `destroy()` from an instance that's casted to a
base type
2/ (the biggest issue IMO) destructors are not called by inheritance (like
`super()` for constructors). destructors are found, from the most derived to
the base using the `TypeInfo_Class` of each generation (indeed in
`rt_finalize2()`). The TI just stores a pointer to a `void function()` and not
to a `@nogc void function()`.
A workaround (that works since i currently use it) is not to use `destroy()`
but create your own equivalent, templatized, able to infer `@nogc`. To solve
the first issue you have to assume that the instance that passed to the custom
`destroy()` function is the most derived (i.e the traits to get `__xdtor`
doesn't return an ancestor `__xdtor`). Then to solve the second issue the
`__xdtor` in the ancestors must be called by inheritance, which can be done by
mixing a template at each generation.
There would also be the idea of an `@assumenogc` attribute. I remember that
someone else needed it for the `IAllocator` interface.
--
More information about the Digitalmars-d-bugs
mailing list