4 ms·

This is absolutely one of the worst aspects of Go. When you call append() on a slice, and then modify the contents of the result, you may or may not modify the

This is absolutely one of the worst aspects of Go. When you call append() on a slice, and then modify the contents of the result, you may or may not modify the original slice. In a language that encourages concurrency, this indeterminism should be jaw-dropping. How many Go programs are safe only accidentally via an array's allocation policy (especially given how much code it requires to duplicate a slice)? Can you think of any other language that has such a design?

kodablah 8y ago
It's not indeterminate, just conditional at runtime, no different than any other may-mutate-parameter-reference function. It fits Go's philosophy of foot guns for the sake of performance/simplicity (be it compiler or runtime performance/simplicity). Use of append by devs should invalidate any future uses of the parameter, but this is better than forcing a copy or abstracting implementation details of linked arrays. > Can you think of any other language that has such a design? Sure, happens all the time because it fits the machine naturally though sometimes it may be hidden with unnecessary runtime costs by many languages that do force copies or reallocations due to immutability. C++ is a language that doesn't hide it. Your argument is like saying you're surprised that std::vector::emplace_back may or may not alter the array I had kept from std::vector::data previously.