In Go, what does `buf = buf[:0]` reuse, and what stays in the underlying array?

## The three-word header A slice is a pointer to a backing array, a length, and a capacity. `buf[:0]` produces a new slice header with the **same pointer**, the **same capacity**, and a length of 0. No memory is allocated, no memory is freed, and not a single byte of the array is touched — reslicing is arithmetic on three words. ## What that buys you Because the pointer and capacity survive, the next `append` writes into the array that is already there, starting at index 0. In a loop that formats one record per iteration, this is the difference between one allocation for the whole loop and one allocation per iteration: ``` buf := make([]byte, 0, 256) for _, rec := range records { buf = buf[:0] buf = appendRecord(buf, rec) w.Write(buf) } ``` After a few iterations the buffer has reached the high-water mark of the records it has seen and stops growing entirely. The same idea is what `bytes.Buffer.Reset` and `strings.Builder.Reset` do for those types: keep the storage, drop the contents. ## What it does not do **It does not clear anything.** The bytes past the new length are still in the array, and they are still reachable — a slice may be resliced up to its capacity, so `buf[:cap(buf)]` shows them: ``` buf := make([]byte, 0, 16) buf = append(buf, "secret"...) buf = buf[:0] buf = append(buf, "hi"...) // buf[:6] is "hicret" - only the first two bytes were overwritten ``` Three consequences follow. **1. Aliasing.** Any slice header that already points into that array keeps pointing into it. If you returned `buf[:n]` to a caller and then reset and refilled `buf`, the caller's slice now reads the *new* bytes. Nothing panics and nothing warns; the caller simply sees data that belongs to someone else's work. This is exactly how a reused buffer bleeds one request's output into another's response, and it is why a function that borrows a shared buffer must copy before handing anything out (`append([]byte(nil), buf...)` or `string(buf)`, both of which copy). **2. Retention.** The array stays alive as long as *any* slice of it is reachable. Holding `buf[:8]` out of a 4 MB buffer keeps all 4 MB from being collected. **3. Secrets are not erased.** Resetting the length hides bytes from `len`-respecting code, nothing more. To actually overwrite them, zero the storage explicitly — `clear(buf[:cap(buf)])` — before reusing it. Even that is a weak guarantee: if the buffer ever grew, the abandoned older arrays still hold copies until the collector reuses that memory. ## `buf = buf[:0]` versus `buf = nil` They are opposites in intent: - `buf = buf[:0]` — keep the array, keep the capacity, reuse. Length 0, capacity unchanged. Later appends are allocation-free up to the capacity. - `buf = nil` — drop the reference. Length 0, capacity 0, the array becomes garbage, the next append allocates a fresh one. This is what you want when the buffer grew huge for one unusual item and you do not want to hold that memory. There is no third option that keeps a *smaller* part of the array: a slice's capacity always runs to the end of the array it points into, unless you cut it explicitly with the three-index form. ## When reuse is the wrong tool Reuse introduces a lifetime rule where none existed: whoever refills the buffer must know that nobody else is still reading it. In a single function that rule is trivially checkable. Across a package boundary, across a goroutine, or once the buffer is handed to something that stores it, the rule is invisible at the call site and will eventually be broken by someone who never saw it. Confine reuse to a scope where you can see both ends of it. ## What an interviewer is listening for That you describe the header rather than saying "it empties the slice"; that you volunteer that nothing is zeroed; and that you can name the aliasing failure — a caller holding a slice of a buffer you are about to refill — as the reason this idiom needs care rather than as a curiosity.