On 11 May 2014 08:40, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 5/10/2014 8:54 AM, Manu via Digitalmars-d wrote: > >> Recall too that D has significant opportunity to >> improve on ARC as implemented by other languages, > > You're essentially arguing that one is easy pickings and the other is > impractically difficult, but they're actually about the same level.
That's not actually what I was arguing at all. I was arguing that D's ARC offering would likely be superior to any that have come before, due to inherent advantages in the language, and by all reports, D is incapable of having the worlds best GC implemented successfully for various reasons. If it is possible to implement the worlds best GC in D, it's still not a done deal though. We still need to consider; does the worlds best GC remain incompatible with my workload at a fundamental level? What do we do about destructors? If ARC is within 10% of the worlds best GC, and both are equally attainable in D's context, is 10% a fair price to pay for a more inclusive technology? Who is it that will declare that 10% difference a deal-breaker? (they're obviously not here now, since D's existing GC is not in that ballpark) With them in mind, and upon an ARC platform, can we offer those users the GC as a library? Or perhaps a mechanism to disable RC code generation in their local code and falling back upon the cycle-collecting GC already in place to pick up the task?