Destructor semantics

[Joe Greer]

Jonathan M Davis <jmdavisprog at gmail.com> wrote in
news:mailman.260.1281553632.13841.digitalmars-d at puremagic.com: 

> On Wednesday, August 11, 2010 11:33:54 Michel Fortin wrote:
>> I'm not too sure that'll work very well. I think a better solution
>> would be to have a way to distinguish between a struct that can be
>> put on the GC heap and one that cannot. A struct that cannot go on
>> the GC heap make it safe to access GC-managed members in its
>> destructor, and thus can have a @safe destructor.
> 
> But couldn't the fact that a struct has a destructor make it so that
> it can't be declared anywhere but on the heap? The destructor itself
> could be what distinguishes them. I don't see a need for any other
> @attributes or whatnot to distinguish them.
> 
> - Jonathan M Davis
> 

Pardon me for sticking my nose in here.  I don't use D as of yet, but I 
do have a bit of experience in C++ and C#.  I think one of the classic 
ways of handling this sort of problem is to split destruction and 
finalization.  That is, the destructor is never invoked by the GC, only 
explicitly or when an object on the stack goes out of scope.  This means 
that everything referenced by the object is valid because it couldn't 
have been collected yet.  A finalizer can be provided to be invoked by 
the GC for limited cleanup.  Normally, this is never used, but sometimes 
is desirable.  Obviously, in the finalizer you can't count on anything 
allocated by the GC to still exist, however you could still free malloced 
memory here if you wanted or more likely complain that the object wasn't 
destructed when it should have been. 

I just haven't seen this idea tossed about yet, so I thought I would 
throw it out.

joe