> I think there is too much arbitrary rejecting of RC because of the way C++ > uses it (and Swift's not-so-good automatic RC) without fully exploring > whether we can use it. Since we don't really want to have to expand GC to > multi-threading use, and B/D techniques don't work for such things as lists > with multi owners, I don't see that we have another choice, unless someone > brilliant comes up with something that's not on the table now.
Completely disagree, the "lists with multi owners" is a very theoretical use-case that I don't care about, lists usually have a terrible performance profile anyway. But again, if you want RC, atomic or not, Nim is giving you the building blocks to do exactly that. There is no "arbitrary rejecting of RC" going on here, the reasoning behind it is very clear: GC is a form of RC, just more incomplete than a tracing GC. B/D however, is different: It turns the imperative manual memory management with its `dealloc` calls into a declarative style. The hope is that it encourages a design that prevents _logical_ memory leaks (leaks that full tracing GCs don't prevent either!) by construction.
