FAQ
My question is illustrated by this very small playground example:

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

Will variable 'a' be assigned a value of type int and value 123, converted
to int64? Or will it, as 'b', be assigned a value of type int64 and value
123?

Thank you

- Tom

--

## Search Discussions

•  at Nov 1, 2012 at 12:41 pm ⇧

On Thu, Nov 1, 2012 at 8:32 PM, tomwilde wrote:

My question is illustrated by this very small playground example:

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

Will variable 'a' be assigned a value of type int and value 123, converted
to int64? Or will it, as 'b', be assigned a value of type int64 and value
123?
You can find out a and b's type by "%T".

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

--
•  at Nov 1, 2012 at 12:42 pm ⇧

On Thursday, November 1, 2012 8:32:07 AM UTC-4, tomwilde wrote:

My question is illustrated by this very small playground example:

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

Will variable 'a' be assigned a value of type int and value 123, converted
to int64? Or will it, as 'b', be assigned a value of type int64 and value
123?
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

--
•  at Nov 1, 2012 at 12:45 pm ⇧
Yes, that's my question, thank you.

Am Donnerstag, 1. November 2012 13:42:40 UTC+1 schrieb Ethan Burns:
On Thursday, November 1, 2012 8:32:07 AM UTC-4, tomwilde wrote:

My question is illustrated by this very small playground example:

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

Will variable 'a' be assigned a value of type int and value 123,
converted to int64? Or will it, as 'b', be assigned a value of type int64
and value 123?
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
--
•  at Nov 1, 2012 at 1:03 pm ⇧

On 2012/11/1 Ethan Burns wrote:
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)
Why are they different? int64(123) and int64(int(123)) are both typed
constants with value 123 and type int64.

Rémy.

--
•  at Nov 1, 2012 at 1:07 pm ⇧

On Thu, Nov 1, 2012 at 9:03 PM, Rémy Oudompheng wrote:
On 2012/11/1 Ethan Burns wrote:
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)
Why are they different? int64(123) and int64(int(123)) are both typed
constants with value 123 and type int64.
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)

--
•  at Nov 1, 2012 at 1:08 pm ⇧

On Thursday, November 1, 2012 9:03:19 AM UTC-4, Rémy Oudompheng wrote:
On 2012/11/1 Ethan Burns <burns...@gmail.com <javascript:>> wrote:
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)
Why are they different? int64(123) and int64(int(123)) are both typed
constants with value 123 and type int64.
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

--
•  at Nov 5, 2012 at 7:35 pm ⇧
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).

--
•  at Nov 5, 2012 at 8:38 pm ⇧

On Mon, Nov 5, 2012 at 8:35 PM, Kevin Gillette wrote:
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
)
There are no untyped Go constants in the above examples.

-j

--
•  at Nov 5, 2012 at 8:45 pm ⇧
Not so: y and z are untyped in the last example.

-rob

--
•  at Nov 5, 2012 at 8:53 pm ⇧

On Mon, Nov 5, 2012 at 9:45 PM, Rob Pike wrote:
Not so: y and z are untyped in the last example.
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

--

## Related Discussions

Discussion Overview
 group golang-nuts categories go posted Nov 1, '12 at 12:32p active Nov 5, '12 at 8:53p posts 11 users 7 website golang.org

### 7 users in discussion

Content

People

Support

Translate

site design / logo © 2021 Grokbase