Destructor semantics

[Michel Fortin]

On 2010-08-12 15:18:33 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer <jgreer at doubletake.com>  wrote:
> 
>> I think you misunderstand what I was saying.  The compiler doesn't decide
>> any of that.  The programmer conserned with correctness has the option of
>> making his finalizer complain about unfreed resources.  I language
>> shouldn't be your nanny, but it should encourage and enable you to do the
>> right thing.  There is just no substitute for knowing how to program.
> 
> So you mark a struct something like:
> 
> @noheap struct File
> {...}
> 
> That's a possible solution.  I just don't like the blanket assumptions  
> being made.

I don't like this assumption either. But short of a type system that 
track the owner of each memory block, all our choices will rely on the 
assumption that the programmer has done the finalizer right. Separating 
the concept of destructor and finalizer should help people realize the 
difference, but finalizers will still be a very tricky thing.

By the way, there's currently a couple of structs in Phobos that aren't 
GC-friendly -- they basically have races when their destructor is 
called during the collection cycle (and File is one of them). I'm more 
and more of the opinion that the language itself should just block you 
from dereferencing members in the finalizer (with some sort of cast to 
bypass this if needed, but then you'll think twice about what you're 
doing). See bug 4624:
<http://d.puremagic.com/issues/show_bug.cgi?id=4624>


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/