Arrays vs Slices

## Two different types, not two spellings of one Go's `[5]int` and `[]int` look similar and behave almost nothing alike. Understanding the difference is the first real hurdle for anyone arriving from a language where "array" means one thing. ### An array is a value with its length in its type An array type is written `[N]T`, where `N` is a constant expression. That `N` is part of the type's identity: `[3]int` and `[4]int` are two distinct types, and no assignment or argument passing converts between them. Because the length is fixed in the type, `len(a)` for an array `a` is a constant the compiler folds away, and there is no way for an array's length to change at run time. An array is also an ordinary value, in exactly the way an `int` or a struct is. Assignment copies it: ```go var a [3]int b := a b[0] = 99 // a[0] is still 0 ``` The same is true at a call boundary: `func f(x [3]int)` receives a copy of all three elements, and whatever `f` writes into `x` is invisible to the caller. If you want the callee to write through to the caller's array, you pass `*[3]int` or, far more commonly, a slice. The storage for an array lives wherever the array itself lives. A local array sits in the function's frame unless the compiler decides it must escape; an array field inside a struct sits inline in that struct, with no separate allocation and no pointer to follow. ### A slice is a view onto a backing array A slice type is written `[]T`, with no length. A slice value refers to a contiguous run of elements in some backing array and carries two numbers with it: a **length** (`len(s)`, how many elements you may index) and a **capacity** (`cap(s)`, how many elements are available in the backing array from the slice's start). Different slice values of the same type routinely have different lengths, so the length is data, not type. Copying a slice value copies the reference along with the two numbers; it does not copy elements: ```go s := []int{1, 2, 3} t := s t[0] = 99 // s[0] is now 99 ``` That is why passing a slice to a function is cheap regardless of how many elements it holds, and why a function that writes `s[0] = x` is visible to its caller. Growing a slice is a separate matter with its own rules; what matters here is that an array can never grow, while a slice's length is a run-time value. ### Moving between them Slicing an array produces a slice over that array's storage: given `var arr [4]byte`, the expression `arr[:]` is a `[]byte` with length 4 and capacity 4, sharing `arr`'s bytes. A later write through the slice changes `arr`. The array being sliced must be addressable, which is why you can slice a variable but not the array returned directly by a function call. In the other direction, a slice can be converted to an array (`[4]byte(b)`, which copies) or to an array pointer (`(*[4]byte)(b)`, which aliases), and both panic if the slice is too short. ### Why the standard library almost always uses slices A function that takes `[]byte` accepts input of any length, accepts a sub-range of a larger buffer without copying, and can be handed the storage of an array with `[:]`. A function that takes `[32]byte` accepts exactly 32 bytes and copies them on every call. So slices are the general-purpose sequence type, and arrays appear where the size is genuinely fixed by a specification: a 32-byte digest, a 16-byte network address, a fixed-size frame read from a device. ### The mistakes to avoid - Treating an array parameter as a reference, as it would be in C or Java, and being surprised that the caller sees nothing. - Treating a slice as a container that owns its elements, and being surprised that two slice variables affect each other. - Assuming `[3]int` will convert to `[4]int` or to `[]int` implicitly; neither happens, and the slice case needs an explicit `a[:]`. - Passing a large array such as `[4096]byte` by value in a hot path and paying a 4 KB copy per call without noticing.