Unexpected Behavior with Append Operations on Slices
In Go, unexpected behavior can occur when appending elements to slices during loop iterations and then creating new slices based on the results. This behavior stems from the underlying array that slices reference.
Consider the following code:
<code class="go">func create(iterations int) []int { a := make([]int, 0) for i := 0; i < iterations; i++ { a = append(a, i) } return a }</code>
If we call create(11) and assign the result to i, we expect each subsequent append operation (j := append(i, 100), g := append(i, 101), and h := append(i, 102)) to create new slices with distinct values. However, the behavior observed is that the last element of these new slices is always 102, regardless of their index.
This happens because all the appends modify the same underlying array. Appending an element to the slice changes the length and may cause a reallocation of the array. When a new array is allocated, all previous references to the old array become invalid.
Slice literals, however, behave as expected because a new array is always allocated if the append would exceed the capacity of the backing array.
Idiomatic Approach
To ensure predictable behavior when creating multiple new slices based on an existing slice, the idiomatic approach is to copy the slice before appending elements:
<code class="go">func makeFromSlice(sl []int) []int { result := make([]int, len(sl)) copy(result, sl) return result }</code>
By performing a copy, we create a new backing array and ensure that changes made to the resulting slice do not affect the original slice.
The above is the detailed content of Why Does Appending to a Slice in a Loop Produce Unexpected Results in Go?. For more information, please follow other related articles on the PHP Chinese website!