> No, that's wrong. I'm sorry but since you keep misrepresenting B/D, I begin > to wonder if you actually really understand it.
Obviously, we read B/D differently. You see promises/advantages where I see limitations. E.g. : a static list with key-value pairs and access via a static list container. A proc requests a reference from the container. It gets the ref. The proc doesn't want an `owned ref`. It only intends to update a data field, letting the structure of the heap unchanged. Then, the proc calls another proc with subsequent calls deeper in the stack. Now, one of these procs wants a ref from the given list container. "Unfortunately", the key is the same and therefore, the selected list element is the same as in the first request mentioned above. Now, the element is "aliased". The actual proc wants to extract the element from the list and to rebind it into another list. This requires an `owned ref`. When the procs eventually return, coming back to first procedure, the element is still in place and the ref is still valid. The recent implementation of RC in Nim allows this. With B/D however, the outcome depends from the implementation. If we allow it, the program will run fine. But there is a disturbing point. Basically, one can omit RC with B/D "if anything has been thorougly tested". Then, the already referenced element is not protected from deletion. If this happens - it could be done with an `owned ref` \- we will run into crash conditions. These conditions might occur rarely , since the "unfortunate equal key" itself might be a rare event. Very bad to detect and to debug. Another question is "optimization". Bacon/Dingle write, that no updates on the heap are necessary as long as the references are maintained on the stack. But then, the ref. element remains "unprotected" and even with RC still in place, we run into very rare, but potential crash conditions. If we are lucky, we get the crash early. If not, someone will be unlucky later. It follows: RC can't be omitted with B/D and refcount updates have to be made constantly. The good news are that you get rid of the stack scan and deallocation happens more deterministic, and cycles can be detected early and if, they are easier to resolve than with the recent RC. I conclude further: If B/D had seen your implementation of RC in Nim, they had never come up with their own proposal. You can still introduce `gcref` in Nim (aka: "weak ptr"), making detection of cycles easier (or to forbid them completely). But B/D is not mature enough to replace the recent RC and definitely not appropriate for a RC removal. If you want to go along with the ideas of B/D, you need to rethink the type system (extension with capabilities). Specificly, you need the definition of an `isolate pointer` to begin with.
