We have to say `&mut i` in main() because `&i` is non-mutable. We’re explicitly taking a mutable borrow.
But once it’s in foo(), it’s already mutable. The type `&mut int` carries its mutability with it. Having to say `mut` again makes no sense and is nothing but pure noise. -Kevin On Dec 27, 2013, at 4:59 PM, Vadim <[email protected]> wrote: > For the same reason we currently have to say `&mut i` in main() - to > explicitly acknowledge that the callee may mutate i. By the same logic, this > should be done everywhere. > > > On Wed, Dec 25, 2013 at 3:11 PM, Kevin Ballard <[email protected]> wrote: > On Dec 25, 2013, at 5:17 PM, Vadim <[email protected]> wrote: > >> I agree that unexpected mutation is undesirable, but: >> - requiring 'mut' is orthogonal to requiring '&' sigil, IMHO, >> - as currently implemented, Rust does not always require mut when callee >> mutates the argument, for example: >> >> fn main() { >> let mut i: int = 0; >> foo(&mut i); >> println!("{}", i); >> } >> fn foo(i: &mut int) { >> bar(i); // no mut! >> } >> fn bar(i: &mut int) { >> *i = *i + 1; >> } >> >> Note that invocation of bar() inside foo() does not forewarn reader by >> requiring 'mut'. Wouldn't you rather see this?: >> >> fn main() { >> let mut i: int = 0; >> foo(mut i); >> println!("{}", i); >> } >> fn foo(i: &mut int) { >> bar(mut i); >> } >> fn bar(i: &mut int) { >> i = i + 1; >> } > > What is the point of adding `mut` here? bar() does not need `mut` because > calling bar(i) does not auto-borrow i. It’s already a `&mut int`. > > -Kevin >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
