3 ms·
Will this improve borrow checking to correctly understand member borrowing of a struct? Like: fn borrow_field1(&mut self) -> &Foo { &mut self.field1 }
by vlovich123 3y ago
Will this improve borrow checking to correctly understand member borrowing of a struct?
Like:
fn borrow_field1(&mut self) -> &Foo { &mut self.field1 }
fn borrow_field2(&mut self) -> &Bar { &mut self.field2 }
fn do_something(&mut self) {
let field1 = self.borrow_field1();
let field2 = self.borrow_field2();
}
- afdbcreid 3y agoNo, this is unrelated work. But see https://smallcultfollowing.com/babysteps/blog/2021/11/05/view-types/ https://smallcultfollowing.com/babysteps/blog/2021/11/05/vie... (only thoughts, nothing concrete or proposal).
- vacuity 3y agoI believe not. The method signature indicates that each reference claims exclusive access to the struct, so it may even be backwards incompatible to add the new behavior without a syntax addition. I believe one of the proposals to this end is "view types".
- fleventynine 3y agoThis is the biggest pain-point of the language. We need a solution.
- galangalalgol 3y agoWhy is that even safe?
- fleventynine 3y agoIt can be safe if the language provides a mechanism to tell the compiler that borrow_field1() and borrow_field2() will never mutably borrow the same fields. This would be part of the public API of those functions, and compilation would fail if the implementations were changed to borrow the same fields.
- csomar 3y agoI don’t see how that code is safe or can be considered so. Your signature suggests that you mutably borrow self. Even if you only use a member, the signature could confuse fellow developers that they can play with the whole object. I’ll use an Arc or an Rc depending on the need of thread safety. I think way too many people are over optimizing their Rust programs. Unless you are building for resource constrained devices, I think the cost of atomic primitives is negligible.