On Jun 25, 2020, at 8:49 PM, chandrak13...@gmail.com wrote: > > Essentially based on the existing capacity, the assignment of one slice > effects other slices. These are stemming from the underlying pointer > arithmetic and seems inconsistent. Looks like programmer needs to know the > history of capacity before understanding the ramifications of slice > assignments.
You are correct, the programmer needs to read the manual. Slices are "windows" into their underlying array, therefore assigning data into slices tied to a given array changes the data in other arrays as well. The append() function merely extends the slice by n and assigns into those elements, returning the new slice header (the old one can remain unchanged, but they will both be slices of the same array). Ian pointed to the canonical documentation on this: https://blog.golang.org/slices Additionally, the language spec has this: https://golang.org/ref/spec#Appending_and_copying_slices I do agree that it would be nicer if this were flagged a little more loudly, since the semantics of the append() builtin can lead the early developer to believe they are making a copy of the slice in question, but they aren't. - Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA9014AE-527F-4D18-81A9-6E63FAD97B54%40gmail.com.
