By Zef Hemel

2014-05-08 13:21:41 8 Comments

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?

Similarly, the same question regarding slices:

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

func myfunc() []*MyStruct {
    return []MyStruct{ &MyStruct{Val: 1} }

func myfunc(s *[]MyStruct) {
    *s = []MyStruct{ MyStruct{Val: 1} }

func myfunc(s *[]*MyStruct) {
    *s = []MyStruct{ &MyStruct{Val: 1} }

Again: what are best practices here. I know slices are always pointers, so returning a pointer to a slice isn't useful. However, should I return a slice of struct values, a slice of pointers to structs, should I pass in a pointer to a slice as argument (a pattern used in the Go App Engine API)?


@nobar 2019-08-13 22:48:29

A case where you generally need to return a pointer is when constructing an instance of some stateful or shareable resource. This is often done by functions prefixed with New.

Because they represent a specific instance of something and they may need to coordinate some activity, it doesn't make a lot of sense to generate duplicated/copied structures representing the same resource -- so the returned pointer acts as the handle to the resource itself.

Some examples:

In other cases, pointers are returned just because the structure may be too large to copy by default:

Alternatively, returning pointers directly could be avoided by instead returning a copy of a structure that contains the pointer internally, but maybe this isn't considered idiomatic:

@Santosh Pillai 2018-09-01 17:30:59

Three main reasons when you would want to use method receivers as pointers:

  1. "First, and most important, does the method need to modify the receiver? If it does, the receiver must be a pointer."

  2. "Second is the consideration of efficiency. If the receiver is large, a big struct for instance, it will be much cheaper to use a pointer receiver."

  3. "Next is consistency. If some of the methods of the type must have pointer receivers, the rest should too, so the method set is consistent regardless of how the type is used"

Reference :

Edit : Another important thing is to know the actual "type" that you are sending to function. The type can either be a 'value type' or 'reference type'.

Even as slices and maps acts as references, we might want to pass them as pointers in scenarios like changing the length of the slice in the function.

@zlotnika 2018-11-17 18:36:24

For 2, what's the cutoff? How do I know if my struct is big or small? Also, is there a struct that's small enough such that it's more efficient to use a value rather than pointer (so that it doesn't have to be referenced from the heap)?

@Santosh Pillai 2019-08-08 11:19:35

I would say the more the number of fields and/or nested structs inside, the bigger the struct is. I'm not sure if there is specific cutoff or standard way to know when a struct can be called "big" or "large". If I'm using or creating a struct, I would know if its big or small based on what I said above. But that's just me!.

@twotwotwo 2014-05-08 20:34:08


  • 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.

One case where you should often use a pointer:

  • Receivers are pointers more often than other arguments. It's not unusual for methods to modify the thing they're called on, or for named types to be large structs, so the guidance is to default to pointers except in rare cases.
    • Jeff Hodges' copyfighter tool automatically searches for non-tiny receivers passed by value.

Some situations where you don't need pointers:

  • Code review guidelines suggest passing small structs like type 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.

    • Value semantics avoid aliasing situations where an assignment over here changes a value over there by surprise.
    • It's not Go-y to sacrifice clean semantics for a little speed, and sometimes passing small structs by value is actually more efficient, because it avoids cache misses or heap allocations.
    • So, Go Wiki's code review comments page suggests passing by value when structs are small and likely to stay that way.
    • If the "large" cutoff seems vague, it is; arguably many structs are in a range where either a pointer or a value is OK. As a lower bound, the code review comments suggest slices (three machine words) are reasonable to use as value receivers. As something nearer an upper bound, bytes.Replace takes 10 words' worth of args (three slices and an int).
  • For slices, you don't need to pass a pointer to change elements of the array. io.Reader.Read(p []byte) changes the bytes of p, for instance. It's arguably a special case of "treat little structs like values," since internally you're passing around a little structure called a slice header (see Russ Cox (rsc)'s explanation). Similarly, you don't need a pointer to modify a map or communicate on a channel.

  • For slices you'll reslice (change the start/length/capacity of), built-in functions like append accept 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.

    • It's not always practical follow that pattern. Some tools like database interfaces or serializers need to append to a slice whose type isn't known at compile time. They sometimes accept a pointer to a slice in an interface{} parameter.
  • 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. (rsc wrote a separate post on how interface values are stored).

    • You still may need to pass pointers in the rarer case that you want to modify the caller's struct: flag.StringVar takes a *string for that reason, for example.

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)).

  • You mention accepting a pointer to avoid allocations by allowing reuse; changing APIs for the sake of memory reuse is an optimization I'd delay until it's clear the allocations have a nontrivial cost, and then I'd look for a way that doesn't force the trickier API on all users:

    1. For avoiding allocations, Go's escape analysis is your friend. You can sometimes help it avoid heap allocations by making types that can be initialized with a trivial constructor, a plain literal, or a useful zero value like bytes.Buffer.
    2. Consider a Reset() method to put an object back in a blank state, like some stdlib types offer. Users who don't care or can't save an allocation don't have to call it.
    3. Consider writing modify-in-place methods and create-from-scratch functions as matching pairs, for convenience: existingUser.LoadFromJSON(json []byte) error could be wrapped by NewUserFromJSON(json []byte) (*User, error). Again, it pushes the choice between laziness and pinching allocations to the individual caller.
    4. Callers seeking to recycle memory can let sync.Pool handle some details. If a particular allocation creates a lot of memory pressure, you're confident you know when the alloc is no longer used, and you don't have a better optimization available, sync.Pool can help. (CloudFlare published a useful (pre-sync.Pool) blog post about recycling.)
    5. Curiously, for complicated constructors, new(Foo).Reset() can sometimes avoid an allocation when NewFoo() would not. Not idiomatic; careful trying that one at home.

Finally, on whether your slices should be of pointers: slices of values can be useful, and save you allocations and cache misses. There can be blockers:

  • The API to create your items might force pointers on you, e.g. you have to call NewFoo() *Foo rather than let Go initialize with the zero value.
  • The desired lifetimes of the items might not all be the same. The whole slice is freed at once; if 99% of the items are no longer useful but you have pointers to the other 1%, all of the array remains allocated.
  • Moving items around might cause you problems. Notably, append copies items when it grows the underlying array. Pointers you got before the append point to the wrong place after, copying can be slower for huge structs, and for e.g. sync.Mutex copying isn't allowed. Insert/delete in the middle and sorting similarly move items around.

Broadly, value slices can make sense if either you get all of your items in place up front and don't move them (e.g., no more appends after initial setup), or if you do keep moving them around but you're sure that's OK (no/careful use of pointers to items, items are small enough to copy efficiently, etc.). Sometimes you have to think about or measure the specifics of your situation, but that's a rough guide.

@The user with no hat 2015-03-20 21:38:55

What means big structs? Is there an example of a big struct and a small struct?

@Tim Wu 2015-06-12 03:50:10

How do you tell bytes.Replace takes 80 bytes' worth of args on amd64 ?

@twotwotwo 2015-06-12 17:32:56

The signature is Replace(s, old, new []byte, n int) []byte; s, old, and new are three words each (slice headers are (ptr, len, cap)) and n int is one word, so 10 words, which at eight bytes/word is 80 bytes.

@Andy Aldo 2017-11-13 04:14:15

How do you define big structs? How big is big?

@twotwotwo 2017-11-13 21:09:59

@AndyAldo None of my sources (code review comments, etc.) define a threshold, so I decided to say it's a judgment call instead of making a threshold up. Three words (like a slice) is pretty consistently treated as eligible to be a value in the stdlib. I found an instance of a five-word value receiver just now (text/scanner.Position) but I wouldn't read much into that (it's also passed as a pointer!). Absent benchmarks, etc., I'd just do whatever seems most convenient for readability.

@nijm 2018-07-24 08:39:34

From the first link in this answer: If the receiver is a large struct or array, a pointer receiver is more efficient. How large is large? Assume it's equivalent to passing all its elements as arguments to the method. If that feels too large, it's also too large for the receiver.

Related Questions

Sponsored Content

5 Answered Questions

36 Answered Questions

21 Answered Questions

[SOLVED] Why should I use a pointer rather than the object itself?

  • 2014-03-03 11:54:16
  • gEdringer
  • 288931 View
  • 1497 Score
  • 21 Answer
  • Tags:   c++ pointers c++11

13 Answered Questions

[SOLVED] What is a smart pointer and when should I use one?

5 Answered Questions

[SOLVED] When is casting void pointer needed in C?

12 Answered Questions

[SOLVED] C pointer to array/array of pointers disambiguation

1 Answered Questions

[SOLVED] Gob can't encode map with a nil pointer value

  • 2018-06-06 16:18:09
  • rampatowl
  • 255 View
  • 1 Score
  • 1 Answer
  • Tags:   pointers go gob

1 Answered Questions

1 Answered Questions

[SOLVED] Create slice of pointers using reflection in Go

  • 2015-10-27 16:31:31
  • i0n
  • 443 View
  • 1 Score
  • 1 Answer
  • Tags:   reflection go

2 Answered Questions

[SOLVED] How to remove an item from a slice by calling a method on the slice

  • 2013-09-02 05:58:27
  • user2736464
  • 14415 View
  • 10 Score
  • 2 Answer
  • Tags:   go slice

Sponsored Content