As the other comment points out, whether there exists a gotcha depends on the sizes, byte -> float32, int32 -> float64, etc are fine, int64 -> float64 is not. There is no reason for the compiler to be ignorant of this.
Moreover, if float means float64 (as I'd suggest be the case) and int continues to mean int32 (which it won't forever), then a lot of common cases would not require explicit casting and be safe.
As the other comment points out, whether there exists a gotcha depends on the sizes, byte -> float32, int32 -> float64, etc are fine, int64 -> float64 is not. There is no reason for the compiler to be ignorant of this.
Yes, but too much variance in how the compiler reacts depending on local implementation details can be quite messy. The principle of least surprise would recommend leaving the feature out, especially since Go dispenses with compiler warnings. Otherwise. we could have the situation where something compiles just fine on your desktop, then breaks when compiled for a different platform like NaCL. How would the developer know this on the desktop, ahead of time? By leaving the feature out, you get a more informant and reliable tool.
If int means int64 on one platform and int32 on another platform, one should expect that some things might require care to port correctly.
A compile-time error because an automatic cast can't be performed on the new platform is infinitely better than a forced cast that silently introduces run-time errors.
If int means int64 on one platform and int32 on another platform, one should expect that some things might require care to port correctly.
That's just the way things have been. It's not a particularly good or pleasant situation. If the Go team wants to make this better, all the power to them. (And I know for a fact that it doesn't have to be this way. It's just the expectation we've come to accept as normal. Squeak runs bit-identically on over 50 combinations of OS and processor.)
A compile-time error because an automatic cast can't be performed on the new platform is infinitely better than a forced cast that silently introduces run-time errors
"Silently" here being that the programmer mindlessly puts in the cast because the compiler "forces" her to? I don't think the compiler is at fault here.
Moreover, if float means float64 (as I'd suggest be the case) and int continues to mean int32 (which it won't forever), then a lot of common cases would not require explicit casting and be safe.