[go-nuts] How does the compiler treat static type conversions?

You can find out a and b's type by "%T".

http://play.golang.org/p/zv0xvL6zri

--

In the assignment to a, 123 is an untyped constant given the type int64. I
don't think that it is ever an int with value 123. So, for example, the
following two lines are different:

var a = int64(int(123))
var a = int64(123)

Is this what you are asking?

Best,
Ethan

--

Yes, that's my question, thank you.

Am Donnerstag, 1. November 2012 13:42:40 UTC+1 schrieb Ethan Burns:

Why are they different? int64(123) and int64(int(123)) are both typed
constants with value 123 and type int64.

Rémy.

--

I think he'd better use a constant like 1<<33 to demonstrate that there
isn't a conversion
to int involved in int64(1<<33) (assuming this is what OP asks)

--

These two lines result in the same thing. The question was if the 123
would be converted to an int before an int64, the answer was no. It would
only matter if the value 123 was instead something that was too large to
represent as type int, in which case there would be a compiler error about
overflow.

Best,
Ethan

--

All numeric constants, unless explicitly given a type, as in:

const x int = 5

are untyped.

const y = 5 // this is untyped

untyped constants do not exist at runtime -- they are a compile-time
phenomenon who's value can't be used until it is coalesced into a type.

const (
y = 5
z = 7.4
)
var (
a int = y
b byte = y
c uint64 = y
d float32 = z
e = y
f = z
)

No conversions occur anywhere in the above. Since y is untyped, a, b, and c
will have that value coalesced (at _compile_ time) into their respective
types. The same applies for d. When an untyped integer constant is used for
type inference (in the case of e), the inference will always be 'int'. For
floating-point untyped constants inference will always be float64 (so f is
a float64). It's like some interpretations of quantum physics: the particle
may have undefined properties until you force it to assume a given form
through observation. In this case, the property is its type, the particle
is an untyped constant (y or z), and the observational act is type
inference.

Also note that if you did something like:

g := int(int64(int(5)))

There will probably be no actual conversion going on, since 5 is a constant
within both the range of int64 and int, and so it's trivially resolvable at
compile time (it's a constant expression).

--

There are no untyped Go constants in the above examples.

-j

--

Not so: y and z are untyped in the last example.

-rob

--

You're right, I'm wrong: http://golang.org/ref/spec#Constants

"Constants may be typed or untyped. Literal constants, true, false,
iota, and certain constant expressions containing only untyped
constant operands are untyped."

I missed the (tiny) comma between `Literal constants` and `true,
false, ...` and inferred that numeric constants are _typed_ but as an
ideal type, compatible with all predefined run time numeric types.

-j

--