DIP74 & GC Destructors

[via Digitalmars-d]

On Tuesday, 16 June 2015 at 15:48:18 UTC, rsw0x wrote:
> On Monday, 15 June 2015 at 16:20:56 UTC, Marc Schütz wrote:
>> I hope we won't get builtin RC, but that's off-topic.
>
> I disagree, that's entirely on topic. I believe every modern 
> implementation of Ada relies solely on RC(while having GC 
> hooks.) Nobody really seems to have an issue with RC there. I 
> personally believe that immediate RC and GC solve completely 
> different issues of deterministic vs non-deterministic resource 
> management. Trying to shoehorn them into the same thing gets 
> you a broken, slow implementation(see: C++'s shared_ptr. It's 
> dog slow and _way_ overused IMO.)

Note that I'm all for supporting good RC, I'm just against adding 
special support for it _in the language_. Instead, the remaining 
obstacles for efficient and safe library-based RC should be 
solved, which from my POV mostly means implementing some version 
of the `scope` feature.

>> In any case, there has been talk about introducing finalizers 
>> instead of destructors for GC managed objects. 
>> rt_attachDisposeEvent() already exists and is used by 
>> std.signal for weak references, but it's a hack, it needs to 
>> be formalized.
>>
>> These finalizers can then have much more restricted semantics 
>> than destructors, e.g. they must be callable on any thread, 
>> are generally un- at safe if they access members with 
>> indirections, and so on.
>
> I'm honestly curious of examples where finalizers are needed.

Well, as I already mentioned, weak references, e.g. for a 
signal/slot mechanism, or for maintaining a cache that doesn't 
keep its contents alive. Apart from that, I don't see much use in 
them either. OTOH, weak references _are_ important, so there 
needs to be some mechanisms for implementing them. I guess 
finalizers are the easiest way to do it.

> The one exception I can think of is managing non-GC objects, as 
> in C#. But that *still* seems like a bad idea because there's 
> zero guarantee the destructor will ever run - i.e, a GC 
> implementation that decides to just never call destructors is a 
> valid implementation.

Agreed.

>
> http://dlang.org/class.html#destructors
> "The garbage collector is not guaranteed to run the destructor 
> for all unreferenced objects. "
>
> D has more than one issue here, from combining "finalizer" and 
> "destructor" into the same term to destructors being incredibly 
> bug-prone and almost useless as defined by the standard.
>
> I hope this gets looked at.

Agreed, too.