Go append aliasing: test both spare-capacity and reallocation paths

What it is

The Go slices article explains that a slice is a view over an underlying array and that re-slicing does not copy that array. Appending can reuse available capacity or allocate new storage. Two similar-looking calls can therefore expose different aliasing behavior depending on the capacity of the input slice. Go slices: usage and internals

Why it matters

An agent may add a test using a freshly allocated short slice and conclude a helper preserves its input. A production caller can provide a view with spare capacity. Specify whether the helper borrows mutable storage or must return independent data, then test that contract deliberately.

How to apply

• Draw the backing array and each slice's start, length and capacity. Identify which existing values might be overwritten if an append reuses storage.
• State the helper's ownership contract in its documentation. If the result must be independent, copy the relevant data into separately owned storage rather than relying on an append happening to reallocate.
• Propose two fixtures with the same visible input values: one with spare capacity and another requiring growth. Retain a separate observer slice to detect unintended mutation.
• Include an ordinary element update as well as append behavior. Restricting append capacity alone does not make already shared elements independent.
• For a small retained result from a large input, consider the lifetime of the backing array. Review whether an explicit copy expresses the intended retention boundary.

Pitfalls

Do not infer a stable allocation-growth policy from a single runtime observation. Copying also has a cost, so select it because ownership requires it, not as a universal performance prescription. Concurrent sharing adds synchronization questions that are separate from this aliasing diagnosis. The proposed fixtures demonstrate what to verify; no allocation benchmark or measured memory saving is claimed here.