One question that's been on my mind regarding multithreading with ARC/ORC 
(without atomic refcount) is the relation with `lent T` return type.

What I mean is that with [strict 
funcs](https://nim-lang.org/docs/manual_experimental.html#strict-funcs) we 
already have a nice way to prevent mutation of parameters (and their transitive 
closure) which helps prevent undesirable data races under multithreading.

Combine this with a way to return borrowed values, I'm wondering if this can 
completely eliminate all refcount operation inside functions.

A simple hypothetical example to illustrate:
    
    
    {.experimental: "strictFuncs".}
    {.experimental: "views".}
    
    type
      Node = ref object
        left, right: Node
        # assume other fields
    
    func query(n: Node): lent seq[Node] =
      if someCondition(n):
        result.add n
      # recurse, etc.
      result.add query(n.left)
      result.add query(n.right)
    
    
    Run

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?
    Or is this something that's planned?

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.

Last, I'm wondering if we could have `lent T from X` syntax similar to what's 
planned for [var T from 
container](https://nim-lang.org/docs/manual.html#var-return-type-future-directions)
 syntax? It would allow for more flexibility on parameter position and also 
potentially borrowing from multiple parameters.

thanks 

Reply via email to