Some (Real) Go Subtleties

I just read an article: 15 Go Subtleties You May Not Already Know. After reading that article, I just feel the title is some weird/improper. Because all the so-called subtleties mentioned in that article are what a quanlified Go programer should know about.

Go indeed has many subtleties. Even many professional Go programmers are not aware of some of them. Here, this article shows several of them (all of them are from the Go Details & Tips 101 book).

Comparing two pointers to the same zero-size value might result either true or false, even during the same program execution

For example. What doesn't the following program print? Nothing, true, or false?

package main

var a, b [0]int
var p, q = &a, &b

func main() {
	if (p == q) {
		p, q = &a, &b
		println(p == q)
	}
}

It prints false (with the official Go toolchain). Surprised? But it looks the behavior doesn't violate Go specification.

`for true {...}` and `for {...}` are not eqivalent

For example, the function foo shown below compiles, but bar doesn't.

func foo() int {
  for {}
}

func bar() int {
  for true {}
}

When using the `make` built-in function to create a map, the second argument (`cap`) can be negative

For example, the following code compiles.

package main

var n = -100

func main() {
    var m = make(map[int]bool, n)
    m[123] = true;
}

A negative cap argument is equivalent to omitting it.

`aConstantString[:]` is not a constant

Here is an example to prove it.

package main

const s = "zigo 101" // len(s) == 8
var a byte = 1 << len(s) / 128
var b byte = 1 << len(s[:]) / 128

func main() {
	println(a, b) // 2 0
}

Some Go programmers might be surprised by this result. To understand the result well, we need to know about the next subtlety.

If the left operand of a non-constant bit-shift expression is untyped, then its type is determined as the assumed type of the expression

For example, the following program prints 0 0 2.

package main

const N = 8
var n = N

func main() {
	var x byte = 1 << n / 128
	var y = byte(1 << n / 128)
	var z byte = 1 << N / 128
	
	println(x, y, z) // 0 0 2
}

In the first two declarations, the types of 1 are both assumed as byte. So the two declarations are both eqivalent to the following line, in which the run-time expression byte(1) << n overflows (and is truncated to 0).

    ... = byte(1) << n // 128

The last declaration is eqivalent to the following line. The expression 1 << N / 128 is evaluated at compile time. In the expression, 1 is treated as untyped int value.

   var z = 2

Some (Real) Go Subtleties

Comparing two pointers to the same zero-size value might result either true or false, even during the same program execution

for true {...} and for {...} are not eqivalent

When using the make built-in function to create a map, the second argument (cap) can be negative

aConstantString[:] is not a constant

If the left operand of a non-constant bit-shift expression is untyped, then its type is determined as the assumed type of the expression

`for true {...}` and `for {...}` are not eqivalent

When using the `make` built-in function to create a map, the second argument (`cap`) can be negative

`aConstantString[:]` is not a constant