> The result of the query borrows from the n parameter, and in theory the > lifetime dependency can avoid refcounting activity since it's assumed that > the lending parameter is reachable in the first place and the lent value > lifetime won't extend its lender's. Does this already prevent refcount > updates?
You misuse `lent` in your example which makes it harder to understand. > Or is this something that's planned? You seem to describe an optimization that is "well known": "There is an important special case in which it is possible to avoid incrementing and decrementing reference counts. Suppose that the program has a declaration type C = counted collection of ... We say that a scope S is C-conservative if it contains no assignments to variables of type ^C that are not local to S, it contains no uses of v.refCount for variables in C, and all procedures that it calls are also C-conservative. Within S it is not necessary to update reference counts for variables in C, since no variable in C can be freed in S and every such variable will have the same reference count on exit from S that it had on entry to S." Nim doesn't do this optimization, instead Nim does "cursor" inference. Given cursor inference, it is not clear if the optimization is worth it. But it is interesting and reasonably easy to understand and implement. > Assuming no concurrent mutation (as for persistent data structures), or a > coarse-grained read/write lock over the root Node, the query function above > would be race-free, refcount-update-free, and thus thread-safe. It would be a > big enabler for multithreaded ARC/ORC. Maybe, maybe not. How can you assume a lock on the "root" Node? The compiler has no idea about a "root" node, the nodes are all of the same type and the hard part of analysing multi-threaded programs is that you don't know what the other threads may do, it's fundamentally a nonlocal analysis. > Last, I'm wondering if we could have lent T from X syntax similar to what's > planned for var T from container syntax? It would allow for more flexibility > on parameter position and also potentially borrowing from multiple parameters. More syntax doesn't help when we still try to figure out the important idioms we need to support.
