Am Sun, 11 May 2014 22:11:28 -0700 schrieb Walter Bright <[email protected]>:
> > 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
