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://smallcultfollowing.com/babysteps/blog/2021/11/05/vie...> IMHO, they're not worth the extra language complexity.

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'.

I added clarification

(That simplified example is just for illustrating contagious borrow issue. The *`total_score` is analogous to a complex state that exists in real applications*. Same for subsequent examples. Just summing integer can use `.sum()` or local variable. Simple integer mutable state can be workarounded using `Cell`.)

I added that into article

It's a bit of both IIRC. You're right that limiting checks to the function signature avoids accidentally leaking implementation details, but it also means that checking functions can be done entirely locally. Not having to recursively inspect called function implementations to determine whether there is a type/borrow checking error scales much worse than only needing to look at function signatures.