https://issues.dlang.org/show_bug.cgi?id=17297

b2.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com

--- Comment #1 from b2.temp@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.

--

https://issues.dlang.org/show_bug.cgi?id=17297

Marco Leise <Marco.Leise@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Marco.Leise@gmx.de

--- Comment #2 from Marco Leise <Marco.Leise@gmx.de> ---
A previous bug report about rt_finalize and @nogc is issue 15246. It takes a look from a different angle, but boils down to the same fundamental issues. Points 1/ (OOP nature) and 2/ (non-inheritance of ~this) from my previous commentator are also discussed there and I gave an example of an "OOP nature" case that I would like to cross post here for illustration purposes...

Quote:

If we did in fact have virtual destructors like C++, the general rule with inheritance applies: The derived thing must be usable everywhere the base class is used. That disallows the removal of attributes on virtual function overrides:

class C {
   ~this() @safe
}

class D {
   override ~this(); // @system
}

void foo(C c) @safe
{
   // Destroying D is unsafe, but we can't statically check,
   // because for all we know it is at least a C.
   destroy(c);
}

void main()
{
   foo(new D);
}

--

https://issues.dlang.org/show_bug.cgi?id=17297

Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |simen.kjaras@gmail.com
         Resolution|---                         |DUPLICATE

--- Comment #3 from Simen Kjaeraas <simen.kjaras@gmail.com> ---


*** This issue has been marked as a duplicate of issue 15246 ***

--

https://issues.dlang.org/show_bug.cgi?id=17297

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|b2.temp@gmx.com             |

--