I have faced a situation where I have some integer value in a constant and multiplying it with math.Pi constant as below:
func main() {
const a = 5
fmt.Printf("%v", a*math.Pi)
}
On execution it gives following result:
15.707963267948966
But, when I change the constant to variable (variable a) as below:
func main() {
a := 5
fmt.Printf("%v", a*math.Pi)
}
On compilation it gives the following error:
constant 3.14159 truncated to integer
As far as I understand implicit numeric type conversion is working when all operands of expression are constants, but not working when any of these a variable.
But why is this happening?
It's happening because of Go's untyped constants. In both cases, you are not explicitly specifying a type.
In the first case, you are defining an untyped constant (you could also define a typed constant by using const a float64 = 5). For an untyped constant, a type will only be inferred when it’s used in a context that requires a type – i.e. when you are multiplying it with math.Pi, the compiler will "guess" that you want to have a float there, and everything works fine.
In the second case, a variable of course has to have a type, so the type inference takes place when declaring the variable, and since you used "5", the compiler will "infer" int, and multiplying an int and a float is not possible in Go. You could use e.g. a:=5.0 or var a float64 = 5 to declare a as a float64, then this code would work as well.
See this blog post for more details.
Related
I'm just learning golang using the official tour/tutorial. In one of the examples, I see a note that says An untyped constant takes the type needed by its context.
I'm trying this:
package main
import "fmt"
const (
// Create a huge number by shifting a 1 bit left 100 places.
// In other words, the binary number that is 1 followed by 100 zeroes.
Big = 1 << 100
)
func main() {
fmt.Printf("Big is of type %T\n", Big)
}
But this fails when I run it, with:
# command-line-arguments
./compile63.go:12:13: constant 1267650600228229401496703205376 overflows int
Why am I unable to discover the type of the constant this way? (Please note I'm a total noob and quite possibly haven't yet discovered enough about the language to be able to solve this myself).
func Printf
func Printf(format string, a ...interface{}) (n int, err error)
Printf formats according to a format specifier and writes to standard
output. It returns the number of bytes written and any write error
encountered.
The Go Programming Language
Specification
Variable
declarations
A variable declaration creates one or more variables, binds
corresponding identifiers to them, and gives each a type and an
initial value.
If a list of expressions is given, the variables are initialized with
the expressions following the rules for assignments. Otherwise, each
variable is initialized to its zero value.
If a type is present, each variable is given that type. Otherwise,
each variable is given the type of the corresponding initialization
value in the assignment. If that value is an untyped constant, it is
first converted to its default type; if it is an untyped boolean
value, it is first converted to type bool. The predeclared value nil
cannot be used to initialize a variable with no explicit type.
Constants
Constants may be typed or untyped. Literal constants, true, false,
iota, and certain constant expressions containing only untyped
constant operands are untyped.
A constant may be given a type explicitly by a constant declaration or
conversion, or implicitly when used in a variable declaration or an
assignment or as an operand in an expression. It is an error if the
constant value cannot be represented as a value of the respective
type.
An untyped constant has a default type which is the type to which the
constant is implicitly converted in contexts where a typed value is
required, for instance, in a short variable declaration such as i := 0
where there is no explicit type. The default type of an untyped
constant is bool, rune, int, float64, complex128 or string
respectively, depending on whether it is a boolean, rune, integer,
floating-point, complex, or string constant.
Numeric types
A numeric type represents sets of integer or floating-point values.
Some predeclared architecture-independent numeric types:
int32 the set of all signed 32-bit integers (-2147483648 to 2147483647)
int64 the set of all signed 64-bit integers (-9223372036854775808 to 9223372036854775807)
The value of an n-bit integer is n bits wide and represented using
two's complement arithmetic.
There are also some predeclared numeric types with
implementation-specific sizes:
uint either 32 or 64 bits
int same size as uint
Big is an untyped constant. There is no type to discover. It is given a type when used in a variable or assignment. The default type for the untyped constant Big is int.
const Big = 1 << 100
In Go, all arguments are passed by value as if by assignment. For fmt.Printf, the second argument is of type interface{}. Therefore, equivalently,
var arg2 interface{} = Big // constant 1267650600228229401496703205376 overflows int
fmt.Printf("Big is of type %T\n", arg2)
The default type for an untyped integer constant is int. Overflow is a compile-time error.
For example,
package main
import "fmt"
const (
// Create a huge number by shifting a 1 bit left 100 places.
// In other words, the binary number that is 1 followed by 100 zeroes.
Big = 1 << 100
)
func main() {
var arg2 interface{} = Big
fmt.Printf("Big is of type %T\n", arg2)
fmt.Printf("Big is of type %T\n", Big)
}
Playground: https://play.golang.org/p/9tynPTek3wN
Output:
prog.go:12:6: constant 1267650600228229401496703205376 overflows int
prog.go:15:13: constant 1267650600228229401496703205376 overflows int
Reference: The Go Blog: Constants
While it is true that an untyped constant takes the type needed by its context, the type it can assume is limited by the primitives of the language, so a constant that big is not actually usable anywhere in the code, due to the fact that it does not fit even in an uint64. The only use it could have would be that of using it in another constant expression, because otherwise that error will always be thrown.
Note that in Printf (and similar functions), the constant is converted to an interface{}, and thus it takes a type of int by default. For 32-bit machines, you need to do a type conversion first if you have a constant expression which overflows int32.
const i = 1 << 50
fmt.Println(i) // => constant 1125899906842624 overflows int
fmt.Println(int64(i)) // => 1125899906842624
If you want to do proper arithmetic on arbitrarily big numbers, there is a handy package: math/big.
i := big.NewInt(1)
i.Lsh(i, 100)
fmt.Println(i.String())
Playground
I know, go converts right side untyped constant to left side typed variable right after := initialization in expression: a := 5.
And it looks like the same as b := int(5) statement. So, what is the purpose of the second statement and how it differs from the first one?
Also, somewhere, I have seen []int(nil) expression, that's a bit confuse me.
Generally you don't need to use := in combination with a type conversion because it defeats the point of :=. := is there to infer the type. The type can generally be inferred from a constant value.
But not always. For example...
package main
import (
"fmt"
)
func main() {
a := 5
b := uint(5)
var c uint = 5
fmt.Printf("%T\n", a)
fmt.Printf("%T\n", b)
fmt.Printf("%T\n", c)
}
a := 5 infers that a is of type int, but what if you wanted it to be something else? 5 could be a bunch of different integer types. Maybe an unsigned integer? Maybe an integer of a specific length like int16?
You can do this by either specifying the type of the constant explicitly, as in b := uint(8), or by specifying the type of the variable explicitly, as in var c uint = 8. With b := uint(8), b's type is inferred from the uint constant being assigned to it. With var c uint = 8, 8 is inferred to be an unsigned integer because it is being assigned to a variable with the type uint. In both cases, b and c will be of type uint.
I'm not aware of any significant difference between b := uint(8) and var b uint = 8, so which you use is largely up to taste. I have a slight preference for var b uint = 8 because it is visually distinct from b := 8 to make it clear explicit types are being used.
You are referring to a type conversion. A type conversion is used to convert a value of one type to a value of another type.
The expression int(5) converts the untyped 5 to an int with value 5.
The expression []int(nil) converts the untyped nil to a []int with value nil.
The statements
a := 5
b := int(5)
declare a int variable with value 5. The declaration of a uses the default type for integer constants (which is int). The declaration of b explicitly uses the int type. Otherwise, they are the same. The use of the default type in the declaration of a is usually preferred over the explicit type in the declaration of b. The type conversion is commonly used for types other than the default type. Example c := int64(22).
userid := 12345
did := (userid & ^(0xFFFF << 48))
when compiling this code, I got:
./xxxx.go:511: constant -18446462598732840961 overflows int
Do you know what is the matter with this and how to solve it ?
Thanks.
^(0xFFFF << 48) is an untyped constant, which in go is an arbitrarily large value.
0xffff << 48 is 0xffff000000000000. When you negate it, you get -0xffff000000000001 (since with two's complement, -x = ^x + 1, or ^x = -(x + 1)).
When you write userid := 12345, userid gets the type int. Then when you try to and (&) it with the untyped constant -0xffff000000000001 the compiler figures that this constant needs to be an int. At this point, the compiler complains because the value is too large in magnitude to be an int.
If you're trying to get the constant 0x0000ffffffffffff, then you can use 1<<48 - 1, which (if you've got 64-bit ints), will fit. Since your code will never work if int is 32-bits, then you should probably use int64 in your code rather than int to make it portable.
The blog post https://blog.golang.org/constants explains how constants work, and some background on why they are the way they are.
The Go Programming Language Specification
Constants
Numeric constants represent values of arbitrary precision and do not
overflow.
Constants may be typed or untyped.
A constant may be given a type explicitly by a constant declaration or
conversion, or implicitly when used in a variable declaration or an
assignment or as an operand in an expression. It is an error if the
constant value cannot be represented as a value of the respective
type.
An untyped constant has a default type which is the type to which the
constant is implicitly converted in contexts where a typed value is
required, for instance, in a short variable declaration such as i := 0
where there is no explicit type. The default type of an untyped
constant is bool, rune, int, float64, complex128 or string
respectively, depending on whether it is a boolean, rune, integer,
floating-point, complex, or string constant.
Numeric types
int is an implementation-specific size, either 32 or 64 bits.
userid is of type int. For example,
package main
import "fmt"
func main() {
userid := 12345
did := uint64(userid) & ^uint64(0xFFFF<<48)
fmt.Println(userid, did)
}
Output:
12345 12345
The Go Programming Language Specification says that:
Constants may be typed or untyped
I am having a little doubt in my understanding.
Consider this example in the spec:
const l = "hi" // l == "hi" (untyped string constant)
const m = string(k) // m == "x" (type string)
The spec says:
constant may be given a type explicitly by a constant declaration or
conversion, or implicitly when used in a variable declaration or an
assignment or as an operand in an expression
By this statement, why isn't l typed since it is clearly a constant declaration?
This behaviour is clearer with another example
type Foo string
func f(a Foo) {}
func main() {
f("sarkozy")
const t = "julie gayet"
f(t)
s := "hollande"
//compile error
// f(s)
f(Foo(s)) // ok
}
Is the reason that f("sarkozy") compiles be due to this statement on Assignability in the spec?
x is an untyped constant representable by a value of type T.
My argument is the following:
"sarkozy" a an untyped literal.
Thus "sarkozy" being representable by Foo means I can type coerce like this Foo("sarkozy")
f(s) fails because s is not untyped.
Why isn't l typed since it is clearly a constant declaration?
Yes, it is clearly a constant declaration, as your quote says:
constant may be given a type explicitly by a constant declaration
However, in your case there is no explicitly given type. You can only have an implicitly given type when "used in a variable declaration or an assignment or as an operand in an expression".
Is the reason that f("sarkozy") compiles be due to this statement on Assignability in the spec?
Yes, the reason that f("sarkozy") compiles is because the untyped constant of "sarkozy" has a type given implicitly when used as an operand in an expression such as in your case.
"sarkozy" is implicitly given the type of Foo
So why doesn't f(s) compile? (okay, that was not in the question, but the question remains)
Your argument states that: "f(s) fails because s is not untyped."
True that s is not untyped. s is a variable and not a constant, and variables cannot be untyped.
The Go specs states for Variable Declarations:
If the type is absent and the corresponding expression evaluates to an untyped constant, the type of the declared variable is as described in §Assignments.
And that refers, from what I understand to the following:
the constant is first converted to type bool, rune, int, float64, complex128 or string respectively, depending on whether the value is a boolean, rune, integer, floating-point, complex, or string constant.
So, the following line:
s := "hollande"
will declare the variable (not constant) s of type string because the right-hand expression is an untyped string constant. The type is implicitly given during the declaration of the variable, not by analyzing what context it which it later on will be used.
f(s) will then result in a compile error because you try to use a value of type string where a value of type Foo is expected.
Given this code:
type Philosopher int
const (
Epictetus Philosopher = iota
Seneca
)
func Quote(who Philosopher) string {
fmt.Println("t: ", reflect.TypeOf(who))
switch who {
case Epictetus:
return "First say to yourself what you would be;
and do what you have to do"
case Seneca:
return "If a man knows not to which port he sails,
No wind is favorable"
}
return "nothing"
}
Calling Quote(5) will print Foo.Philosopher as the type for 5.
Why didn't the type checker complain since that is what a type safe enums are supposed to do i.e. limit the scope of values ?
These are not enums as you think of them. Type Philosopher is more or less an alias of an int. More or less, because it is a fundamentally distinct type, which can define its own methods.
The point of it is to provide semantic grouping of constants in a way that is clear to the programmer. Additionally, one gets the benefit of Go's type checker during compile time. But only to the degree that a value passed into a func(Philosopher) can not be implicitly interpreted as such. Passing a literal 5 as the parameter works, because constants like that in Go are inherently untyped. This will not work;
n := 5
Quote(n) // Compile error -> int is not Philosopher
Reason being that n is defined as int. There exists no implicit conversion between type int and Philosopher. However, this will work:
n := 5
Quote(Philosopher(n))
Because the type cast is valid. Go does not care whether or not 5 is a valid and pre-defined Philosopher constant.
Go doesn’t make any guarantees about valid values, except for those implied by int. The use of iota is just a convenience for defining a series of constants; it doesn’t say anything about valid values.
5 is a valid int, and therefore a valid Philosopher. You could also create const Plato = Philosopher(5).
Shorter answer should be like :
An untyped constant takes the type needed by its context.