More radical ideas about gc and reference counting

[via Digitalmars-d]

On Saturday, 3 May 2014 at 11:12:56 UTC, Michel Fortin wrote:
> On 2014-05-01 17:35:36 +0000, "Marc Schütz" <schuetzm at gmx.net> 
> said:
>
>> Maybe the language should have some way to distinguish between 
>> GC-managed and manually-managed objects, preferably in the 
>> type system. Then it could be statically checked whether an 
>> object is supposed to be GC-managed, and consequentially 
>> shouldn't have a destructor.
>
> Or turn the rule on its head: make it so having a destructor 
> makes the heap memory block reference counted. With this adding 
> a destructor always cause deterministic destruction.
>
> The compiler knows statically whether a struct has a 
> destructor. For a class you need a runtime trick because the 
> root object which can be either. Use a virtual call or a magic 
> value in the reference count field to handle the reference 
> count management. You also need a way to tag a class to be 
> guarantied it has no derived class with a destructor (to 
> provide a static proof for the compiler it can omit ARC code), 
> perhaps @disable ~this().
>
> Then remains the problem of cycles. It could be a hard error if 
> the destructor is @safe (error thrown when the GC collects it). 
> The destructor could be allowed to run (in any thread) if the 
> destructor is @system or @trusted.
>
> The interesting thing with this is that the current D semantics 
> are preserved, destructors become deterministic (except in the 
> presence of cycles, which the GC will detect for you), and if 
> you're manipulating pointers to pure memory (memory blocks 
> having no destructor) there's no ARC overhead. And finally, no 
> new pointer attributes; Walter will like this last one.

This is certainly also an interesting idea, but I suspect it is 
bound to fail, simply because it involves ARC. Reference counting 
always makes things so much more complicated... See for example 
the cycles problem you mentioned: If you need a GC for that, you 
cannot guarantee that the objects will be collected, which was 
the reason to introduce ARC in the first place. Then there are 
the problems with shared vs. thread-local RC (including casting 
between the two), and arrays/slices of RC objects. And, of 
course, Walter doesn't like it ;-)