What does the third index in Go's full slice expression s[a:b:c] control, and why use it?

## Two indices versus three Writing `s[a:b]` produces a slice whose length is `b-a` — but whose capacity is whatever remains from index `a` to the end of the source's backing array. Re-slicing narrows the *view*, never the *reach*. That is why `append` on a re-sliced value can write into elements the original still exposes. The full slice expression adds a third index: `s[a:b:c]`. - length = `b - a` - capacity = `c - a` - the array pointer is unchanged: it still points at element `a` of the same array The indices must satisfy `0 <= a <= b <= c <= cap(s)`. Violating that is a run-time panic with a slice-bounds error (for a constant index on an array or string operand it is caught at compile time, but on a slice the capacity is not a compile-time constant). Note what the third index does *not* do: it does not change where the data lives, it does not copy anything, and it does not shrink the allocation. ## The reason it exists The motivating case is handing out part of a buffer you still own. ```go buf := make([]byte, 0, 1024) buf = append(buf, "hello world"...) word := buf[0:5] // len 5, cap 1024 -- dangerous ``` If a caller appends to `word`, there are 1019 bytes of spare capacity, so the append writes into `buf`'s array at index 5, silently corrupting the space character and anything you later write there. Both slices are correct-looking code; the collision is invisible at each site. Change it to `word := buf[0:5:5]` and the result has capacity 5. The caller's first append finds no room, allocates a fresh array, copies the five bytes into it and writes there instead. Your buffer is untouched. The cost is one allocation *only if the caller actually appends* — if they merely read, nothing extra happens. The same reasoning applies inside a package: a method that returns `p.items[:n]` invites the caller to append into `p.items`; returning `p.items[:n:n]` does not. ## What it protects and what it does not It protects **element identity**: nobody else's append can overwrite elements of the source array. It is a *write* barrier in the informal sense, expressed purely through capacity. It does **not** protect the elements the slice does expose. `word[0] = 'H'` still writes into the shared array, because index assignment does not consult capacity. If the caller must not mutate the data at all, capping capacity is not enough — you have to copy, or hand out a `string`, which is immutable. It also does **not** reduce memory. A slice keeps its entire backing array reachable regardless of length or capacity, so `buf[0:5:5]` still pins the whole 1024-byte array as long as it is alive. Capping capacity and freeing memory are different problems with different fixes; the fix for memory is to allocate a fresh, right-sized slice and `copy` into it. ## Where it shows up in practice - A library function returning a view of an internal buffer to a caller it does not control. - Splitting a buffer into non-overlapping regions that different goroutines or different call paths will each append to — without the cap, two regions can write to the same bytes. - Any API that documents "the returned slice is valid until the next call": capping capacity removes one class of surprise from it, though a copy removes all of them. ## Reading it correctly Because the syntax looks like three bounds, a common misreading is that `s[2:5:8]` yields a slice from 2 to 8 in some sense, or that the third number is an end index for the capacity in absolute terms *and* changes the length. It does not: length comes from the first two indices only. For `s := make([]int, 10, 100)`, `s[2:5:8]` has length 3 and capacity 6 — both measured from index 2. One syntactic restriction to remember: full slice expressions are defined for slices, arrays and pointers to arrays, but **not** for strings. Strings have no spare capacity to hand out in the first place, since they are immutable.