I might be hated for saying this but I still think the GC problem should not be apart of D language. Make it the user's or third party problem.

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.

On 7/27/17 4:23 AM, Guillaume Piolat wrote:
> 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).

Consider reference counting with cycles. The proposal from Walter/Andrei is to do reference counting to clean up everything but cycles. For cycles, the GC will take care of it.

So how do you do this correctly without having two separate mechanisms?

>> 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.

This is an unworkable solution. One simple time you forget to clean up deterministically and then you corrupt memory by using members that are already cleaned up.

Or, you disable calling destructors in the GC, and instead leak resources.

Or I suppose you could crash your application. This would be a fun bug to figure out...

-Steve

> Consider reference counting with cycles. The proposal from Walter/Andrei is to do reference counting to clean up everything but cycles. For cycles, the GC will take care of it.

That is the PHP way to do things. :) It's neat but I still think the only real thing to deal with resources is built-in ownership like Rust does it. But that's a bit out of question for D2 I suppose. What's the state of the RC approach?

For cycle in RC you either do it like other RC system and break cycles manually, or create a parent owner to own every things pointing to each other and having cycles.

On Thursday, 27 July 2017 at 11:43:37 UTC, Steven Schveighoffer wrote:
> This is an unworkable solution.

Not at all unworkable, it's much easier than mixed strategies.


> One simple time you forget to clean up deterministically and then you corrupt memory by using members that are already cleaned up.

Once again, this is the reason of the existence of the GC-Proof-resource-class, which have the GC warn you of non-deterministic destruction at debug time.

In the very case you mention it will tell you "you have forgot to release one resource T deterministically".

> Or, you disable calling destructors in the GC, and instead leak resources.

As I said in previous messages, not all resources can be destroyed by the GC: they have to fit into 3 different constraints.

I'll leave the discussion, you seem to ignore my arguments in what seems as an attempt to have the last word.