Finalizers, Destructors, RAII, GC

[Ola Fosheim Grøstad]

On Wednesday, 28 April 2021 at 22:05:31 UTC, sighoya wrote:
> Doesn't suffice ownership here? I mean you surely talk about 
> owned manually allocated memory inside a class.

The compiler currently doesn't know about ownership, but you 
might have a non-owning pointer to a resource-manager-object that 
is guaranteed to outlive the program for instance.

> But why the need at all for a finalizer and instead allow 
> non-empty destructors for gc allocated classes?
> Having both is confusing.

Because destructors should be reserved for deterministic 
destruction, where you can presume that there are no dangling 
pointers. You shouldn't be allowed to allocate such object on the 
GC-heap.

On the other hand, you should be allowed to subclass a 
GC-oriented finalizer based class and extend it with 
deterministic destruction.  I guess you could make the 
distinction some other way. The difference is that a finalizer is 
running on a partially destructed object, whereas a destructor is 
running on a valid object.

You don't need seperate functions at runtime, I guess, but the 
compiler has to know whether it is typechecking a finalizer or a 
destructor.

>> Or would it be better to simply forbid any cleanup in the GC? 
>> I kinda think so, but I also think many D users are used to 
>> letting the GC trigger cleanup on collection.
>>
>> What do you think?
>
> Probably not for gc managed resources, but what about making 
> class members reference counted or owned instead.

That is the big question, is it really necessary to allow the GC 
to manage other resources than memory?

I guess you could do it also for file descriptors, with a precise 
collector. Then it would scan also file descriptors and release 
those that no longer are referenced. But that is kinda 
esoteric... :-)

> Owned resources should be deleted automatically when a class 
> object is destructed and reference counted resources are 
> deleted if refcount goes to zero, which may occurs after 
> destruction but at least not before.

Yes, but this is tricky with a GC that isn't fully precise. The 
more objects that reference the ref-count the more likely you are 
to get a leak.