[Issue 17297] Object.~this not being @nogc is severely limiting @nogc applicability

2020-03-20 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17297

Basile-z  changed:

   What|Removed |Added

 CC|b2.t...@gmx.com |

--


[Issue 17297] Object.~this not being @nogc is severely limiting @nogc applicability

2018-02-07 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17297

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #3 from Simen Kjaeraas  ---


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

--


[Issue 17297] Object.~this not being @nogc is severely limiting @nogc applicability

2017-04-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17297

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #2 from Marco Leise  ---
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);
}

--


[Issue 17297] Object.~this not being @nogc is severely limiting @nogc applicability

2017-04-06 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17297

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

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

--