Earlier quoted context omitted.
> For the disjoint field issues raised, it’s not that the borrow checker can’t “reason across functions,” it’s that the field borrows are done through getter functions which themselves borrow the whole struct mutably Right, and even more to the point, there's another important property of Rust at play here: a function's signature should be the only thing necessary to typecheck the program; changes in the body of a fu…
Exactly. We've talked about fixing this, but doing so without breaking this encapsulation would require being able to declare something like (syntax is illustrative only) `&mut [set1] self` and `&mut [set2] self`, where `set1` and `set2` are defined as non-overlapping sets of fields in the definition of the type. (A type with private fields could declare semantic non-overlapping subsets without actually exposing whic…
For example, this won't compile:
struct Something { z: usize }
struct Foo { x: usize, y: &'a Something }
impl Foo {
fn bar(&mut self) -> &Something
{ let something = self.bar(); self.x += something.z; something }
}
But if you could tell the borrow checker the mutable borrow of self can never modify z, then it would be safe. This would achieve that: struct Something { z: usize }
struct Foo { x: usize, y: &'a const Something }
impl Foo {
fn bar(&mut self) -> &const Something
{ let something = self.bar(); self.x += something.z; something }
}
I've now had several instances where they would have let me win a battle with the borrow checker succinctly rather than the long work around I was forced to adopt. Const struct members allow you implement read only fields with having to hide them, and provide getters is icing on the cake.