Auto syntax REALLY revisited

[Mike Capp]

In article <dtf7gr$1sla$1 at digitaldaemon.com>, Don Clugston says...
>
>You're saying, abolish finalisers from the language. Radical.
>But I agree. I have NEVER seen a single good use for a finaliser.

Woohoo! I'd almost given up.

(I have, several times, heard Java or .Net people enthuse about being able to
'resurrect' objects in their finalizers, but needless to say they never seem to
supply a reason why you'd want to do something so braindead. One can only stare
pityingly.)

>I bet removing finalisers would simplify the gc.

Yes... I was going to mention that, but I wasn't 100% sure and it's kind of
tangential to my main motivation, which is to slap people around the face with a
large halibut until they realize that GC is not the Second Coming for resource
management.

>However, there's still the issue of manual memory management. It would I 
>think be possible to allow RAII classes to be created on the heap with 
>new, and have the destructor called manually with delete.

I'm not convinced that it's worth supporting. As soon as you get into manual
destructor calls, you're separating the call from the object's lifetime, at
which point I don't consider it a destructor in any useful sense. It's just a
function that happens to do resource release, and I think that framing it in
those terms would help prevent sloppy thinking. ("But it's a destructor, it
can't possibly be called twice!")

>Of course, if RAII classes on the heap are forbidden, it's easy -- the 
>GC then never has to worry about destructors or finalisers, it can just 
>release memory.

That would be my preference in many ways - it's always easier to relax a
restriction later than to impose a new one - but if a RAII ref is being assigned
from the result of a function call, you don't know the actual type at compile
time, which would make stack allocation tricky.

cheers,
Mike