Value and Pointer Semantics

Output:

customer: Ana
first quantity: 5
number of items: 1
Copy

The three results have three different causes:

1. The customer is unchanged because the string field belongs to the copy.
2. The quantity did change because o.Items[0] refers to the array that both headers point to.
3. The number of items is unchanged because append returned a new header, and only the Items field of the copy received it.

A struct copy is shallow. It duplicates the fields themselves, but it does not duplicate anything those fields point to. This result surprises many engineers: a function that takes Order by value can still change the caller's items. If a function must change its items without affecting the caller, it has to copy them first with slices.Clone.

Choosing a Receiver Kind

A method receiver follows the same rules as a parameter. A value receiver gets a copy of the value, and a pointer receiver gets its address. The Go FAQ lists three considerations, in this order:

• Does the method need to change the receiver? If so, use a pointer receiver.
• Is the value large? If so, a pointer receiver may be cheaper.
• Do other methods of the type have pointer receivers? If so, use a pointer receiver here as well, so that the type has one kind throughout.

A struct that must not be copied, such as one that contains a lock (sync.Mutex), also needs a pointer receiver. A value receiver is a good fit for a small type that behaves like a single value. An example is time.Time, whose Add method returns a new time rather than changing the old one.

Keeping one kind per type matters because the two kinds differ in the method set (the list of methods a type has for the purpose of implementing an interface). Methods with pointer receivers belong to *Order but not to Order, so the code below does not compile.

type Payable interface {
	MarkPaid()
}

func (o *Order) MarkPaid() { o.Paid = true }

var p Payable = Order{ID: 1001}
Copy

./main.go:14:17: cannot use Order{…} (value of struct type Order) as Payable value in variable declaration: Order does not implement Payable (method MarkPaid has pointer receiver)
Copy

A mix of kinds on one type means that some methods are in the method set of Order while others are only in the method set of *Order. It also means that some methods work on a copy while others work on the shared value. The reader then has to check each method to find out which.

Pointer Speed

Many engineers pass pointers everywhere because they expect that avoiding a copy saves time. The program below answers two separate questions about an Order, which is 56 bytes on amd64: what passing it costs, and what returning it costs. A 4 KB array is included for comparison. The //go:noinline comments keep each call in place, so that the program measures the calls themselves.

One possible output (measured on one machine):

pass value       2.5 ns per call
pass pointer     2.1 ns per call
pass 4 KB value  50.4 ns per call
return value     3.8 ns per call
return pointer   17.4 ns per call
Copy

Passing a 56-byte struct by value costs less than a nanosecond more than passing a pointer on this machine. Returning a pointer costs several times more than returning a value. The Order must then be placed in memory that outlives the call (an allocation), and the garbage collector (the part of the runtime that frees unused memory) must later find it and free it.

"Pointers are faster" is often false. A pointer avoids a copy, but it can force an allocation, and an allocation usually costs more than copying a few dozen bytes. The 4 KB line shows the opposite case. A copy does become expensive once the value is large enough, so size is a fair reason to choose a pointer. Choose by meaning first, and change that choice only where a measurement shows a real cost.

Types That Behave Like References

Slices and maps are often described as reference types, and that description is only partly true. A map value is one pointer to a runtime structure, and a slice value is a header that holds a pointer. Both are still copied when passed, and the program below shows what that copy can and cannot do.

Output:

map[A-100:5]
[1250 799]
map bytes: 8  slice bytes: 24
Copy

A function can change what the map or the slice elements contain, and the caller sees that change. A function cannot change the caller's variable, so assigning a new map, or a slice with a new length, has no effect outside the function. To change the caller's slice, a function returns the new slice or takes a pointer to it. The append function itself follows the first of these patterns.

Using This in an Interview

Say that Go always passes by copying. A pointer or slice has a small value to copy, and that value still refers to shared data. Use a pointer receiver when a method changes the value or the value must not be copied, and keep one receiver kind per type. A likely follow-up asks why a function that takes a struct by value can still change the caller's data. The struct may contain a slice, map, or pointer, and the copy refers to the same underlying data.

Key Takeaways

• Go passes every argument by copying it; a pointer parameter copies an address, so both sides share one value.
• A struct copy is shallow, so a copied Order still shares its array of items with the original.
• Use a pointer receiver when a method changes the value or the value must not be copied, and keep one receiver kind per type.
• Passing a pointer saves little for a small struct, and returning one can force an allocation that costs far more than a copy.
• Slices and maps share their contents when copied, but a function still cannot change the caller's variable.

Every assignment and every call in Go makes a copy, and the only question is what that copy contains. A copy that contains the data gives each holder its own value. A copy that contains an address gives all holders one shared value. Once you can name which of the two a type gives you, you can predict what each function is able to change.