4 ms·
> 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 mutatin
by roblabla 4y ago
> 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 <stdio.h>
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).
- wara23arish 4y agoi feel like that C example isnt fair cause you cant have functions bound to types right?? youre not calling change(a) but instead calling a.change(). i havent learned any rust yet, im waiting till im a little better at go so i can be comfortable at work before doing so:) whats the advantage of creating a function of type struct a rather than creating the C equivalent of change(obj structAtype) ? to me now, it seems that it should be expected that an a.Change func will mutate A i see what you’re saying that with Go it cant always be easy to check if its mutating what you’re calling or not. its giving the developer more options to use stuff by ref/val which gives more power but more room for mistakes.
- kevinmgranger 4y ago> it seems that it should be expected that an a.Change func will mutate A But you can make functions that have copied receivers: type Foo struct { bar int } func (f Foo) mutate() { f.bar = 2 } func main() { f := Foo{bar: 1} f.mutate() fmt.Println(f.bar) // 1 } > whats the advantage of creating a function of type struct a rather than creating the C equivalent of change(obj structAtype) types need to have methods in order to fulfill interfaces, that's all. (Well, and all the downstream benefits of using interfaces, such a polymorphism).
- wara23arish 4y agoOkay, I haven’t worked with Go enough yet to need inheritance so I stupidly overlooked that :) even though ive used it extensively in java. i can definitely see how that is wacky. i wonder what the upsides of being able to do that is. really appreciate the explanation! thank you