radical ideas about GC and ARC : need to be time driven?

[via Digitalmars-d]

On Tuesday, 13 May 2014 at 14:59:42 UTC, Kagamin wrote:
> On Tuesday, 13 May 2014 at 12:18:06 UTC, Manu via Digitalmars-d 
> wrote:
>> It completely undermines the point. If you're prepared to call
>> finalise, when you might as well call free... Every single 
>> detail
>> required to perform full manual memory management is required 
>> to use
>> finalise correctly.
>> I see absolutely no point in a GC when used with objects that 
>> require
>> you to manually call finalise anyway.
>
> Well, GC doesn't run immidiately, so you can't do eager 
> resource management with it. GC manages memory, not other 
> resources, and lots of people do see point in it: java and C# 
> are industry quality technologies in wide use.
>
>> ARC release is eager. It's extremely common that destructors 
>> either
>> expect to be called eagerly, or rely on proper destruction 
>> ordering.
>> Otherwise you end up with finalise again, read: unsafe manual 
>> memory
>> management :/
>
> No language will figure out all algorithms for you, but this 
> looks like a rare scenario: for example, kernel objects don't 
> require ordered destruction.
> Finalizer will be called when GC collects the object, it's a 
> last resort cleanup, but it's not as unsafe as it used to be.

It's not (memory) unsafe because you cannot delete live objects 
accidentally, but it's "unsafe" because it leaks resources. 
Imagine a file object that relies on the destructor closing the 
file descriptor. You will quickly run out of FDs...

I only see two use cases for finalizers (as opposed to 
destructors):

1.) Release manually allocated objects (or even ARC objects) that 
belong to the finalized object, i.e. releasing dependent objects. 
This, of course _must not_ involve critical external resources 
like FDs or temporary files.

2.) Implement weak references.