nanxiao / golang-101-hacks

A rudimentary Go tutorial.

Golang 101 hacks

This is an ongoing rudimentary Go programming language tutorial, and it will be updated non-periodically.

Project homepage

https://github.com/NanXiao/golang-101-hacks

License

MIT

golang-101-hacks's Issues

Update explanation of slices as arguments

Hello,

Thank you for sharing your knowledge with the rest of the community!

I was looking at your explanation of passing slices as function argumens (https://github.com/NanXiao/golang-101-hacks/raw/master/posts/pass-slice-as-a-function-argument.md) and found that it may be nice to expand on it a bit:

This time, the addValue function doesn't take effect on the s slice in main function. That's because it just manipulate the copy of the s, not the "real" s.

From https://golang.org/doc/effective_go.html?#slices we know that what happens here is that the value s, containing a pointer to an underlying array, is copied when passed as an argument to addValue.
In order to distinguish the two values, let's call the copy of s that exists within addValue cs.

When we use append to update cs, it just so happens that the capacity of the underlying array is exceeded. A new array is allocated, the values from the old array is copied to the new array, and the pointer in cs is updated to point to the new array.
Since our changes to cs are not reflected in s, the pointer to the underlying array in s is not updated and therefore points to the old array. This is the effect you show in your example.

If the underlying array happens to have enough capacity to accommodate the appended data, append actually does append data to the underlying array that s points to. See an example here: https://play.golang.org/p/eLQ9doxuWze

We see that s "is not aware" that more data has been added to the underlying array. If we want to read all of the data of the underlying array, we have to read beyond the length (not capacity) of the array. This is because the length is stored as a value in s, which is updated in cs during append, but, for the same reasons as with the updated pointer to the underlying array above, this change is not reflected in s.