2 ms·
(See also my response to jerf, above.) In Go (as in most programming languages) it's not true that the assignment "a = b" implies that "b == foo => a == foo",
by dilap 10y ago
(See also my response to jerf, above.)
In Go (as in most programming languages) it's not true that the assignment "a = b" implies that "b == foo => a == foo", if a and b are different types.
For example, this C code will print "nope":
float b = 3.5;
int a = b;
printf(a==3.5 ? "yup" : "nope\n");
So back to Go, sure, this is initially surprising, and most people get bit by it at first. Once you know about it, it's fine.
In practice I haven't encountered any refactoring bugs as you describe, though it is theoretically possible.
I personally don't see it as a big issue.
(In retrospect, Go could've help guide intuition better by using a new keyword like "unset" or something to test for the zero-value of interfaces, instead of overloading nil.)
- dragonwriter 10y ago> In Go (as in most programming languages) it's not true that the assignment "a = b" implies that "b == foo => a == foo", if a and b are different types. While I haven't counted and compared, I suspect that in most programming languages, "a=b" being a non-error implies that either a and b are the same type and value, or that a and b are values that, if they are of different and comparable types, will compare equal. There are certainly popular languages that do it the way you describe, but I don't think most languages do.
- dilap 10y agoThat's a fair point.
- stouset 10y ago> In Go (as in most programming languages) it's not true that the assignment "a = b" implies that "b == foo => a == foo", if a and b are different types. While this is true, in all of those other cases you have the benefit of compile-time type checking so cannot call a function on the wrong type. With nil, you get runtime errors.