Passing slices by reference

I was replying to a post by /u/PedanticGeorge regarding concurrency and the passing of slices by reference vs. value only to find the post and many of his comments deleted while writing my reply.

I wanted to post my findings anyway for two reasons - to help me understand arrays and slices; and in case it's of any use to others.

If I understand things correctly, slices can be passed by value or by reference (using a pointer). The underlying arrays for those slices are always passed by reference implicitly.

This is something that caught me out recently so I've put an example together on the playground. Note that whether you pass the slice by value or by reference, the backing array is modified when calling append(). I imagine that dealing purely with slices would simplify things greatly as you are no longer concerned with the underlying array.

https://play.golang.org/p/xXyT1yYoPk

I'd be grateful for any feedback/corrections.

---

评论：

YEPHENAS:

This

func f(s []string) {}

is equivalent to
func f(ptr *string, len, cap int) {}

or
type stringSlice {
    ptr *string   // points to an element within an array of strings
    len, cap int
}
func f(s stringSlice) {}

dchapes:

passing of slices by reference vs. value

There is no passing by reference in Go, everything is passed by value. You are passing pointer values not references.
Words and terminology matter and using incorrect terminology just confuses things.

goomba_gibbon:

I get that *int and int are distinct types in Go. How is passing a pointer not a reference? Is this only a semantic difference or something more?

snowzach:

Yah, passing a pointer to something is passing by reference. Slices in go are inherently references though so you don't pass a pointer to a slice, you just pass the slice and it's like you passed a reference to it.

softwaregav:

Slices in go are inherently references to the underlying array, not themselves. If you want to pass a slice by reference, you still have to pass a pointer to it.

goomba_gibbon:

I think this is only partially true. If you pass a slice to a function and alter that slice (by setting slice[0] = something) then the underlying array is also modified. That means you don't need to pass a pointer in that case.
/u/ChristophBerger demonstrates this behaviour here - https://play.golang.org/p/Gs3KRf47v8

softwaregav:

Slices in go are inherently references to the underlying array, not themselves.

So, if you copy a slice, you still have a pointer to the same underlying array. Because of this, there doesn't really seem to be much of an advantage to passing the pointer of a slice, but I believe the difference is still there.

goomba_gibbon:

Thanks for the response.

Slices in go are inherently references though so you don't pass a pointer to a slice, you just pass the slice and it's like you passed a reference to it.

Is this true? You can't modify the original slice in a function without passing a pointer to it, can you? See the first two parts of the playground example.

FUZxxl:

You can easily understand slice if you know that a slice is just a structure containg a pointer to some memory, a length and a capacity. Passing a slice makes a copy of that structure, but the pointer still refers to the same chunk of memory.

ChristophBerger:

You can't modify the original slice in a function without passing a pointer to it, can you?

You can modify the contents of a slice passed by value. See this modified playground code. I added two functions, sliceByVal2 and sliceByRef2, that modify the original slice.
The point is, the slice header is a struct that contains a pointer to the slice content and the length of the slice. The header is passed by value (as everything in Go), but the pointer within the header still points to the original slice. That's why sliceByVal2() can modify the original slice.
append() returns a new slice if the original slice has not enough capacity for appending more values. In this case, append() modifies the slice header that is just a local copy of the original slice header and is discarded when the function call returns. This is why the original sliceByVal() left the original slice untouched.

goomba_gibbon:

This is a great explanation. Thank you.

0xjnml:

A reference cannot be dereferenced. A pointer can.

goomba_gibbon:

Thanks. I still think a pointer is a reference but it's good to be explicit to avoid confusion.

itsmontoya:

Passing a pointer and passing by reference is the same thing. Don't get caught up arguing over semantics