GC has a "barbaric" destroyng model, I think

[Andrey Derzhavin via Digitalmars-d-learn]

        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.