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: 

Additionally, the language spec has this: 

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 

Reply via email to