The current GC cannot allocate within a destructor because of the fact that it has to acquire a global lock on the GC before calling the actual destructor, meaning that attempting to allocate or do anything that requires a global lock on the GC is impossible, because the lock has already been acquired by the thread. Admittedly this isn't the way it actually fails, but it is the flaw in the design that causes it to fail.
Destructors and finalizers are the same thing. They are declared the same, function the same, and do the same things. In D, the deterministic invocation of a destructor is a side-effect of the optimization of allocations to occur on the stack rather than the heap, whether this is done by the user by declaring a value a struct, or by the compiler when it determines the value never escapes the scope. Currently the GC doesn't invoke the destructor of a struct that has been heap allocated, but I view this as a bug, because it is the same thing as if it had been declared as a class instead, and a destructor must take this into account, and not be dependent on the deterministic destruction qualities of stack-allocated values. On 5/5/14, Brian Rogoff via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Monday, 5 May 2014 at 14:17:04 UTC, Orvid King via > Digitalmars-d wrote: >> Also, the @nogc for destructors is specific to the current GC, >> and is a limitation that isn't really needed were destructors >> implemented properly in the current GC. > > How does one implement destructors (described below) properly in > a garbage collector? > > I'm a bit puzzled by the recent storm over destructors. I think > of garbage collected entities (classes in Java) as possibly > having "finalizers", and scoped things as possibly having > "destructors". The two concepts are related but distinct. > Destructors are supposed to be deterministic, finalizers by being > tied to a tracing GC are not. Java doesn't have stack allocated > objects, but since 1.7 has try-'with resources' and AutoCloseable > to cover some cases in RAII-like fashion. My terminology is from > this http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html > > IMO, since D has a GC, and stack allocated structs, it would make > sense to use different terms for destruction and finalization, so > what you really want is to properly implement finalizers in your > GC. > I'm a lot more reluctant to use classes in D now, and I'd like to > see a lot more code with @nogc or compiled with a the previously > discussed and rejected no runtime switch. > > Interestingly, Ada finalization via 'controlled' types is > actually what we call destructors here. The Ada approach is > interesting, but I don't know if a similar approach would fit > well with D, which is a much more pointer intensive language. > > >
