Is it possible to deinitialize the class without calling the gc?

[12345swordy]

On Saturday, 4 August 2018 at 04:51:55 UTC, Adam D. Ruppe wrote:
> On Saturday, 4 August 2018 at 02:21:48 UTC, 12345swordy wrote:
>> Which is converted to void type when passing the object to 
>> rt_finalize, which causes to lost all type information.
>
> It still has run-time type information, but indeed, the compile 
> time info is lost.
>
>
>>> Child classes have independent destructors which do not need 
>>> to adhere to the attributes of the parent class destructor,
>> Why is this an issue? Simply don't call them.
>
> Then the object isn't fully destroyed....
I know the risks behind it, @nogc and others only care that 
non- at nogc functions are not called. That's why I propose 
destructor_hook function for clear transparency.

>
> So, even with the changes I outlined above, @nogc destroy would 
> be valid if and only if it is passed a class whose *static* 
> type explicitly includes the @nogc guarantee, which is only 
> allowed if all the parent chains, all the way up, have either 
> trivial destructors or their own @nogc guarantees.
I was thinking along of lines of "Canary in a coal mine" when it 
comes to class static typing if the compiler couldn't determine 
the child classes that are currently inheriting the current 
non-final class. A system attribute "Canary" Boolean value can be 
override by compiler to set it to false if it detects a "Gas 
leak".

> But you can derive the bits you need from compile time info if 
> the child destructors were restricted as described above. 
> Unless I'm missing something too....
>
You want me to introduce the "restrict" keyword in my dip for 
maximum safety? Fine, I don't mind.

> of course you could just do the sane thing and pretend @nogc 
> doesn't exist. then this stuff becomes a lot easier and you can 
> just get back to work.
People are treating classes like a neglected child due to the 
lack of @nogc. We could solve the "is it @nogc?" issue by having 
the compiler provide a strict readonly body of the 
function/class/module (after all the meta-programming has been 
applied obviously) and statically analyze it, but there are fears 
that this will lead to AST, and I don't have enough spare time to 
argue all day on this atm.

-Alexander