Destructor semantics

[Steven Schveighoffer]

On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer <jgreer at doubletake.com>  
wrote:

> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in
> news:op.vhbtwjhoeav7ka at localhost.localdomain:
>
>>> Logically speaking if an object isn't destructed, then it lives
>>> forever and if it continues to hold it's resource, then we have a
>>> programming error.  The GC is for reclaiming memory, not files.  It
>>> can take a long time for a GC to reclaim an object and you surely
>>> don't want a file locked for that long anymore than you want it held
>>> open forever.  My point is, that it is a programming error to expect
>>> the GC be involved in reclaiming anything but memory.  IMO, the best
>>> use of a finalizer is to error out if an object holding a resource
>>> hasn't been destructed, because there is obviously a programming
>>> error here and something has leaked. GCs aren't there to support
>>> sloppy programming.  They are there to make your life easier and
>>> safer.
>>
>> An open file maybe, but why should the compiler decide the severity of
>> not  closing the resource?  What if the resource is just some
>> C-malloc'd memory?
>>
>> Note, you are free to write your finalizer to do exactly what you want
>>  (print some error if it's called and the file's still open).  I just
>> don't  think the compiler should be involved in the decision, because
>> it's too  ill-equipped to make one.
>>
>> -Steve
>
> 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.

-Steve