On Thursday, 15 May 2014 at 07:27:41 UTC, Kagamin wrote:
On Wednesday, 14 May 2014 at 09:39:01 UTC, Marc Schütz wrote:
RC is done by the object itself, so by definition it knows its
own type, while the GC needs to be told about the type on
allocation. AFAIK there is ongoing work to make this
information available for non-class types.
If you can unify RC on binary level for any type, GC can use
that unification too: when you allocate the object, you has its
type and can setup necessary structures needed to call the
destructor.
Exactly.
Well, it cannot be made 100% reliable by principle. That's
just an inherent property of tracing GCs. The question is, can
we define which uses of destructors are "safe" in this sense
and which ones are not, and ideally find ways to detect unsafe
uses at compile time... That's very much in the spirit of D:
Something that looks right, should be right. If it is not, it
should be rejected by the compiler.
Does this suggest that if you slip a type with destructor into
your code, it will force everything to be refcounted?
Hmm... that's probably too strict. There are often non-critical
resources that need to be released on destruction, like a
hypothetical String class which owns it's data and which is
itself allocated on the GC heap, because we don't need eager
destruction for it. We'd want the data buffer to be released as
soon the String object is destroyed. This buffer might even be
allocated on the C heap, so we cannot rely on the garbage
collector to clean it up later. Is that a job for a finalizer?
