3 ms·
> If there are no implicit conversions, users complain about having to write "1.0" instead of "1", or worse, having to write "1.0L". If there are too many impli
by majewsky 8y ago
> If there are no implicit conversions, users complain about having to write "1.0" instead of "1", or worse, having to write "1.0L". If there are too many implicit conversions, you get unexpected semantics. Basically, conversions are there for numbers. Then somebody decides to generalize them. That sometimes ends badly.
In Go, there are special types for integer and float literals. Literals can be implicitly casted into any numeric type large enough to store them, but casts from numeric types into other numeric types must be explicit. So for example:
funcThatTakesInt32(1) // works
funcThatTakesUint64(1) // works too
var x int32 = 1
funcThatTakesUint64(x) // error: type mismatch
funcThatTakesUint64(uint64(x)) // works: explicit cast
The only thing I'm not sure about is which numeric type gets chosen when a literal is stored in a fresh variable without declaring its type, i.e.
x := 42
y := 23.0
I think `x` would be `int` since the following works:
for x := 0; x < 10; x++ {
fmt.Println(someArray[x]) //subscript requires `int` index
}
But then what happens when the literal in `x := <literal>` is too large to fit in `int`? And since the size of `int` (AFAIK) is machine-dependent, does that mean that some programs will compile for some target platforms, but fail for other target platforms? Argh. I see what you're getting at.