Method receivers in Go: the copy you cannot see, and the "pointer is faster" that is wrong

What is really being asked

The ladder is almost always this one:

1. "How does a value receiver differ from a pointer receiver?" — testing whether you say "a copy" or stop at the word "mutates".
2. "Why did my method change nothing?" (with code) — that same copy.
3. "Why does the type not implement the interface?" — about method sets.
4. "Does Go take the address itself? Always?" — about addressability; here most people answer "always", and that is wrong.
5. "What do you pick by default and why?" — testing whether you name consistency of the method set rather than "a pointer, it is faster".
6. "How much faster?" — a question about honesty: without a number both extremes are equally bad.

The lesson climbs that ladder, and it climbs in one direction: semantics first — does the method change state, and what follows from that for method sets and interfaces — and only then cost. Its spine is one sentence: a receiver is an ordinary argument, and arguments are copied.

Base: the one question the choice starts from

A method in Go is a function tied to a type: c.Inc() calls Inc "on" the value c. That value is called the receiver, and it is declared to the left of the method's name: func (c Counter) Inc().

The whole topic rests on one distinction, and it is a semantic one. A method with a value receiver works on a copy: whatever it changes there is invisible outside. A method with a pointer receiver gets an address and can change the original value.

So the choice of receiver is decided not by the size of the struct and not by team habit, but by one question about what the method means:

Does the method work with a copy of the value — or must it change the original state?

If it changes it, the receiver must be a pointer; there is no alternative. If it does not, the other considerations follow below: method sets, the decision tree and, last of all, the price of the copy.

Why the question is that one becomes clear if you read the declaration as an ordinary function:

func (c Counter) IncValue()   { c.n++ }
func (c *Counter) IncPointer() { c.n++ }

Those are IncValue(c Counter) and IncPointer(c *Counter). The difference is exactly the one between any two functions with those signatures — there is no magic in a receiver.

Two conclusions follow at once:

• A value receiver gets a copy. Incrementing a field of the copy is allowed and pointless: the copy dies when the method returns.
• A pointer receiver gets an address. One word is copied, and it leads to the original.

The trap is that the call looks identical: c.IncValue() and c.IncPointer() are written exactly the same way. The difference is visible only in the method declaration — elsewhere in the file, often in another file.

The second half of that sentence is the source of both bugs in this lesson: "the method changed nothing" and "the type does not implement the interface".

That is already enough to answer the basic interview question: the difference between receivers is the difference between working on a copy and working on the original. Everything below is about what follows from it for interfaces, where the compiler supplies an address for you, where a copy appears unnoticed, and what it costs.

Mechanism 1: a method set is not a matter of style

The method sets of T and *T are different, and the difference is visible without a compiler — through reflect:

String is declared with a pointer receiver and did not make it into the value's method set. The interface check says the same:

The reason is not syntactic, and it is worth being able to state: a value in an interface is a copy, and it has no address. A method with a pointer receiver could not change the original; silently changing a copy would be worse than a build error. The other direction is allowed: a pointer has an address, and dereferencing it for a value method is always possible.

The specification puts it in one sentence:

Mechanism 2: the compiler takes the address — but not everywhere

Here is where nearly everyone answers "Go will take the address itself", which is only half right.

First, what it is not. Taking the address automatically is syntactic convenience, not a change to the method set. The set of T stays what it was: the compiler merely writes & where it is allowed to. Which is precisely why assigning a value to an interface, from the previous section, is not rescued by the same mechanism — there is no longer a variable whose address could be taken.

The condition is spelled out in the specification:

The key word is addressable. What is addressable and what is not is worth holding as a list:

A variable has an address, so c.IncPointer() works. A map element has none — the table is rebuilt on growth — and

m := map[string]Counter{"k": {}}
m["k"].IncPointer()   // does not compile

will not build at all: cannot call pointer method on m["k"]. The way around it is map[string]*Counter: the pointer moves, the object stays put.

And that is, oddly, the good news. Where there is no address the compiler refuses to build and the error is immediate. The dangerous case is where an address does exist: there the compiler quietly takes the address of a copy — and that is the next section.

Mechanism 3: three places where a copy appears unnoticed

All three are common "find the bug" questions, and none is caught by the compiler. The numbers below were printed by a run of bench/gorecv/internals.go.

First — range over a slice of values. The loop variable is a copy of the element:

for _, v := range items {
    v.Add()        // changes the copy; the slice stays put
}
for i := range items {
    items[i].Add() // changes the element
}

The run gives 0 in the first case and 1 in the second. This is the most common of the three, because for _, v := range is written without thinking.

Second — assigning a struct. cp := src copies it whole, and from then on they are two independent objects: after cp.Add() the run shows src=5 cp=6.

Third — keeping values where pointers are needed. map[string]Acc will not let a pointer method be called at all; []Acc will, but through an index rather than through the loop variable.

What all three share: the call looks the same. The compiler takes the address when the variable is addressable, and says nothing; when there is no address, it refuses to build. The bug lives between those two cases.

Mechanism 4: the decision tree

The rule for choosing is not about speed. The questions are asked in order, and the first "yes" settles it:

The top three questions are about correctness, and only the fourth about cost. The same questions in words:

1. Does the method mutate the receiver? Then a pointer — otherwise it mutates a copy. That is not a recommendation but the only working option.
2. Does the type contain something that must not be copied? sync.Mutex, sync.WaitGroup, strings.Builder — a copy of such a type breaks silently, and go vet catches it with a dedicated copylocks check.
3. Do some methods already have pointer receivers? Then give the rest pointer receivers too: otherwise the method set depends on what exactly was assigned.

Only if none of the three questions settled it does size remain. Good candidates for a value receiver are small immutable types: time.Time, your own wrappers over a number or a string. There a copy is a feature rather than a cost.

Deeper: "a pointer is faster" is a function of size, not a rule

Here are the numbers worth switching the tab above for. The same method — reading two fields — over structs of different sizes:

This table should be read bottom-up. At the bottom is what people ask about: a copy costs money, and at a kilobyte the call is nearly ten times dearer. At the top is what people forget: at one or two words there is no difference at all — there is nothing to copy, the value lives in registers anyway.

So the answer "a pointer receiver is faster" is wrong as a rule. But the opposite rule — "take the value, a copy is cheap" — is wrong in exactly the same way: the bottom row of the table refutes it.

What is right is a third thing, and it is not a rule but a dependency: the copy is what costs, and its price grows with the size. The method body is the same throughout — the same two fields are read. The ratios themselves belong to this run on this machine: elsewhere they will come out different, while the direction of the series will not.

And size is only one of the factors, and the least important at that. A pointer makes the value escape to the heap more often (see the escape-analysis lesson), while a value gives the compiler more freedom. Which wins in a given function is measured with a profile, not derived from a table.

Note the word "large" — and note that in the FAQ this caveat comes after the rules about mutation and consistency, not instead of them.

How to answer in an interview

Short answer: a method with a value receiver works on a copy, while a method with a pointer receiver can change the original value. A receiver is the method's first argument written on the left, and arguments are copied; hence both "the method changed nothing" and "the type does not implement the interface".

That is enough for a correct answer. What follows is what you add when the interviewer digs.

If the interviewer digs deeper

To "what is the difference" answer "a receiver is the first argument". "A value is copied, a pointer is not; everything else follows." The answer shows straight away that you did not memorise two rules but understand one.

On "the method changed nothing" name the place, not the rule. "Most likely for _, v := range: the loop variable is a copy, and the pointer method changed it." This reads as experience immediately.

On the interface, talk about the address. "A copy in an interface has no address, so a method with a pointer receiver is not in the value's method set." "You have to pass a pointer" is true but explains nothing.

On automatic address-taking, add the caveat. "It does, if the expression is addressable; a map element has no address, and there it does not compile." Half of candidates answer "always".

On speed, give a range rather than an extreme. "The difference is the price of the copy: up to eight words there is none at all, at a kilobyte I got ten times." One number without the other turns a right measurement into a wrong rule.

On the default, name consistency. "If even one method needs a pointer, all of them get pointers, so the method set does not depend on what was assigned."

Next they ask

Common misconceptions

Practice

Two problems. Answer first, then check against the real output: in both, the correct answer is taken from a run of the script rather than assigned.

func (c Counter) IncValue() { c.n++ }

func (c *Counter) IncPointer() { c.n++ }

c := Counter{}
c.IncValue()
c.IncPointer()
fmt.Println(c.n)

cs := []Counter{{}, {}}
for _, v := range cs {
	v.IncPointer()
}
fmt.Println(cs[0].n)

for i := range cs {
	cs[i].IncPointer()
}
fmt.Println(cs[0].n)

p := &Counter{}
p.IncValue()
fmt.Println(p.n)

1
0
1
0

2
1
2
1

1
1
1
1

2
0
1
0

Knowledge check