(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`.)
(Although we're a bit there with functions returning an impl)
jasonthorsness•12h ago
[1] https://rust-unofficial.github.io/too-many-lists/
scottlamb•11h ago
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.
recursivecaveat•10h ago
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'.
qouteall•3h ago