More radical ideas about gc and reference counting

[Marco Leise via Digitalmars-d]

Am Sun, 11 May 2014 22:11:28 -0700
schrieb Walter Bright <newshound2 at digitalmars.com>:

> > But I thought ARC cannot be designed without GC to resolve
> > cycles.
> 
> It can be, there are various schemes to deal with that, including "don't create 
> cycles". GC is just one of them.
> 
> http://en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles

Yes that article mentions:
a) "avoid creating them"
b) "explicitly forbid reference cycles"
c) "Judicious use of weak references"
d) "manually track that data structure's lifetime"
e) "tracing garbage collector"
f) adding to a root list all objects whose reference
   count is decremented to a non-zero value and periodically
   searching all objects reachable from those roots.

To pick up your statement again: »Your proposal still relies
on a GC to provide the memory safety, […] it is a hybrid
ARC/GC system.«

a) and b) let's assume never creating cycles is not a feasible
          option in a systems programming language
c) and d) don't provide said memory safety
e) and f) ARE tracing garbage collectors

ergo: »But I thought ARC cannot be designed without GC to
resolve cycles.«

Your were arguing against Michel Fortin's proposal on the
surface, when your requirement cannot even be fulfilled
theoretically it seems. Which could mean that you don't like
the idea of replacing D's GC with an ARC solution.

»This is the best horse I could find for the price. It is
 pretty fast and ...«
»No, it still has four legs.«

-- 
Marco