auto classes and finalizers

[kris]

Bruno Medeiros wrote:
> kris wrote:
> 
>>
>>
>> Regardless of how it's implemented, what's needed is a bit of 
>> consistency. Currently, dtors are invoked with two entirely different 
>> world-states: with valid state, and with unspecified state. What makes 
>> this generally unworkable is the fact that (a) the difference in state 
>> is often critical to the operation of the dtor, and (b) there's no 
>> clean way to tell the difference.
>>
> 
> Hum, from what you said, follows a rather trivial alternative solution 
> to the problem: Have the destructor have an implicit parameter/variable, 
> that indicates whether it was called explicitly or as a finalizer (i.e, 
> in a GC run): (This would be similar in semantics to Sean's suggestion 
> of separating the destruction and finalize methods)
> 
> class LinkedList {
>   ~this() { // called manually/explicitly and automatically
>     if(explicit) {
>       for( Node n = top; n; ) {
>         Node t = n->next;
>         delete n;
>         n = t;
>       }
>     }
>     // ... finalize here
>   }
>   ...
> 
> Would this be acceptable? How would this compare to other suggestions? I 
> can think of a few things to say versus my suggestion.

Perhaps it would be better as an optional parameter? This certainly 
would allow for lazy dtors that don't need timely cleanup. Although I 
can't think of any reasonable examples to illustrate with.

However, it clearly exposes the "uneasy" status that a dtor might find 
itself in. For that reason it seems a bit like a hack on top of a queasy 
problem (to me). In cases like these I tend to think it's better to 
start off constrained and deterministic (remove those 'lazy' 
non-deterministic dtor invocations), and then optionally open things up 
as is deemed necessary, or when a resolution to the non-determinism is 
found.