Destructors vs. Finalizers

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 26 July 2017 at 15:15:03 UTC, Steven Schveighoffer 
wrote:
> On 7/26/17 10:57 AM, Guillaume Piolat wrote:
>
>> I'll defend the view point that there is _nothing_ useful to 
>> do in a finalizer except to check if the destructor has 
>> already been called.
>
> The thing to do in a finalizer that is useful is to release any 
> non-GC resources.
>
> -Steve

Interesting case.

Do we assume the finalizer is always called after the destructor?

- If yes, then releasing these non-GC resources could have been 
possible in the destructor too. The only lost generality would be 
if releasing such non-GC resources would be faster from the GC 
thread (could well be since pooled).

- else, it's a case of the finalizer being calld by the GC and 
the destructor not being called. Is this considered a bug?
|
|   - If yes, then point of releasing resources is moot since we 
have a bug.
|
|   - If not, it means we want to allow not calling destructors.
|   |
|   |   => this implies we think finalizers will be called
|   |      I'll make claim this works for process-wide resources 
somehow (we stopped the last debate here), but not transient ones 
(eg: mutex) because of false pointers. The finalizer might be 
released late.

 From these premises I conclude that the instructions given to new 
D programmers would be:

   1. you should destroy resources deterministically

   2. however GC objects owning resources may release them in 
their finalizer
     * except if you can't release them from any thread
     * except if these resources should be released before the GC 
shutdown (and then you have to explain why finalizer might not be 
called right now).