[HN Gopher] Rust Contagious Borrow Issue
       ___________________________________________________________________
        
       Rust Contagious Borrow Issue
        
       Author : qouteall
       Score  : 32 points
       Date   : 2025-10-24 12:10 UTC (10 hours ago)
        
 (HTM) web link (qouteall.fun)
 (TXT) w3m dump (qouteall.fun)
        
       | jasonthorsness wrote:
       | I've been learning Rust via the book and a great article I found
       | on linked lists [1]. Coming from C++ the lifetimes/borrows
       | concepts make sense at a high level but the practical details
       | seem to get pretty crazy. If anyone here knows Rust well does the
       | OP article have a good take or is it missing something?
       | 
       | [1] https://rust-unofficial.github.io/too-many-lists/
        
         | scottlamb wrote:
         | I think if you've hit this problem and are looking for
         | solutions, this article looks like a helpful read. There are
         | lots of ideas there.
         | 
         | I wouldn't say this is a super common problem (though I have
         | hit it). The opening example here is that logic outside
         | `Parent` is maintaining its summary state based on its
         | children. That's unusual; typically `Parent` itself would be
         | responsible for that, and so you can inline the logic without
         | having to expose the fields.
         | 
         | Sometimes inlining the logic gets impractical though if the
         | logic is super long. In that case it can be helpful to split it
         | into sub-structs so that you can easily call a method on a
         | group of fields. I did that here, for example:
         | <https://github.com/scottlamb/moonfire-
         | nvr/blob/ff383147e4ff7...>
         | 
         | There have been language proposals to define "view types" which
         | are basically groups of fields that are borrowed. <https://smal
         | lcultfollowing.com/babysteps/blog/2021/11/05/vie...> IMHO,
         | they're not worth the extra language complexity.
        
         | recursivecaveat wrote:
         | This actually seems like a very good collection of strategies.
         | The only one I use that I see missing is converting a closure
         | capture into an argument. If you design something like:
         | zebra.onmove(|| log(barn.contains(zebra))), then you will find
         | everything locks up due to the references of the closure.
         | Instead you convert the data to args: zebra.onmove(|world,
         | zebra| log(world.barn.contains(zebra))). Obviously with cheap
         | data which you can freeze and copy like a BarnId it's fine to
         | do that.
         | 
         | In general, "stop, drop, reacquire" is a good motto. ie finish
         | figuring out what you want to happen, release the resources
         | that you needed to figure that out, reacquire exactly the
         | resources you need to make the thing happen, do it. That's
         | basically the premise of 'mutation-as-data'.
        
       | phibz wrote:
       | For this example id probably accumulate the score total in a
       | local variable. Then once iterating over all the children i would
       | call parent.add_score() with the accumulated total
        
       ___________________________________________________________________
       (page generated 2025-10-24 23:01 UTC)