[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