> I thought everything was handed out as copies in go by default unless a pointer was being passed. So this would make it “easy” to tell whether you are mutating a object or not.
The first bit is correct.
The point the article makes is that, to know whether a variable is potentially mutated, you have to go look at the signature of any function called on it. E.G. you can't just look at main and "know" whether a will get mutated or not, you have to also look at the signature of `Changed`. In C, with the following code
#include
struct test {
int value;
}
int main() {
struct test a = test { value: 1 };
Change(a);
printf("a.Value = %d\n", a.Value);
}
I can be 100% sure that a is never mutated, because it is passed to change value, and won't get automatically turned into a reference. Had Change be called with `&a`, then I'd know that a potentially gets mutated.
In Rust, `a` would have to be declared mutable to start with, e.g.
fn main() {
let mut a = A { value: 1 };
a.Change();
println!("{:?}", a);
}
The above, I know that Change can potentially mutate a. And if a had been declared `let a`, I can be 100% sure that change cannot mutate it.
The direction go took is in line with many other languages (I think C++ behaves this way, it automatically turns values into references based on function signature).