Constants are expressions whose value is known to the compiler and whose evaluation is guaranteed to occur at compile time, not at run time. The underlying type of every constant is a basic type: boolean, string, or number.
A const
declaration defines named values that look syntactically like
variables but whose value is constant, which prevents
accidental (or nefarious) changes during program execution. For
instance, a constant is more appropriate
than a variable for a mathematical constant
like pi
, since its value won’t change:
const pi = 3.14159 // approximately; math.Pi is a better approximation
As with variables, a sequence of constants can appear in one declaration; this would be appropriate for a group of related values:
const ( e = 2.71828182845904523536028747135266249775724709369995957496696763 pi = 3.14159265358979323846264338327950288419716939937510582097494459 )
Many computations on constants can be completely evaluated at compile time, reducing the work necessary at run time and enabling other compiler optimizations. Errors ordinarily detected at run time can be reported at compile time when their operands are constants, such as integer division by zero, string indexing out of bounds, and any floating-point operation that would result in a non-finite value.
The results of all arithmetic, logical, and comparison operations
applied to constant operands are themselves constants, as are the
results of conversions and calls to certain built-in functions such as len
,
cap
, real
, imag
, complex
, and
unsafe.Sizeof
(§13.1).
Since their values are known to the compiler, constant expressions may appear in types, specifically as the length of an array type:
const IPv4Len = 4 // parseIPv4 parses an IPv4 address (d.d.d.d). func parseIPv4(s string) IP { var p [IPv4Len]byte // ... }
A constant declaration may specify a type as well as a value, but
in the absence of an explicit type, the type is inferred from the
expression on the right-hand side.
In the following, time.Duration
is a named type whose underlying
type is int64
, and time.Minute
is a constant of that type.
Both of the constants declared below thus have the type time.Duration
as well,
as revealed by %T
:
const noDelay time.Duration = 0 const timeout = 5 * time.Minute fmt.Printf("%T %[1]v ", noDelay) // "time.Duration 0" fmt.Printf("%T %[1]v ", timeout) // "time.Duration 5m0s" fmt.Printf("%T %[1]v ", time.Minute) // "time.Duration 1m0s"
When a sequence of constants is declared as a group, the right-hand side expression may be omitted for all but the first of the group, implying that the previous expression and its type should be used again. For example:
const ( a = 1 b c = 2 d ) fmt.Println(a, b, c, d) // "1 1 2 2"
This is not very useful if the implicitly copied right-hand
side expression always evaluates to the same thing. But what if it
could vary? This brings us to iota
.
iota
A const
declaration may use the constant
generator iota
, which is used to create a sequence of related
values without spelling out each one explicitly. In a const
declaration, the value of iota
begins at zero and increments by one
for each item in the sequence.
Here’s an example from the time
package, which defines named
constants of type Weekday
for the days of the week, starting with
zero for Sunday
. Types of this kind are often called
enumerations, or enums for short.
type Weekday int const ( Sunday Weekday = iota Monday Tuesday Wednesday Thursday Friday Saturday )
This declares Sunday
to be 0, Monday
to be 1, and so on.
We can use iota
in more complex expressions too, as in this
example from the net
package where each of the lowest 5 bits
of an unsigned integer is given a distinct name and boolean
interpretation:
type Flags uint const ( FlagUp Flags = 1 << iota // is up FlagBroadcast // supports broadcast access capability FlagLoopback // is a loopback interface FlagPointToPoint // belongs to a point-to-point link FlagMulticast // supports multicast access capability )
As iota
increments, each constant is assigned the value of
1 << iota
, which evaluates to successive powers of two, each
corresponding to a single bit.
We can use these constants within functions that test, set, or clear
one or more of these bits:
func IsUp(v Flags) bool { return v&FlagUp == FlagUp } func TurnDown(v *Flags) { *v &^= FlagUp } func SetBroadcast(v *Flags) { *v |= FlagBroadcast } func IsCast(v Flags) bool { return v&(FlagBroadcast|FlagMulticast) != 0 } func main() { var v Flags = FlagMulticast | FlagUp fmt.Printf("%b %t ", v, IsUp(v)) // "10001 true" TurnDown(&v) fmt.Printf("%b %t ", v, IsUp(v)) // "10000 false" SetBroadcast(&v) fmt.Printf("%b %t ", v, IsUp(v)) // "10010 false" fmt.Printf("%b %t ", v, IsCast(v)) // "10010 true" }
As a more complex example of iota
, this declaration names
the powers of 1024:
const ( _ = 1 << (10 * iota) KiB // 1024 MiB // 1048576 GiB // 1073741824 TiB // 1099511627776 (exceeds 1 << 32) PiB // 1125899906842624 EiB // 1152921504606846976 ZiB // 1180591620717411303424 (exceeds 1 << 64) YiB // 1208925819614629174706176 )
The iota
mechanism has its limits.
For example, it’s not possible to
generate the more familiar powers of 1000 (KB, MB, and so on) because
there is no exponentiation operator.
Exercise 3.13:
Write const
declarations for KB, MB, up through YB as compactly
as you can.
Constants in Go are a bit unusual.
Although a constant can have any of the basic data types like
int
or float64
, including named basic types like
time.Duration
, many constants are not committed to a particular
type.
The compiler represents these uncommitted constants with much greater
numeric precision than values of basic types,
and arithmetic on them is more precise than machine arithmetic;
you may assume at least 256 bits of precision.
There are six flavors of these uncommitted constants, called
untyped boolean, untyped integer, untyped rune, untyped
floating-point, untyped complex, and untyped string.
By deferring this commitment, untyped constants not only retain their
higher precision until later, but they can participate in many more
expressions than committed constants without requiring conversions.
For example, the values ZiB
and YiB
in the example above
are too big to store in any integer variable, but they are legitimate
constants that may be used in expressions like this one:
fmt.Println(YiB/ZiB) // "1024"
As another example, the floating-point constant math.Pi
may be used
wherever any floating-point or complex value is needed:
var x float32 = math.Pi var y float64 = math.Pi var z complex128 = math.Pi
If math.Pi
had been committed to a specific type such as float64
,
the result would not be as precise,
and type conversions would be required to use it when a float32
or
complex128
value is wanted:
const Pi64 float64 = math.Pi var x float32 = float32(Pi64) var y float64 = Pi64 var z complex128 = complex128(Pi64)
For literals, syntax determines flavor.
The literals 0
, 0.0
, 0i
, and 'u0000'
all denote constants of the same value but different flavors:
untyped integer, untyped floating-point, untyped complex, and untyped
rune, respectively.
Similarly, true
and false
are
untyped booleans and string literals are untyped strings.
Recall that /
may represent integer or floating-point division
depending on its operands.
Consequently, the choice of literal may affect the result of a
constant division expression:
var f float64 = 212 fmt.Println((f - 32) * 5 / 9) // "100"; (f - 32) * 5 is a float64 fmt.Println(5 / 9 * (f - 32)) // "0"; 5/9 is an untyped integer, 0 fmt.Println(5.0 / 9.0 * (f - 32)) // "100"; 5.0/9.0 is an untyped float
Only constants can be untyped. When an untyped constant is assigned to a variable, as in the first statement below, or appears on the right-hand side of a variable declaration with an explicit type, as in the other three statements, the constant is implicitly converted to the type of that variable if possible.
var f float64 = 3 + 0i // untyped complex -> float64 f = 2 // untyped integer -> float64 f = 1e123 // untyped floating-point -> float64 f = 'a' // untyped rune -> float64
The statements above are thus equivalent to these:
var f float64 = float64(3 + 0i) f = float64(2) f = float64(1e123) f = float64('a')
Whether implicit or explicit, converting a constant from one type to another requires that the target type can represent the original value. Rounding is allowed for real and complex floating-point numbers:
const ( deadbeef = 0xdeadbeef // untyped int with value 3735928559 a = uint32(deadbeef) // uint32 with value 3735928559 b = float32(deadbeef) // float32 with value 3735928576 (rounded up) c = float64(deadbeef) // float64 with value 3735928559 (exact) d = int32(deadbeef) // compile error: constant overflows int32 e = float64(1e309) // compile error: constant overflows float64 f = uint(-1) // compile error: constant underflows uint )
In a variable declaration without an explicit type (including short variable declarations), the flavor of the untyped constant implicitly determines the default type of the variable, as in these examples:
i := 0 // untyped integer; implicit int(0) r := ' 00' // untyped rune; implicit rune(' 00') f := 0.0 // untyped floating-point; implicit float64(0.0) c := 0i // untyped complex; implicit complex128(0i)
Note the asymmetry: untyped integers are converted to int
,
whose size is not guaranteed, but untyped floating-point and complex
numbers are converted to the explicitly sized types float64
and
complex128
.
The language has no unsized float
and complex
types
analogous to unsized int
, because it is very difficult to write
correct numerical algorithms without knowing the size of one’s
floating-point data types.
To give the variable a different type, we must explicitly convert the untyped constant to the desired type or state the desired type in the variable declaration, as in these examples:
var i = int8(0) var i int8 = 0
These defaults are particularly important when converting an untyped constant to an interface value (see Chapter 7) since they determine its dynamic type.
fmt.Printf("%T ", 0) // "int" fmt.Printf("%T ", 0.0) // "float64" fmt.Printf("%T ", 0i) // "complex128" fmt.Printf("%T ", ' 00') // "int32" (rune)
We’ve now covered the basic data types of Go. The next step is to show how they can be combined into larger groupings like arrays and structs, and then into data structures for solving real programming problems; that is the topic of Chapter 4.
3.133.109.211