On Saturday, 3 May 2014 at 11:12:56 UTC, Michel Fortin wrote:
On 2014-05-01 17:35:36 +0000, "Marc Schütz" <schue...@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 ;-)
