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.
Comments
Um, what?
Lisp lists are very highly mutable. Aaaand they're not arrays.
Yes, I know. However, a and b are both references to the same underlying array. "alias" was the best term I could come up with.
Hence it is not a edge case
"Slices hold references to an underlying array, and if you assign one slice to another, both refer to the same array."
https://golang.org/doc/effective_go.html#slices