@Arag:
> But again, if you want RC, atomic or not, Nim is giving you the building
> blocks to do exactly that.
I'm grateful for that capability and have used it witha destructor
implementation when I wanted to try an algorithm that depended on list-like
structures without using GC.
> The real issue is that RC cannot even detect cycles so you're left with
> having to run a separate leak detector.
Would it help to reject cyclic data completely (except at the global level) as
per what Elm does currently? Or do you see use cases where we can't live
without cyclic data? According to the Elm people, cyclic data isn't a problem
if you can't create it in the first place and they apparently think that they
can live without it.
I see that "introducing a cycle (leak) detector" could cost a lot in cycles and
is greatly to be avoided.
> Introducing cycles with B/D is much harder to accomplish.
I don't see it being hard to introduce cycles with B/D at all if we want B/D to
be able to handle everything that GC currently can. The following trivial
example works fine with current GC, but would be a cycle that would require
cycle detection or that the special destruction extensions be used if the ref
were a B/D owned ref or a combination of owned ref and dangling ref:
type
List[T] = ref object
head: T
tail: List[T]
proc makeCycle[T](x: T): List[T] =
result = List[T](head: x); result.tail = result
var ones = makeCycle(1)
for _ in 1 .. 20: stdout.write ones.head, " "; ones = ones.tail
Run
Yes, this is a list which isn't really very useful, but the same principles
apply if it were a more useful structure such as a binary tree (with cycles).
It's possible to fix for B/D by using the extension(s) proposed by B/D for
destruction, but those, in turn, cost cycles and don't seem to cover deepCopy
if one truly needs it. Again, deepCopy extensions can be implemented in a
similar way, but they also cost cycles, although I suppose that would be
acceptable given that deepCopy would be needed so rarely.
As well, B/D doesn't seem to apply in all cases where one must have multiple
owners such as for the sub-nodes in a binary tree, as the only alternates would
seem to be deepCopy ("Clone" for Rust) which are extremely wasteful for a large
tree structure, having GC as an alternate (I've come to see your objections to
it so don't really want to have to revert to using that), and RC (which is
Rust's solution in spite of being "incomplete").
