When you append to a slice in Go, the result may share the same underlying array as the original slice if the capacity of the original is sufficient to accommodate the new elements. This happens because append returns a slice header (pointer, length, capacity) that may point to the same backing array. If the length of the original slice is less than its capacity, and you reslice or append within that capacity, changes to the new slice's elements are visible in the original slice since they reference identical memory addresses.
buffer := make([]int, 3, 5) // [0 0 0], len=3, cap=5 buffer[0] = 10 newSlice := append(buffer, 42) // Still shares backing array newSlice[0] = 99 // buffer[0] is now 99, not 10
This aliasing behavior stems from Go's slice implementation using a contiguous array with a pointer header, optimizing for memory efficiency at the cost of potential side effects when developers assume value semantics.
Imagine a high-frequency trading platform processing batches of market orders. A function extracts the last five unprocessed orders from a rolling buffer slice containing the last hundred orders, then appends a new synthetic order to prepare a final submission batch. The developer assumes the new batch is independent, but upon modifying the price field of the synthetic order in the submission batch, the corresponding order in the rolling buffer mysteriously updates, causing duplicate order detection logic to trigger false alarms and reject valid trades.
Several solutions were considered to isolate the data. The first approach involved using copy to create a defensive clone of the data before appending, which guarantees independence from the backing array but incurs an O(n) memory allocation and copy cost that becomes prohibitive when processing thousands of batches per second. The second approach suggested always allocating a new slice with make of exact length zero and capacity equal to the needed size, then copying only the required elements; this prevents aliasing but requires careful capacity management and wastes memory if the batch sizes vary unpredictably. The third approach utilized a custom arena allocator with manual memory management to ensure contiguous placement without Go's slice semantics; however, this introduced unsafe pointer operations and violated the project's safety requirements, making it unsuitable for production financial code.
The team chose the first solution using copy for critical submission batches while implementing a sync.Pool for the backing arrays to mitigate allocation overhead. This approach ensured data isolation without compromising type safety.
After deployment, the false alarm rate dropped to zero, and CPU profiling showed only a 3% increase in allocation throughput, which was acceptable given the correctness guarantees achieved.
Why does checking len(slice) == cap(slice) before append not guarantee that append returns an independent copy?
Even when length equals capacity, append may reallocate if the current backing array is full, but the critical misunderstanding lies in assuming independence only requires checking this condition. Candidates miss that slices derived from other slices via reslicing (e.g., s[:0]) retain the original capacity unless explicitly limited. The runtime only allocates new memory when the append exceeds the available capacity, but "available capacity" includes any unused slots in the original backing array that the slice header still references. To guarantee independence, one must either copy to a new slice with exact capacity or use three-index slicing s[low:high:max] to restrict capacity before appending.
How does three-index slicing prevent append aliasing, and what are its performance implications?
Three-index slicing s[i:j:k] sets both the length (j-i) and capacity (k-i) of the resulting slice, effectively capping the visible portion of the backing array. When you subsequently append to this restricted slice, any growth immediately triggers a reallocation because the capacity constraint prevents overwriting data beyond index k-1. This technique avoids memory allocation during the slicing operation itself—unlike copy—but candidates often fail to recognize that it still references the same backing array until an append occurs. If the original slice is large and the subset is small, this approach saves memory by avoiding duplication, though it risks holding references to the entire backing array and delaying GC of unused elements.
Under what specific condition does passing a slice to a function and appending within that function fail to reflect changes in the caller's original slice variable despite modifying the underlying array?
This occurs because Go passes slices by value, copying the slice header (pointer, length, capacity) but not the backing array. If the function appends and the slice header is updated (new pointer due to reallocation or increased length), the caller's header remains unchanged. Candidates miss that while modifications to existing elements mutate shared memory, the length and pointer updates are local to the function's copy of the header. To propagate append results back, one must return the new slice or pass a pointer to the slice (*[]T), forcing the caller to reassign the result: slice = append(slice, val) works because the caller reassigns the return value, but func mutate(s []int) { s = append(s, 1) } silently discards the reallocation unless s is returned.