auto classes and finalizers

[Regan Heath]

On Thu, 6 Apr 2006 00:08:43 -0400, Jarrett Billingsley <kb3ctd2 at yahoo.com>  
wrote:
> "Dave" <Dave_member at pathlink.com> wrote in message
> news:e11vjk$1fou$1 at digitaldaemon.com...
>> Long and short of it is I like Mike's ideas regarding allowing dtors for
>> only
>> auto classes. In that way, the GC wouldn't have to deal with finalizers  
>> at
>> all,
>> or at least during non-deterministic collections. It would also still
>> allow D to
>> claim RAII because 'auto' classes are something new for D compared to  
>> most
>> other
>> languages.
>
> Hmm.  'auto' works well and good for classes whose references are local
> variables, but .. what about objects whose lifetimes aren't determined by
> the return of a function?
>
> I.e. the Node class is used only in LinkedList.  When a LinkedList is
> killed, all its Nodes must die as well.

Assuming the nodes contain reference(s) to resources (other than memory)  
that need to be released, right? You don't need to delete them to free  
memory, the GC should free them eventually.

The same is true for any non-auto object which contains a sub-object which  
has a reference to a resource that must be released deterministically.  
Isn't the solution therefore to make every object containing an 'auto'  
object 'auto' as well.

How about this:

1) If a class has a dtor it must be auto, eg.

      class A { ~this() {} } //error A must be auto
auto class A { ~this() {} } //ok


2) If a class contains a reference to an auto class, it must also be auto,  
eg.

      class B { A a; } //error A is auto, B must be auto too
auto class B { A a; ~this() { delete a; } } //ok

2a) If that class does not have a dtor it is an error.
2b) If that dtor does not delete the 'a' reference it is an error.

Speculative:
Can the compiler in fact auto-generate a dtor for this class? One that  
deletes all auto references.
Can it append (not prepend) that auto-generated dtor to any user supplied  
one?


3) Remove the other 'auto' class syntax, i.e.

class A {}
auto A a = new A();

It's either a class with resources that need to be freed, or it's not. Is  
there any need for a middle ground?
(this also removes the double use of auto, that'll make some people happy)


Pros:
1. no more weird crashes in dtors where people reference things which are  
gone.
2. compiler finds/corrects most reference leaks automatically.
3. no more double use of 'auto'.

Cons:
1. less flexible?


I can already think of a situation where this might be too inflexible.  
What happens if you want to share an object between multiple objects, for  
example:
   auto class DatabaseConnection {}

a singelton style shared connection to a database. You have several  
classes which share that connection, i.e.
   class UserQuery { DatabaseConnection c; }

using the rules above these classes would either be illegal, or get a dtor  
which auto-deletes the DatabaseConnection.

The solution? Perhaps it's reference counting in the DatabaseConnection?  
Perhaps it's a new syntax to mark something 'shared', preventing the  
compiler auto-deleting it. eg.
   class UserQuery { shared DatabaseConnection c; }

Perhaps this cure is worse than the disease? Thoughts?

Regan