@jyelon: > I'm surprised everyone is treating owned and unowned refs as if they were > something new. C++ has owned and unowned refs....
I'm afraid you are far behind the curve here, Nim's owned/dangling ref's aren't like those of C++ at all, see [@Araq's original post on the forum](https://forum.nim-lang.org/t/4743#29588) with follow-up discussion and [another follow-up thread](https://forum.nim-lang.org/t/4976#31173). In short, in his research, @Araq found a paper that describes a way of doing this that is not just pure reference counting but rather more like C++ "unique_ptr" but better as it can optionally verify the correctness with reference counting - it is more like a cross between C++ "unique_ptr" and "shared_ptr" but not the same as either. Since then, we have been working at improving on the work in the original research paper to (hopefully) get something even better than that. > But anybody considering this would have immediately understood the cost > tradeoffs: you pay the performance penalty of maintaining the reference > counts, and you pay the price of doing the extra work to clear out the > unowned refs. In Nim's implementation, reference counts are optional and something that one would turn on for debug/development so as to make sure the compiler/programmer are doing their job properly, then turned of for release in which case there is no reference counters used nor checks made if that option is selected. As to "clearing out unowned ref's", if you are referring to dangling ref's, they are actually just something like C++ "weak_pointer" and thus there is no "clearing out to be done; if checks are turned off and the compiler and programmer are mistaken, then the program may fail by trying to reference a deallocated pointer. As to "clearing out owned ref's when they go out of scope, that is just a simple automatic deallocation just as for any pointer when it is deallocated. Thus, the Nim version of owned/dangling ref's can be zero cost for release/danger mode. When the ownership model fails as when one needs to have the equivalent of multiple owners of the same data, then it is proposed that one would implement an override that would do a deep copy just as one would implement a "Clone" trait in Rust for this case. When one wants to share the same data such as across threads, then one does the overrides to implement reference counted pointers that are basically the same as C++ "shared_ptr", but the need for those should be fairly rare and when required the overhead of their use will likely be much less than other overheads, such as those related to thread context switching.
