GC-proof resource classes

[Timon Gehr via Digitalmars-d]

On 08/30/2015 12:10 PM, rsw0x wrote:
> On Saturday, 29 August 2015 at 23:08:45 UTC, Timon Gehr wrote:
>> On 08/29/2015 04:45 PM, rsw0x wrote:
>>> On Saturday, 29 August 2015 at 14:32:27 UTC, Timon Gehr wrote:
>>>> On 08/29/2015 04:20 PM, cym13 wrote:
>>>>> On Saturday, 29 August 2015 at 14:17:10 UTC, rsw0x wrote:
>>>>>> [...]
>>>>>
>>>>> After reading all that, I too am convinced that the GC shouldn't call
>>>>> the destructor.
>>>>
>>>> But then classes with destructors shouldn't be allowed to be allocated
>>>> on the GC heap in the first place, which is a PITA as well. (Note that
>>>> classes/arrays can have destructors because some component structs
>>>> have them; structs generally assume that their destructors will be
>>>> called.)
>>>
>>> make classes with destructors(and structs allocated via new) have RC
>>> semantics.
>>
>> RC is an especially eager form of GC, that does not deal with cycles
>> by default. Why does it help?
>
> The problem is that there's no guarantee the destructor will run with
> the GC,

This is something the GC can in principle guarantee though, and it might 
be good enough to deallocate memory.

> no guarantee what thread it will run on, and no guarantee on
> when it will run. RC guarantees all three of these

Those are good points, but why do this implicitly with the same 
allocation syntax?

> outside of cycles.

One might not have no cycles. Each reference counted reference has a 
destructor. I.e. as soon as some class in an object graph has a 
destructor, a lot of them do. I think it wouldn't necessarily be great 
language design to have memory leaks caused by e.g. adding 
std.container.Array to some class.