GC has a "barbaric" destroyng model, I think

[Orvid King via Digitalmars-d-learn]

On Wednesday, 11 February 2015 at 21:34:00 UTC, Andrey Derzhavin 
wrote:
>        If we are using a DMD realization of destroying of 
> objects, happens the following: at the calling the «destroy» 
> method the calling of dtor takes place always, and then the 
> object which is being destroyed is initialized by the default 
> state. In other words, after calling «destroy» method, there is 
> no way of getting an access to the members of the object that 
> is being destroyed (it is meant, that the members are the 
> references). GC works the same way.
> 	This approach in case of manual calling of «destroy» method 
> has predictable and understandable consequences (there is no 
> reasone to use the object being destroyed). But if GC performes 
> the destroying of the objects, a lot of errors appear at the 
> accessing to the members which are references, because some of 
> them have already been destroyed (access to the members is 
> realized in dtors). Such situations can be avoided, by using 
> «@nogc» keyword. Howewer «@nogc» keyword doesn't protect us 
> from using the references in dtors: we can assign some values 
> to the refernces, we can have access to some members by the 
> references and assign them some values.That is not correct in 
> itself.
>
> If GC starts destroying some group of the objects, it could be 
> more correct, if the calls of dtros are occured of all objects 
> in a group before phisical memory releasing. Or GC must call 
> dtors of the objetcts only, which noone refers to.

The finalization order issue is one that is actually rather 
difficult, if not impossible, to solve without a precise GC. It 
gets even more complicated when you have to deal with cyclic 
references in finalizable allocations.