https://issues.dlang.org/show_bug.cgi?id=17297
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from [email protected] --- > 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. --
