> Go forces writing loop for removing an element from an array
It does not:
copy(a[i:], a[i+1:]) // Shift a[i+1:] left one index.
a[len(a)-1] = "" // Erase last element (write zero value).
a = a[:len(a)-1]
It does not:
copy(a[i:], a[i+1:]) // Shift a[i+1:] left one index.
a[len(a)-1] = "" // Erase last element (write zero value).
a = a[:len(a)-1]
list = append(list[:i], list[i+1:]...)
See this playground for an illustration: https://play.golang.org/p/mOpuGVj2ypG
That uses append to delete, and then modifies element 0 in the result. In the first call, only the new slice is modified. But in the second call, both slices are modified, since they share the same backing array.
I consider this to be one of the worst mistakes of Go, to design a highly multithreaded language in which variable aliasing is a dynamic property. I am convinced that many Go programs have latent races and bugs, invisible to the race detector, and they have not yet been tripped because they have been (un)lucky with the runtime's capacity decisions.
Edit: I didn't do my test quite right. It's not really special-cased. But it's still very surprising to see this happen:
Code:
s1 := []int{1, 2, 3, 10, 11, 12}
s2 := []int{4, 5, 6}
s3 := s1[:2]
s4 := append(s3[:2], s2...)
fmt.Println(s1)
fmt.Println(s4)
[1 2 4 5 6 12]
[1 2 4 5 6]It may or may not copy.
Simple! But not easy. Go is absolutely filled with nuggets like this in my experience. False-simplicity is deeply ingrained in the standard library as well: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...