Destructors vs. Finalizers

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 26 July 2017 at 22:29:50 UTC, Steven Schveighoffer 
wrote:
> Today, the finalizer is essentially a last-effort to clean up 
> resources that would otherwise leak.

My point is that this "last chance" to clean up resources should 
only be used to tell deterministic destruction wasn't acheived 
(for reasons given in my former post: it's _too hard to explain_ 
how to do resource management else).



> The reason deterministic destruction sucks today is because 
> once you go 2 levels deep, the only tool available (~this) 
> cannot release any resources (because it's not legal to access 
> GC-allocated members inside ~this).

You already know it, but if you commit to not doing anything in 
the finalizer case, then ~this doesn't suck, it works as a 
destructor and the restrictions lift.
So "suck" is a bit strong.


> Look at any library that contains such non-memory resources. 
> These things inevitably implement some sort of "close()" or 
> "release()" function, which does the deterministic destruction. 
> It's just a destructor with a different name.

You could also merge the close() function with ~this() and remove 
~this()-called-as-finalizer, which is the position I defend.

If I count correctly there are 3 restrictions on the type of 
resource that can be GC-finalized:
- can be destroyed from any thread
- do not depend on another resource released by GC finalization, 
for it's own release 
https://forum.dlang.org/post/pmulowxpikjjffkrscct@forum.dlang.org
- can have a delayed finalization

That's the reason why I thnk deterministic destruction for 
non-memory resources is easier than more mixed strategies.