Go Tips 101

Package developers can put a non-exported zero-size field in a struct type definition, so that compilers will forbid package users using composite literals without field names to create values of the struct type.

An example:

// foo.go
package foo

type Config struct {
	_    [0]int
	Name string
	Size int
}

// main.go
package main

import "foo"

func main() {
	//_ = foo.Config{[0]int{}, "bar", 123} // doesn't compile
	_ = foo.Config{Name: "bar", Size: 123} // compile okay
}

Please try not to place the zero-size non-exported field as the last field in the struct, for doing so might enlarge the size of the struct type.

Simetimes, we want to avoid a custom struct type being used a map key types, then we can put a field of a non-exported zero-size uncomparable type in a struct type to make the struc type uncomparable. For example:

package main

type T struct {
	Dummy        [0]func()
	AnotherField int
}

var x map[T]int // compile error: invalid map key type T

func main() {
	var a, b T
	_ = a == b // compile error: invalid operation:
}

Currently (Go 1.11), there are some evaluation orders in multi value assignments are unspecified and there are some disputes and bugs in the standard Go compiler and gccgo compiler when there are dependencies existing between the expressions invloved in a multi-value assignment. So try to split a multi-value assignment into multiple single value assignments if there are, or you can't make sure whether or not there are, dependencies between the involved expressions.

We can range over an array with zero-size element or a nil array pointer to simulate such a loop. For example:

package main

import "fmt"

func main() {
	const N = 5

	for i := range [N]struct{}{} {
		fmt.Println(i)
	}
	for i := range [N][0]int{} {
		fmt.Println(i)
	}
	for i := range (*[N]int)(nil) {
		fmt.Println(i)
	}
}

Values of the bytes.Buffer type, strings.Builder type and the types in the sync standard package are not recommended to be copied. (They really should not be copied, though it is no problems to copy them under some specified circumstances.)

The implementation of strings.Builder will detect invalid strings.Builder value copies. Once such a copy is found, panic will occur. For example:

package main

import "strings"

func main() {
	var b strings.Builder
	b.WriteString("hello ")
	var b2 = b
	b2.WriteString("world!") // panic here
}

Copying values of the types in the sync standard package will be warned by the go vet command provided in Go SDK.

// demo.go
package demo

import "sync"

func f(m sync.Mutex) { // warning: f passes lock by value: sync.Mutex
	m.Lock()
	// do something ...
	m.Unlock()
}

$ go vet demo.go
./demo.go:5: f passes lock by value: sync.Mutex

Copying bytes.Buffer values will never be detected at run time nor by the go vet command. Just be careful not to do this.

Please read the memclr optimization for details.

Use the way in the following example. (Assume the prototype of the method needed to be checked is M(int) string.)

package main

import "fmt"

type A int
type B int
func (b B) M(x int) string {
	return fmt.Sprint(b, ": ", x)
}

func check(v interface{}) bool {
	_, has := v.(interface{M(int) string})
	return has
}

func main() {
	var a A = 123
	var b B = 789
	fmt.Println(check(a)) // false
	fmt.Println(check(b)) // true
}

Please read this wiki article and this wiki article for details.

Assume a package provides a func NewX(...Option) *X function, and the implementation of this function will merge the input options with some internal default options, then the following implementation is not recommended.

func NewX(opts ...Option) *X {
	options := append(opts, defaultOpts...)
	// Use the merged options to build and return a X.
	// ...
}

The reason of the above implementation is not recommended is the append call may modify the underlying Option sequence of the argument opts. For most scenarios, it is not a problem. But for some special scenarios, it may cause some unexpected results.

To avoid modifying the underlying Option sequence of the input argument, we should use the following way instead.

func NewX(opts ...Option) *X {
	options := append(opts[:len(opts):len(opts)], defaultOpts...)
	// Use the merged options to build and return a X.
	// ...
}

Another scenario at which we should use three-index subslice form is mentioned in this wiki article.

One drawback of three-index subslice forms is they are some verbose. In fact, I ever made a proposal to make it less verbose, but it was declined.

We can assign a value of the custom defined type to a variable of type of the specified interface type to make sure the custom type implements the specified interface type, and more importantly, to show the custom type is intended to implement which interface types. Sometimes, writing docs in runnable code is much better than in comments.

package myreader

import "io"

type MyReader uint16

func NewMyReader() *MyReader {
	var mr MyReader
	return &mr
}

func (mr *MyReader) Read(data []byte) (int, error) {
	switch len(data) {
	default:
		*mr = MyReader(data[0]) << 8 | MyReader(data[1])
		return 2, nil
	case 2:
		*mr = MyReader(data[0]) << 8 | MyReader(data[1])
	case 1:
		*mr = MyReader(data[0])
	case 0:
	}
	return len(data), io.EOF
}

// Any of the following three lines assures
// type *MyReader implements io.Reader.
var _ io.Reader = NewMyReader()
var _ io.Reader = (*MyReader)(nil)
func _() {_ = io.Reader(nil).(*MyReader)}

Please read this article for details.

Several ways to guarantee a constant N is not smaller than another constant M at compile time:

const N, M = 8, 8

// Any of the following lines can guarantee N >= M
func _(x []int) {_ = x[M-N]}
func _(){_ = []int{M-N: 0}}
func _([N-M]int){}
var _ [N-M]int
const _ uint = N-M
type _ [N-M]int

One more way which is stolen from @lukechampine. It makes use of the rule that duplicate constant keys can't appear in the same composite literal.

var _ = map[bool]struct{}{false: struct{}{}, N>=M: struct{}{}}

The above way looks some verbose but it is more general. It can be used to assert any conditions. It can be less vervose but needs a little more (negligible) memory:

var _ = map[bool]int{false: 0, M>=N: 1}

NOTE: currently, gccgo 8.2.0 has a bug which allows duplicate constant keys in composite literals. So this trick doesn't work for gccgo now. This bug will be fixed in a later gccgo version.

Similarly, ways to assert two integer constants equal to each other:

var _ [N-M]int; var _ [M-N]int
type _ [N-M]int; type _ [M-N]int
const _, _ uint = N-M, M-N
func _([N-M]int, [M-N]int) {}

var _ = map[bool]int{false: 0, M==N: 1}

var _ = [1]int{M-N: 0} // the only valid index is 0
var _ = [1]int{}[M-N]  // the only valid index is 0

var _ [N-M]int = [M-N]int{}

The last line is also inspired by one of Luke Champine's tweets.

const MaxUint = ^uint(0)
const MaxInt = int(^uint(0) >> 1)

This tip is Go unrelated.

const Is64bitArch = ^uint(0) >> 63 == 1
const Is32bitArch = ^uint(0) >> 63 == 0
const WordBits = 32 << (^uint(0) >> 63) // 64 or 32

Please read Go value memory layouts for details.

When a non-interface value is assigned to an interface value, a copy of the non-interface value will be boxed into the interface value. The copy cost depends on the size of the non-interface value. The larger the size, the higher the copy cost. So please try to avoid boxing large-size values into interface values.

For example, in the following example, the cost of the latter two print calls are muich lower than the former two.

package main

import "fmt"

func main() {
	var a [1000]int
	
	// This cost of the two lines is high.
	fmt.Println(a)                   // a is copied
	fmt.Printf("Type of a: %T\n", a) // a is copied
	
	// The cost of the two lines is low.
	fmt.Printf("%v\n", a[:])
	fmt.Println("Type of a:", fmt.Sprintf("%T", &a)[1:])
}

About value sizes of different types, please read value copy costs in Go.

Please read this article to get what is BCE and how well BCE is supported in Go now. That article also show some examples on how to making use of BCE to do code optimization. Here, another example is provided:

package main

import (
	"strings"
	"testing"
)

func NumSameBytes_1(x, y string) int {
	if len(x) > len(y) {
		x, y = y, x
	}
	for i := 0; i < len(x); i++ {
		if x[i] != y[i] {
			return i
		}
	}
	return len(x)
}

func NumSameBytes_2(x, y string) int {
	if len(x) > len(y) {
		x, y = y, x
	}
	if len(x) <= len(y) { // more code but more efficient
		for i := 0; i < len(x); i++ {
			if x[i] != y[i] { // bound check eliminated
				return i
			}
		}
	}
	return len(x)
}

var x = strings.Repeat("hello", 100) + " world!"
var y = strings.Repeat("hello", 99) + " world!"

func BenchmarkNumSameBytes_1(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = NumSameBytes_1(x, y)
	}
}

func BenchmarkNumSameBytes_2(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = NumSameBytes_2(x, y)
	}
}

In the above example, function NumSameBytes_2 is more efficient than function NumSameBytes_1. The benchmark result:

BenchmarkNumSameBytes_1-4   	10000000	       669 ns/op
BenchmarkNumSameBytes_2-4   	20000000	       450 ns/op

Please note, there are many small improvements in each main release of the standard Go compiler (gc). The trick used in the above example doesn't work for Go SDK versions earlier than 1.11. And future gc versions may become smarter so that the trick will become unnecessary.