Partial borrowing (for fun and profit)
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rfcs/issues/1215)* Consider the following struct and impl for 2D coordinates: ``` rust struct Point { x: f64, y: f64 } impl Point { pub fn x_mut(&mut self) -> &mut f64 { &mut self.x } pub fn y_mut(&mut self) -> &mut f64 { &mut self.y } } fn main() { let mut point = Point { x: 1.0, y: 2.0 }; // ... } ``` Even in this simple example, using `point.x` and `point.y` gives us more flexibility than using `point.mut_x()` and `point.mut_y()`. Compare following examples that double the components of a point: ``` rust { // Legal: point.x *= 2.0; point.y *= 2.0; } { // Legal: let x_mut = &mut point.x; let y_mut = &mut point.y; *x_mut *= 2.0; *y_mut *= 2.0; } { // Legal: let ref mut x_ref = point.x; let ref mut y_ref = point.y; *x_ref *= 2.0; *y_ref *= 2.0; } { // Legal: *point.x_mut() *= 2.0; *point.y_mut() *= 2.0; } { // Illegal: let x_mut = point.x_mut(); let y_mut = point.y_mut(); // ^~~~~ // error: cannot borrow `point` as mutable more than once at a time *x_mut *= 2.0; *y_mut *= 2.0; } ``` The lifetime elision rules make it pretty clear why this happens: `x_mut()` returns a mutable borrow that has to live _at least_ as long as the mutable borrow of `self` (written as `fn x_mut<'a>(&'a self) -> &'a f64`). In order to 'fix' the above example, there n
Posted by kylewlacy on Jul 18, 2015, 7:18 AM
Tags
Related issues
Raise real-world problems, find people facing the same issue, and discuss solutions.5,500 issues0 comments
github (E-commerce)
proposal: cmd/cgo: cgo without a C toolchain
Replace PowerToys Run with Command Palette
VPS with a vRack leg
Possibility of Portal 1 Code Inclusion
Introducing NewPlayer
Metrics for PRs are never expiring ("memory leak")
ship even more of the compiler in source form
Flatpak Application TRACKING ISSUE
Partial borrowing (for fun and profit)
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rfcs/issues/1215)* Consider the following struct and impl for 2D coordinates: ``` rust struct Point { x: f64, y: f64 } impl Point { pub fn x_mut(&mut self) -> &mut f64 { &mut self.x } pub fn y_mut(&mut self) -> &mut f64 { &mut self.y } } fn main() { let mut point = Point { x: 1.0, y: 2.0 }; // ... } ``` Even in this simple example, using `point.x` and `point.y` gives us more flexibility than using `point.mut_x()` and `point.mut_y()`. Compare following examples that double the components of a point: ``` rust { // Legal: point.x *= 2.0; point.y *= 2.0; } { // Legal: let x_mut = &mut point.x; let y_mut = &mut point.y; *x_mut *= 2.0; *y_mut *= 2.0; } { // Legal: let ref mut x_ref = point.x; let ref mut y_ref = point.y; *x_ref *= 2.0; *y_ref *= 2.0; } { // Legal: *point.x_mut() *= 2.0; *point.y_mut() *= 2.0; } { // Illegal: let x_mut = point.x_mut(); let y_mut = point.y_mut(); // ^~~~~ // error: cannot borrow `point` as mutable more than once at a time *x_mut *= 2.0; *y_mut *= 2.0; } ``` The lifetime elision rules make it pretty clear why this happens: `x_mut()` returns a mutable borrow that has to live _at least_ as long as the mutable borrow of `self` (written as `fn x_mut<'a>(&'a self) -> &'a f64`). In order to 'fix' the above example, there n
Comments (0)
No comments yet. Start the discussion.