Go: A Surprising Edge Case Concerning append and Slice Aliasing

In Go, the append function reallocates the underlying array if there's no more room. Hence, if you have two slices that point to the same array, after you append to one of the slices, the other slice may or may not point to the same array. This can lead to some unexpected behavior:

package main

import "fmt"

func main() {
 // Create a slice of length 1 and capacity 2.
 a := make([]int, 1, 2)

 // b "aliases" a
 b := a

 // If I set something in a, you see it in b.
 a[0] = 1
 fmt.Println(a[0], b[0]) // Prints 1 1; they're equal.

 // append returns a new slice, but with the same array.
 // Hence, if I set something in a, you still see it in b.
 a = append(a, 2)
 a[0] = 2
 fmt.Println(a[0], b[0]) // Prints 2 2; they're equal.

 // I'm doing the same thing as last time. However, this time,
 // append has to allocate a new array because there's not enough
 // space. Hence, if I set something in a, you don't see it in b.
 a = append(a, 3)
 a[0] = 3
 fmt.Println(a[0], b[0]) // Prints 3 2; they're *not* equal.
}

Having multiple aliases to the same mutable data can lead to some subtle behavior and lots of bugs if you're not careful. It's perhaps even more surprising to the naive reader since a and b don't look like pointers. In fact, they're not. They're slices which are a value type that have a pointer within them.

Immutable data structures (like lists in Lisp) don't have these issues. However, you lose some of the performance that a raw array can provide.