3 ms·
My best interpretation of his question was more along the lines of: why do you have to mark it as `mut` if you aren't going to change it in the function? Sudden
by skywhopper 9y ago
My best interpretation of his question was more along the lines of: why do you have to mark it as `mut` if you aren't going to change it in the function? Suddenly your function only accepts mutable pointers, not just any pointer.
- eridius 9y agoWell, you wouldn't. The example function in the blog post isn't mutating the argument, but that's why the comment says // This uses mut for no reason other than to prove a point. You wouldn't normally have a function accept a mutable reference if it's not mutating it.
- jackmott 9y agoit would be a compiler warning if you did, too.
- kibwen 9y agoRust deliberately doesn't do interprocedural analysis, so function signatures are the ultimate source of truth. If you want to call a function that takes a `&mut` then all the rules for taking a `&mut` apply. If the function that takes a `&mut` doesn't need a `&mut`, however, then that's probably just bad API design, and is something to be avoided (I've never seen any such thing in the wild; the guideline in API design is to make your function signatures as unrestrictive as you can, and `&mut` is as restrictive as it gets).
- kevincox 9y agoTo me it lets me know if an object will be changed by the function or not. If it's just & I know that my object is just how I left it. If it is &mut I need to think about how it was changed.
- scottlamb 9y agoTo the compiler, too. if it's just &, the compiler knows the pointee is just how it left it[1], and it can optimize on this assumption. For example, if it had the contents in a register before the call, it knows they're still valid after the call. This is the same sort of thing "restrict" gives you in C, but unlike "restrict", using & is idiomatic and the compiler will spot mistakes. If it's &mut, those assumptions aren't valid. [1] except, iiuc, the contents of UnsafeCells (and things built on top of them, such as RefCell).
- kevincox 9y agoWell the compiler knows the signature of the function you pass it to so it should be able to optimize it anyways. I think in most if not all cases the compiler can figure out if &thing needs a mutable or immutable reference. I think the only difference is the readability to the programmer and I agree with the decision made requiring &mut for a mutable reference.
- steveklabnik 9y ago> so it should be able to compile it anyways. &T vs &mut T is very significant in Rust; not only the stuff that the parent brought up, but also variance. It's not a simple lint.
- kevincox 9y agoSorry, I typed the wrong word. I've updated the parent to be less confusing. s/compile/optimize/ For reference the first line used to be: "Well the compiler knows the signature of the function you pass it to so it should be able to compile it anyways." > &T vs &mut T is very significant in Rust Yes, especially for function signatures it is critical, however the ancestor was talking about using & to take a reference. When using & to take a reference I don't think &mut needs to be required. The compiler could probably figure it out.
- scottlamb 9y agoOh, I'm talking about having the type of reference declared in the function signature. Yes, I agree repeating it in the invocation is for the programmer's benefit. Rust doesn't have overloading, so there's no ambiguity.