> The trick seems to be universally applicable. By the way, you can exploit the trick further if you even rewrite append(list,element) as a template. But these things come to an end if the template itself calls a proc. Then, you either have to update the refcount(s) on the heap (costly,costly....) , eventually including some dynamic checks later, or the callee tells the compiler what to do instead (statically) via some fancy [adapt:] passing mode. In this sense, Nim could surpass Rust. Sounds good, isn't it?
Bacon/Dingle tell us that a correct Gel-program doesn't need a refcounted GC at all. To check this, they still have the refcount and offer us a runtime error (?!). That's odd. No, the costs of a refcount are only justified if one gets an _advantage at runtime_ of it. If the refcount doesn't fit, the deallocator could bind the data structure to a list of unresolved (postponed) data to deallocate later. Then the programmer gets informed that some postponed deallocation occured (this can even be done at runtime), and the programmer either will fix it with a minor change of the code, or he decides to continue with the current program e.g. for speed reasons (might rework it later, typically with a major overhaul). And in some cases, a dynamic solution can be faster and/or lead to shorter code than a perfect statical rework. Bacon/Dingle have an interesting detail in their paper though: _pooled allocation_ , where they place the `owned ptr` into a privileged piece of memory. I would go a step further and even place the refcount into such a privileged memory region, because the refcounts get frequent writes. Now, the refcount ptr on the heap would change to a ptr that points to the refcount. Modern CPUs have huge caches, the refcount area would remain permanently cached and I expect a (drastic) reduction of cachemisses in that case. But this needs to be explored further. With multithreading, common regions for refcounting might even seem appropriate.
