append, copy, and Slice Aliasing

A batch worker processes events in chunks of two. The first version looks unremarkable:

events := []string{"a", "b", "c", "d", "e"}

for i := 0; i < len(events); i += 2 {
	end := i + 2
	if end > len(events) {
		end = len(events)
	}
	chunk := events[i:end]
	chunk = append(chunk, "tagged") // mark the batch
	fmt.Println(chunk)
}

Output begins [a b tagged] — and on the next iteration, events no longer reads [a b c d e]. chunk is a header over events' own storage. Its length is 2 with capacity reaching to the end of the array, so append does not allocate: it writes the new element into events[2], clobbering "c". Aliasing means the write went through two names to one memory location.

Whether an append collides depends purely on available capacity:

a := []int{1, 2, 3, 4, 5}
b := a[:2]          // len 2, cap 5
b = append(b, 99)    // fits in cap: writes a[2]
fmt.Println(a)       // [1 2 99 4 5] — parent corrupted

c := a[2:4:4]        // len 2, cap 2 — sealed
c = append(c, 77)    // must allocate; a untouched
fmt.Println(a)       // [1 2 99 4 5]

Three defenses, in order of preference:

1. Seal with the full slice expression — s[i:j:j] makes the child's capacity equal its length, so any append allocates instead of writing back into the parent (Slice Basics and the Slice Header).
2. Clone at the boundary — when a function receives a sub-slice and must not disturb the original, copy elements into fresh storage before mutating.
3. Never mutate a slice you do not own — if the batch chunk is read-only input, tag a parallel []string of labels instead of writing into the input.

The bug class extends to structs: a struct field holding a slice shares its backing array with every copy of that struct. Passing Events{buf: events} around and appending to e.buf in one copy can affect another. Aliasing is not a slice defect — shared storage is the design — but every write to a slice element needs an answer to "who else can see this array?"

An append has two possible fates, and the header tells you which:

s := make([]int, 0, 4)
s = append(s, 1) // len 1 cap 4 — write in place
s = append(s, 2) // len 2 cap 4 — write in place
s = append(s, 3, 4, 5) // len 5 > cap: allocate, copy 2 existing + 3 new

While len < cap, append writes into existing storage and the header's pointer never changes. The moment the sum exceeds capacity, Go allocates a new, larger array, copies everything, and returns a header pointing at the new home. The old array stays alive only for other slices still referencing it.

Two details of the growth policy are worth carrying around: for small slices the new capacity roughly doubles, so repeated single appends stay linear overall instead of quadratic; for large slices growth becomes more gradual (on the order of 25% plus slack), so a tight for loop appending one element to a multi-megabyte slice can still surprise you. When the final size is known, reserve it:

out := make([]Row, 0, len(input)) // one allocation for the whole result
for _, in := range input {
	out = append(out, Row{ID: in.ID})
}

The assignment s = append(s, x) is not ceremony. Forget it and two failures hide in plain sight: appends that fit in capacity appear to work while the variable still points at the old header, and appends that reallocate lose every element you thought you added. Any function returning a grown slice must pass the new header back — by return value, since parameters are local copies (Pointers as Function Parameters).

Two growth patterns deserve memory:

// Reserve n zero slots at the end in one call.
s = append(s, make([]int, n)...)

// Grow a byte buffer without counting capacity yourself.
buf = append(buf, payload...)

The make([]int, n)... form spreads n zeros into the append, which both extends length and — because appending n elements to a slice with fewer than n free slots allocates exactly for the final size — gives you a stable window to fill by index afterward.

append builds slices from scratch; copy moves elements between storage that already exists. Its signature rewards a careful read: copy(dst, src) returns the number of elements copied, stops at the shorter of the two lengths, and never allocates.

buf := make([]byte, 5)
n := copy(buf, "hello world") // copies 5 bytes — dst is the limit
fmt.Println(n, string(buf))   // 5 [hello]

That "shorter side wins" rule makes copy safe for overlapping regions, which is how a sliding window compacts itself:

// Keep only bytes before the first delimiter; shift the remainder down.
func trimBefore(sep byte, buf []byte) []byte {
	if i := bytes.IndexByte(buf, sep); i >= 0 {
		copy(buf, buf[i+1:]) // overlapping-safe shift
		return buf[:len(buf)-i-1]
	}
	return buf
}

When the goal is a duplicate rather than a move, the idiomatic clone spreads one slice into a fresh one:

clone := append([]int(nil), src...) // new storage, same contents

Building from nil guarantees there is no shared backing array; slices.Clone(src) (Go 1.21+) is the same idea as a stdlib call. A plain clone := src is not a clone — it copies the header, and the aliasing bugs from the first chapter come right back.

Many transforms need no second slice at all. The two-index compaction pattern overwrites a prefix of the same array:

func compact(nums []int) []int {
	n := 0 // write cursor: everything below n is kept
	for _, v := range nums {
		if v%2 == 0 {
			nums[n] = v
			n++
		}
	}
	return nums[:n]
}

Read n as the boundary between "kept" and "garbage". Filtering a million elements allocates nothing extra, and the caller receives a shorter view of the same storage — with the understanding that elements past the new length are stale. copy for moving, append([]T(nil), s...) for duplicating, compaction for in-place filtering: together they cover nearly every slice reshaping you will write.

The nastiest aliasing bugs are not written in loops — they arrive through shared ownership. Two places produce them repeatedly.

A slice field appended to under a value receiver. Methods on a value receiver get a copy of the struct, including its slice header. This compiles and quietly does nothing useful:

type Queue struct {
	items []string
}

func (q Queue) Push(v string) { // value receiver: copies the header
	q.items = append(q.items, v) // grows a local copy; caller's header unchanged
}

When capacity suffices, the element write lands in shared storage — the caller might see an element it cannot reach through its own length. When capacity is exceeded, append allocates and the caller sees nothing at all. Behavior that changes with capacity is the signature of this bug. Use a pointer receiver and treat the append's returned header as authoritative (Value Semantics and Copies).

Shared test fixtures. A package-level slice passed to every test becomes an accumulator:

var fixture = []string{"alpha", "beta"} // built once, shared by all tests

func TestProcess(t *testing.T) {
	input := fixture          // header copy, same storage
	input = append(input, "x") // if cap allowed it, later tests see "x"
	...
}

The defensive habit at boundaries: clone what you hand out, or clone what you receive when the callee might write. slices.Clone in tests costs microseconds and removes an entire category of order-dependent failures.

A quick ownership checklist for any slice write:

1. Who allocated this backing array — me, my caller, or shared state?
2. Does my view's capacity reach into storage others can read?
3. Am I reassigning the header (s = append(...)) or only writing elements?

If the answer to 2 is "others" and 3 is "elements", seal with s[i:j:j] or clone first. Carrying that checklist into Iterating Strings, Bytes, and Runes — where slicing decisions also have correctness weight, just a different kind — is the best bridge to the rest of the phase.