This article says that the borrow checker doesn't look past functions signatures because of compiler performance. I strongly disagree. The reason is to avoid coupling. If it did, you couldn't swap 2 functions with the same signature because their implementation would have a different borrowing pattern. Very bad.
(Although we're a bit there with functions returning an impl)
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?
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...>
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'.
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
(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`.)
This article says that the borrow checker doesn't look past functions signatures because of compiler performance. I strongly disagree. The reason is to avoid coupling. If it did, you couldn't swap 2 functions with the same signature because their implementation would have a different borrowing pattern. Very bad.
(Although we're a bit there with functions returning an impl)
I added that into article
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/
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'.
Thanks for suggestion.
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
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`.)