More radical ideas about gc and reference counting

[Michel Fortin via Digitalmars-d]

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.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca