A side effect is an observable change or interaction caused by evaluating or executing code beyond producing its direct return value. In Go, slicing can expose this mistake: a slice carries length and capacity while sharing a backing array with other slices. section 3.9
Appending through a subslice changes the original
Given s1 := []int{1, 2, 3}, s2 := s1[1:2], and s3 := append(s2, 10), s2 has spare capacity. append writes 10 into the shared backing array, producing s1=[1 2 10], s2=[2], and s3=[2 10]. The apparent update to s3 therefore changes s1 without assigning to s1 directly. section 3.9
The same hazard appears across function boundaries. Passing s[:2] limits the visible length, not necessarily the capacity; a function that appends can overwrite the third element of the caller’s slice. section 3.9
Choose a protection strategy according to the ownership and readability requirements:
- Pass a copy when the function must not affect the original backing array; reconstruct the result afterward. This is safer but adds code and can reduce readability. section 3.9
- Pass a full slice expression such as s[:2:2] when the function should see only two elements and any append should allocate separately. section 3.9
- Treat package initialization as another deliberate side-effect mechanism: importing a package with _ runs its init functions even without a direct public-function dependency. section 2.3.1
