Auto syntax REALLY revisited

[Don Clugston]

Mike Capp wrote:
> In article <43FAF3AC.2080609 at nospam.org>, Georg Wrede says...
>>> I want another word substituted
>>> for 'auto'! We can't have it mean "autotype and/or RAII", at the same
>>> time. That is just too much of a disgrace.
> 
> Amen.
> 
>> To summarize:
>>
>> It would be handy to have a class that _requires_ RR instantiation.
> 
> And it's not that big a leap. Currently I believe you can declare a class "auto"
> to force all instances to be auto; you'd just have to beef up this rule to say
> that ONLY instances of auto classes can be declared auto.
> 
> This is probably going to get me chased out of town with torches and pitchforks,
> but I'd actually like to go one step further and rule that ONLY auto classes can
> define destructors. The thinking being that if you care enough about a managed
> resource to write a destructor to release it, you almost certainly want that
> destructor called deterministically. 

You're saying, abolish finalisers from the language. Radical.
But I agree. I have NEVER seen a single good use for a finaliser. I've 
only ever seen them used as "poor man's destructors". But I'll change my 
mind if anyone can show a use for them. Any takers?

I bet removing finalisers would simplify the gc.

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. Whenever the 
gc runs, if it finds that it is able to collect an object which has a 
destructor, instead of calling it as a finaliser, it should assert -- a 
memory leak bug has been found.
Alternatively, you could just use the C++ method and and perform the 
check only at the end of the program. (But it would be cool to have a 
function checkForMemoryLeaks() which could be run at any time, for 
anyone who still wants to use manual memory management. By using 
mark-and-sweep, you can detect a memory leak much earlier than in C/C++).

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.

Relying on the garbage collector to call it
> for you in a timely fashion is almost certainly setting you up for a nasty
> surprise. Far too many people still seem to think that GC is a panacea for
> resource management generally, not just memory management, and until they're
> jolted out of that I don't have much hope for D's RAII support improving.

Agreed.

  > (Incidentally, what's with this "RR"??? I've never seen it before in 
10 years of
> writing C++. If you mean RAII, it's probably less confusing to the reader to say
> RAII, however silly an acronym it might be.)

You could think of RAII as "Release At Imminent Incineration" <g>
Or come up with a better interpretation of the letters.

> 
> cheers,
> Mike
> 
>