GC has a "barbaric" destroyng model, I think

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, February 11, 2015 21:40:30 Orvid King via Digitalmars-d-learn wrote:
> 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.

Yeah. And what it comes down to is that you don't access anything on the GC
heap from a class' finalizer, which seriously limits what you can do with
them. And yes, that can suck, but there isn't an easy solution - especially
when you take cyclical references into account. Basically, don't use class
finalizers unless you have to, and even then, only use them to access stuff
that isn't on the GC heap.

- Jonathan M Davis