Pass by pointers vs. values and return values in golang. What are the best practices?

Question

In Go there are various ways to return a struct value or slice thereof. For individual ones I've seen:
type MyStruct struct {
    Val int
}

func myfunc() MyStruct {
    return MyStruct{Val: 1}
}

func myfunc() *MyStruct {
    return &MyStruct{}
}

func myfunc(s *MyStruct) {
    s.Val = 1
}

I understand the differences between these. The first returns a copy of  the struct, the second a pointer to the struct value created within the  function, the third expects an existing struct to be passed in and  overrides the value.

I've seen all of these patterns be used in various contexts, I'm  wondering what the best practices are regarding these. 

When would you  use which? For instance, the first one could be ok for small structs  (because the overhead is minimal), the second for bigger ones. And the  third if you want to be extremely memory efficient, because you can  easily reuse a single struct instance between calls. Are there any best  practices for when to use which?

Gufran Mirza · Accepted Answer

Predetermined choice A choice is sometimes predetermined by usage context. Let’s have a look at the most common use cases. Variable must not be modified We do not have other option, but pass variable by value. So that variable cannot be modified downstream. And vice versa, if variable is expected to be modified, it must be passed by pointer. Variable is a large struct If variable is a large struct and performance is an issue, it’s preferable to pass variable by pointer. So that to avoid expensive copying of the whole struct in memory. Variable is a map or slice Maps and slices are reference types in Go and should be passed by values. Passing by value often is cheaper Even though Go looks a bit like C, its compiler works differently. And C analogy does not always work with Go. Passing by value in Go may be significantly cheaper than passing by pointer. This happens because Go uses escape analysis to determine if variable can be safely allocated on function’s stack frame, which could be much cheaper then allocating variable on the heap. Passing by value simplifies escape analysis in Go and gives variable a better chance to be allocated on the stack. Bottom line Sometimes the choice of how to pass variable is predetermined by variable type or its usage. Otherwise, it’s highly recommended to pass variables by value. Also it is very important to be consistent with your choice, so that not to confuse yourself and your teammates. Read this post for more details

Sumit Sharma · Answer

tl;dr: Methods using receiver pointers are common; the rule of thumb for receivers is, "If in doubt, use a pointer." Slices, maps, channels, strings, function values, and interface values are implemented with pointers internally, and a pointer to them is often redundant. Elsewhere, use pointers for big structs or structs you'll have to change, and otherwise pass values, because getting things changed by surprise via a pointer is confusing. Some situations where you don't need pointers: Code review guidelines suggest passingsmall structsliketype Point struct { latitude, longitude float64 }, and maybe even things a bit bigger, as values, unless the function you're calling needs to be able to modify them in place. For slices, you don't need to pass a pointer to change elements of the array.io.Reader.Read(p []byte)changes the bytes ofp, for instance. It's arguably a special case of "treat little structs like values," since internally you're passing around a little structure called aslice header(seeRuss Cox (rsc)'s explanation). Similarly, you don't need a pointer tomodify a map or communicate on a channel. For slices you'll reslice(change the start/length/capacity of), built-in functions likeappendaccept a slice value and return a new one. I'd imitate that; it avoids aliasing, returning a new slice helps call attention to the fact that a new array might be allocated, and it's familiar to callers. Maps, channels, strings, and function and interface values, like slices, are internally references or structures that contain references already, so if you're just trying to avoid getting the underlying data copied, you don't need to pass pointers to them. (rscwrote a separate post on how interface values are stored). Where you use pointers: Consider whether your function should be a method on whichever struct you need a pointer to. People expect a lot of methods on x to modify x, so making the modified struct the receiver may help to minimize surprise. There are guidelines on when receivers should be pointers. Functions that have effects on their non-receiver params should make that clear in the godoc, or better yet, the godoc and the name (like reader.WriteTo(writer)).

Go Language

Similar Discussions

Golang serving static files, please explain what is happening in these 3 lines of code

Is type casting a costly operation in Golang?

Go modules and Google cloud, having trouble in renning code!

On a mission to build Next-Gen Community Platform for Developers

Facebook

Twitter

Linkedin

Instagram