Golang Slice: append, make, len vs cap, and the Sharing Bug

A slice in one example

A slice is a growable view onto an array. You create one with a literal or with make, grow it with append, and read its size with len.

package main

import "fmt"

func main() {
	langs := []string{"Go", "Rust"}
	langs = append(langs, "Zig", "C")
	fmt.Println(langs, len(langs))

	for i, l := range langs {
		fmt.Println(i, l)
	}

	fmt.Println(langs[1:3]) // elements 1 and 2
}

[]string has no length in the brackets. That is the difference from an array type like [4]string, whose size is fixed.

What a slice is

A slice value is a small header with three fields:

• a pointer to an element in a backing array
• a length: how many elements the slice can see
• a capacity: how many elements exist from that pointer to the end of the backing array

Copying a slice (assigning it, passing it to a function) copies only this header. Both copies point at the same elements. Almost every slice surprise comes from forgetting that.

make: length and capacity

make([]T, len, cap) allocates a backing array and returns a slice over it. The capacity is optional and defaults to the length.

package main

import "fmt"

func main() {
	a := make([]int, 3) // len 3, cap 3, all zeros
	fmt.Println(a, len(a), cap(a))

	b := make([]int, 0, 10) // len 0, room for 10
	fmt.Println(b, len(b), cap(b))

	for i := range 5 {
		b = append(b, i*i)
	}
	fmt.Println(b, len(b), cap(b)) // no reallocation happened
}

A common mix-up: make([]int, 5) followed by five append calls gives you ten elements, the first five of them zero. Use make([]int, 0, 5) when you plan to append, or make([]int, 5) when you plan to assign by index.

Preallocating capacity when you know the final size avoids repeated growth. It is an optimization, not a requirement.

append and growth

append adds elements after the current length. If the capacity is big enough, it writes in place. If not, it allocates a larger array, copies the old elements over, and returns a slice pointing at the new array.

package main

import "fmt"

func main() {
	var s []int
	prevCap := cap(s)
	for i := range 2000 {
		s = append(s, i)
		if cap(s) != prevCap {
			fmt.Printf("len %4d  cap %4d\n", len(s), cap(s))
			prevCap = cap(s)
		}
	}
}

The capacity roughly doubles while the slice is small and grows by a smaller factor (moving toward 1.25x) once it passes 256 elements. The exact numbers are a runtime detail that has changed between Go versions, so never write code that depends on them.

Because append may return a different array, you must use its result:

append(s, 4)     // compile error: append(s, 4) (value of type []int) is not used
s = append(s, 4) // correct

Appending a whole slice uses the spread syntax: s = append(s, other...).

Slicing shares the backing array

s[low:high] makes a new slice header over the same array, covering indexes low up to but not including high. Either bound can be left out. No elements are copied.

package main

import "fmt"

func main() {
	nums := []int{10, 20, 30, 40, 50}
	mid := nums[1:4] // 20 30 40
	mid[0] = 99
	fmt.Println(nums) // the write shows up in nums

	fmt.Println(len(mid), cap(mid)) // cap runs to the end of nums
}

Output:

[10 99 30 40 50]
3 4

That sharing is what makes slicing cheap. It is also the source of the most famous slice bug.

The append aliasing bug

When a sub-slice has spare capacity, appending to it writes into the parent's array, over elements the parent still uses.

package main

import "fmt"

func main() {
	base := []int{1, 2, 3, 4, 5}
	first := base[:2] // [1 2], cap 5

	first = append(first, 100) // fits in capacity: overwrites base[2]
	fmt.Println(base)
	fmt.Println(first)

	// Two slices built from the same prefix clobber each other.
	prefix := make([]string, 0, 4)
	prefix = append(prefix, "cmd")
	a := append(prefix, "build")
	b := append(prefix, "test")
	fmt.Println(a, b) // both print test
}

Output:

[1 2 100 4 5]
[1 2 100]
[cmd test] [cmd test]

a and b share the array slot after "cmd", so the second append overwrote the first. The code looks fine and works whenever the capacity happens to be full, which is why this bug shows up only sometimes.

Two fixes:

1. The full slice expression s[low:high:max] caps the capacity at max-low. With no spare capacity, the next append must allocate. first := base[:2:2] makes the first example safe.
2. Copy explicitly when a slice will outlive the call or be appended to independently: slices.Clone(prefix) or append([]string(nil), prefix...).

A related trap: a small slice of a huge array keeps the whole array alive for the garbage collector. If you read a 100 MB file and keep data[:10], the 100 MB stays in memory. Clone the part you keep.

copy

The built-in copy(dst, src) copies min(len(dst), len(src)) elements and returns that count. It never grows dst.

package main

import (
	"fmt"
	"slices"
)

func main() {
	src := []int{1, 2, 3}

	dst := make([]int, len(src))
	n := copy(dst, src)
	dst[0] = 100
	fmt.Println(n, src, dst) // independent

	var empty []int
	fmt.Println(copy(empty, src)) // 0: dst has no length

	c := slices.Clone(src) // the one-line version (Go 1.21)
	fmt.Println(c)
}

copy handles overlapping source and destination correctly, so copy(s[1:], s) shifts elements right without corruption.

The slices package

Since Go 1.21 the standard slices package has generic helpers for the operations you used to write by hand.

package main

import (
	"fmt"
	"slices"
)

func main() {
	s := []int{5, 2, 8, 2, 9}

	fmt.Println(slices.Contains(s, 8)) // true
	fmt.Println(slices.Index(s, 2))    // 1
	fmt.Println(slices.Max(s), slices.Min(s))

	slices.Sort(s)
	fmt.Println(s)
	i, found := slices.BinarySearch(s, 8)
	fmt.Println(i, found)

	s = slices.Compact(s) // drop adjacent duplicates
	fmt.Println(s)

	s = slices.Delete(s, 1, 2) // remove index 1
	fmt.Println(s)

	s = slices.Insert(s, 1, 3, 4)
	fmt.Println(s)

	slices.Reverse(s)
	fmt.Println(s, slices.Equal(s, []int{9, 8, 4, 3, 2}))
}

Delete and Insert return a slice you must assign, like append. Sorting has its own page: sorting.

Removing elements while looping by index skips elements. Use slices.DeleteFunc instead:

s = slices.DeleteFunc(s, func(n int) bool { return n%2 == 0 }) // drop evens

2D slices

A slice of slices gives you a grid whose rows can differ in length. Each row must be allocated separately.

package main

import "fmt"

func main() {
	rows, cols := 3, 4
	grid := make([][]int, rows)
	for r := range grid {
		grid[r] = make([]int, cols)
	}
	grid[1][2] = 7

	for _, row := range grid {
		fmt.Println(row)
	}

	// Rows of different lengths are fine.
	triangle := [][]int{{1}, {1, 1}, {1, 2, 1}}
	fmt.Println(triangle)
}

Forgetting the inner make leaves each row nil, and grid[1][2] = 7 panics with index out of range [2] with length 0.

nil slices and empty slices

package main

import (
	"encoding/json"
	"fmt"
)

func main() {
	var a []int  // nil
	b := []int{} // empty, not nil

	fmt.Println(len(a), len(b), a == nil, b == nil)

	a = append(a, 1) // append works on nil
	fmt.Println(a)

	ja, _ := json.Marshal(struct{ Items []int }{})
	jb, _ := json.Marshal(struct{ Items []int }{Items: []int{}})
	fmt.Println(string(ja), string(jb))
}

A nil slice behaves like an empty one for len, cap, range and append, so prefer var s []T as the zero state. Initialize to []T{} only when the difference matters, which is mostly JSON output (null vs []). Check emptiness with len(s) == 0, not s == nil.

Slices and functions

A function receiving a slice can change its elements, and the caller sees the changes. It cannot change the caller's length, because it received a copy of the header. A function that appends must return the new slice:

func addAll(s []int, vals ...int) []int {
	return append(s, vals...)
}

This is why append, slices.Delete and slices.Insert all return a slice.

Common mistakes

• Ignoring append's result. Does not compile when discarded entirely, but append(s, x) assigned to a different variable than the one you keep using is a logic bug.
• Two appends from one base. They may share storage. Clone the base or use a full slice expression.
• make([]T, n) then append. Leaves n zeros at the front.
• Index out of range. s[len(s)] panics. The last element is s[len(s)-1].
• Comparing slices with ==. Only s == nil compiles. Use slices.Equal.