Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Excessively strict borrowing rules. #15001

Closed
smosher opened this issue Jun 18, 2014 · 3 comments
Closed

Excessively strict borrowing rules. #15001

smosher opened this issue Jun 18, 2014 · 3 comments

Comments

@smosher
Copy link

smosher commented Jun 18, 2014

rustc 0.11.0-pre-nightly (7ec7805 2014-06-16 08:16:49 +0000)
host: x86_64-unknown-linux-gnu

I'm not sure if this is intentional with the new borrowing rules, but I don't think it should be. When calling a &mut self method on a struct, you can't pass in a field of the struct by value, nor can you express a computed value in the arguments.

Test case:

struct Foo { x: int }
impl Foo {
    fn set_x(&mut self, new: int) { self.x = new }
}

fn main() { 
    let t = &mut Foo { x: 0 };
    // compiles:
    let tmpx = t.x;
    t.set_x(tmpx + 1);
    // borrow fails:
    t.set_x(t.x + 1)
}

The borrow of t.x fails, claiming that t is already borrowed by t.setx, but I would expect t.x + 1 to be evaluated prior to the mutable borrow (at least conceptually), and to behave essentially like the pair of lines above which compile successfully.

t2.rs:13:11: 13:14 error: cannot use `t.x` because it was mutably borrowed
t2.rs:13                t.set_x(t.x + 1);
                                ^~~
t2.rs:13:3: 13:4 note: borrow of `*t` occurs here
t2.rs:13                t.set_x(t.x + 1);
                        ^
error: aborting due to previous error
@pnkfelix
Copy link
Member

This was listed as a known drawback to the stricter rules on the commit message for commit d7de4e9

That message also describes the standard workaround (bind the field as a temporary first) and says that hopefully the problem will go away if #6268 is fixed.

@smosher
Copy link
Author

smosher commented Jun 18, 2014

Wow, I am sure I must have read that commit at some point. Thanks.

Do I close this or leave it open?

@alexcrichton
Copy link
Member

Closing as a dupe of #6268 due to @pnkfelix's comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants