4 ms·
This is either wrong or incomplete. When you call a function `f()` with some `&mut`, the callee gets a `&mut`, not a borrowed `&mut &mut`. The callee doesn't bo
by legerdemain 4y ago
This is either wrong or incomplete. When you call a function `f()` with some `&mut`, the callee gets a `&mut`, not a borrowed `&mut &mut`. The callee doesn't borrow the ref mut, it gets the actual ref mut, and for some time you have multiple mutable references in the same scope. How?
- Filligree 4y agoBecause the calling function isn't using it at the time. Rust isn't proving something about the number of references in memory; it's proving something about the dynamic behaviour of the program, i.e. that there can be at most one reference actively being used to mutate it, at a time. Hence there's no problem cloning a mutable reference implicitly, when calling a function. Notice that you can't for instance send it to another thread, however.
- zaphar 4y agoThere are not multiple mutable references in the same scope. The mutable reference is only valid for the scope of the function `f()`. This doesn't sound like a problem understanding mutable references but a problem understanding scope.
- nicoburns 4y agoThe function isn’t borrowing the reference. It’s using the reference to borrow the value thats being pointed to by the reference.
- legerdemain 4y agoI was looking for the word "reborrowing," which I think is crucial for beginners trying to form an effective mental model of Rust semantics.
- scotty79 4y agoIt gets `&mut *&mut` (where * doesn't mean a pointer, just deref) Not sure if that's good that this feature is automatic. Maybe it wouldn't be too bad to call functions like that for consistency: go_break_stuff(&mut *my_stuff_ref); if you want to keep using the reference after the call.