Pointers in Go: everything is passed by value, even a pointer

What is really being asked

The ladder usually looks like this:

1. "What is a pointer and why do you need it?" — the warm-up; "the address of a variable" is correct but explains nothing.
2. "Is anything in Go passed by reference?" — the main question of the lesson. "Pointers and maps are passed by reference" is the very mistake this question is meant to catch.
3. "What happens if you assign nil to a pointer parameter inside a function?" — the same check, on code.
4. "Can you call a method on a nil pointer?" — and what panics then and what does not.
5. "Why can't you take the address of a map element, while you can for a slice element?" — about addressability and about a pointer that quietly lost its link to the slice's array.
6. "Can you return a pointer to a local variable?" — a question from C; in Go the answer is different.
7. "Does Go have pointer arithmetic?" — and what to do if you really need it.
8. "Which is faster — passing a struct by value or by pointer?" — about cost, and it has two sides.

The ladder has one spine: a pointer is an ordinary value that is copied like any other; what the copies share is only the variable they point to. Everything in this lesson that looks surprising follows from that sentence.

Base: the address of a variable and the variable at an address

The specification defines a pointer through the variable it points to:

Two operators: &x gives the address of the variable x, *p gives the variable p points to. Through *p you can both read and write. In the run x := 10 and a type with two methods.

Fragment of bench/goptr/internals.go (package-level declarations; comments translated):

type Point struct{ X, Y int }
 
func (p *Point) Move(dx int) { p.X += dx }        // pointer receiver
func (p Point) Sum() int     { return p.X + p.Y } // value receiver

Output of bench/goptr/internals.go, section 1; labels translated:

1) ADDRESS AND DEREFERENCE
──────────────────────────
  &x                       -> <addr 1>
  p := &x; p               -> <addr 1>
  *p                       -> 10
  *p = 20; x               -> 20
  pt := &Point{1, 2}; var v Point
  pt.X                     -> 1    (same as (*pt).X)
  pt.Sum()                 -> 3    (Sum on Point: *pt taken)
  v.Move(5); v.X           -> 5    (Move on *Point: &v taken)

Real addresses change from run to run, so the script prints labels: the same address gets the same label <addr N>. p and &x have one label, that is, one value.

The last three lines are why Go code shows so few stars. A field through a pointer is read without a dereference: the selector rule in the specification applies "for a value x of type T or *T", so pt.X is (*pt).X. A method is called the same way: for a method on Point the compiler turns pt.Sum() into (*pt).Sum(), and for a method on *Point it turns v.Move(5) into (&v).Move(5), because v is addressable (that is, its address can be taken: it is a variable; what else is addressable is Mechanism 3). The method set in the quote below is the set of methods that can be called on a value of the type:

When this shorthand is not available — for example, for a value in an interface or for a map element — is covered in the lesson on method receivers.

new(T) and &T{}. Both give a pointer to a new variable:

Output of bench/goptr/internals.go, section 4; labels translated:

4) new(T) AND &T{}
──────────────────
  a := new(Point)          -> {X:0 Y:0}
  b := &Point{}            -> {X:0 Y:0}
  *a == *b                 -> true
  a == b                   -> false   (two different variables)
  allocations when the pointer goes into a global variable:
    sinkP = new(Point)     -> 1
    sinkP = &Point{}       -> 1
  new(int); *n             -> 0   (there is no &int{}: int has no composite literal)

For the struct Point both forms give pointers to equal zero values, while the pointers themselves differ: each expression creates its own variable. One allocation each in this context, and the compiler's placement decisions (Mechanism 4) are the same for both; the allocation count is an observation of the go1.24.7 implementation, not a language rule. &T{...} can fill in fields right away, while new works with any type, including int, which has no composite literal.

For a slice and a map the forms differ. new(T) gives a pointer to the zero value of the type, and the zero value of a slice or a map is nil. &T{} gives a pointer to an empty but initialized container. The specification says so directly:

Output of bench/goptr/audit.go, section 1; labels translated:

1) new(T) AND &T{} FOR A STRUCT, A SLICE AND A MAP
──────────────────────────────────────────────────
  T                  *new(T)              *(&T{})
  Point              {X:0 Y:0}            {X:0 Y:0}
  []int              == nil: true         == nil: false
  map[string]int     == nil: true         == nil: false

  write (*m)["k"] = 1:
    m := new(map[string]int)    -> panic: assignment to entry in nil map
    m := &map[string]int{}      -> len 1
  *s = append(*s, 1):
    s := new([]int)             -> len 1   (append to a nil slice is legal)
    s := &[]int{}               -> len 1

For a slice the difference barely shows: append to a nil slice is legal. For a map it decides everything: a map from new cannot be written to — a panic — it has to be created with make or a literal first. That is why a pointer to a map is written as &map[K]V{}, or not needed at all: a map is itself a reference to a shared table (see the lesson on maps).

Neither a constant nor the result of a function call has an address.

Output of bench/goptr/compile.sh, case addrconst (the file intentionally does not compile):

addrconst:
  ./main.go:10:8: invalid operation: cannot take address of 10 (untyped int constant)
  ./main.go:11:8: invalid operation: cannot take address of get() (value of struct type Point)

This is enough for a Junior-level answer to "what is a pointer": a value that holds the address of a variable. & takes the address, * gives the variable at the address, the zero value is nil. Through a pointer a function can change the caller's variable without copying it. The last sentence is exactly what the next step checks.

Mechanism 1: a pointer parameter is a copy

What happens on a function call, the specification states directly:

Arguments are assigned to parameters — the rule has no exception for pointers. The parameter p *int is a new variable of the function, and the address is copied into it. Three functions with the same signature.

Fragment of bench/goptr/internals.go (comment translated):

func set(p *int) { *p = 42 }
 
func redirect(p *int) {
    y := 0
    p = &y
    *p = 99
}
 
func drop(p *int) { p = nil }
 
func where(p *int) (string, string) { return addr(p), addr(&p) } // prints the value of p and the address of p itself

Output of bench/goptr/internals.go, section 2; labels translated:

2) A POINTER PARAMETER IS A COPY
────────────────────────────────
  outside  p = <addr 1>   &p = <addr 2>
  inside   p = <addr 1>   &p = <addr 3>
  Same value — the address of x; a different pointer variable.

  set(p):      *p = 42             x = 42    — visible
  redirect(p): p = &y; *p = 99     x = 42, p = <addr 1>    — not visible
  drop(p):     p = nil             p == nil: false    — not visible

The "inside" line is printed by where — the same kind of function with a p *int parameter. The first two lines are the whole mechanism. Inside the function p holds the same <addr 1>, but the variable p itself lives at a different address: <addr 3> against <addr 2>. These are two variables with the same value. Everything else follows:

• *p = 42 writes at the address — into x, shared by both copies. That is visible outside.
• p = &y changes the copy itself. The outer p knows nothing about it and still points at x; 99 went into y.
• p = nil is the same: the copy was cleared.

So the answer to "is anything passed by reference" is no. Everything is passed by value; a pointer's value is an address, and a copy of the address leads to the same variable. "By reference" in C++ means the parameter is another name for the same variable, and assigning to it changes the caller's variable. Go has no such parameter; drop(p) is the check.

All of this fits into a short program. The full file bench/goptr/cases/example/main.go can be copied into an empty directory next to a go.mod (module example, go 1.24) and run with go run .:

package main
 
import "fmt"
 
func set(p *int)  { *p = 42 }
func drop(p *int) { p = nil }
 
func main() {
	x := 1
	p := &x
	set(p)
	fmt.Println(x)
	drop(p)
	fmt.Println(p == nil, *p)
}

Output of bench/goptr/example.sh; the header translated:

go1.24.7 linux/amd64 | full example: go run .

  42
  false 42

If a function really does need to change the caller's pointer, it is given the address of that pointer — and that is again passing by value, only the value is now a **int.

Fragment of bench/goptr/internals.go:

var other = 7
 
func retarget(pp **int) { *pp = &other }

Output of bench/goptr/internals.go, section 9; labels translated:

9) A POINTER TO A POINTER
─────────────────────────
  before: p = <addr 1> (address of x), *p = 1
  retarget(&p): *pp = &other
  after:  p = <addr 2> (address of other), *p = 7

In practice it is simpler to return the new pointer as a result.

Mechanism 2: nil — a panic on dereference, but not on a method call

The dereference rule in the specification is short:

The key word is evaluate *x. Not "use the pointer" but read or write the variable through it.

Fragment of bench/goptr/internals.go; comments shortened and translated:

type Tree struct {
    Val         int
    Left, Right *Tree
}
 
func (t *Tree) Sum() int { // checks nil itself
    if t == nil {
        return 0
    }
    return t.Val + t.Left.Sum() + t.Right.Sum()
}
 
func (t *Tree) Kind() string { return "tree" } // touches no fields

Output of bench/goptr/internals.go, section 3; labels translated:

3) nil POINTER
──────────────
  var np *Point; np == nil -> true
  *np                      -> panic: runtime error: invalid memory address or nil pointer dereference
  np.X                     -> panic: runtime error: invalid memory address or nil pointer dereference
  np.Sum()  (on Point)     -> panic: runtime error: invalid memory address or nil pointer dereference
  nt.Kind() (on *Tree)     -> "tree"
  nt.Sum()  (on *Tree)     -> 0
  tree 1 + 2, t.Sum()      -> 3
  panic value is a runtime.Error: true

Three panics and two successful calls, and the line between them runs exactly along the dereference:

• *np and np.X dereference — a panic. For a field the specification says it separately: "assigning to or evaluating x.f causes a run-time panic".
• np.Sum() is a method on the value Point. To call it, *np has to be copied into the receiver, and that is a dereference — a panic.
• nt.Kind() and nt.Sum() are methods on the pointer *Tree. The receiver is just a parameter holding nil; there is no panic until the body touches a field. Kind touches no fields, Sum checks t == nil first.

This is a common technique: the recursive Sum does not check its children before calling — an empty subtree yields 0 by itself.

The panic text comes from the runtime. runtime/panic.go (line 258 in go1.24.7) holds memoryError = error(errorString("invalid memory address or nil pointer dereference")), and the runtime error: prefix is added by errorString.Error in runtime/error.go. The value caught by recover is a runtime.Error, as the run printed. The text has nothing to do with it: errorString has a RuntimeError() method (same file, line 79 in go1.24.7), and "a type is a run time error if it has a RuntimeError method".

One warning worth raising yourself in an interview: a nil pointer stored in an interface makes the interface non-nil. The method on the nil receiver will be called, and err == nil will be false. This is covered in the lesson on interfaces.

Where go1.24 did not panic

go1.24.7 does not always keep the "dereferencing nil panics" guarantee: the compiler could move the nil check into the branch where the loaded value is used, and on the other path it never ran. In go1.25.1 the tighten pass, which moves values closer to where they are used, is no longer allowed to move nil checks (src/cmd/compile/internal/ssa/tighten.go, lines 48–49: "Nil checks need to stay in their block"), and the distribution contains the regression test test/fixedbugs/issue72860.go. Here is the function from it and familiar-looking code that reads the result before checking the error.

Fragment of bench/goptr/nilcheck.go; comments removed, the string in open translated:

//go:noinline
func f(p *int, b bool) int {
    valid := *p >= 0
    if !b || !valid {
        return 5
    }
    return 6
}
 
func open() string {
    file, err := os.Open("no-such-file")
    name := file.Name()
    if err != nil {
        return "open failed, the name is not used"
    }
    return name
}

Output of bench/goptr/nilcheck.go on go1.24.7; labels translated:

go1.24.7 linux/amd64 | the nil check the compiler deferred

  f(nil, false)            -> 5
  open()                   -> open failed, the name is not used

Output of the same file on go1.25.1; labels translated:

go1.25.1 linux/amd64 | the nil check the compiler deferred

  f(nil, false)            -> panic: runtime error: invalid memory address or nil pointer dereference
  open()                   -> panic: runtime error: invalid memory address or nil pointer dereference

file.Name() is return f.name (os/file.go, line 62 in go1.24.7 and 63 in go1.25.1): a field read through nil. On go1.24.7 the code "worked"; on go1.25.1 it panics — as the specification requires. The practical conclusion: code that touches the result before checking the error could pass its tests and start panicking after a compiler upgrade. Fix the code, not the version: first if err != nil, then the result.

Mechanism 3: an address belongs to a variable — a slice element has one, a map element does not

& does not apply to everything. The specification lists what is addressable:

Slice indexing is on the list, map indexing is not, and the compiler confirms it.

Output of bench/goptr/compile.sh, cases mapaddr and mapfield (the files intentionally do not compile):

mapaddr:
  ./main.go:9:8: invalid operation: cannot take address of m["a"] (map index expression of struct type Point)

mapfield:
  ./main.go:9:2: cannot assign to struct field m["a"].X in map

The second error follows from the first. m["a"].X = 10 assigns to a field of a struct stored in a map; a field is addressable only in an addressable struct, and a map element is not addressable. The fix: take the value out, change it and put it back — or store pointers in the map. Why maps work this way — entries move to a new table as the map grows — is covered in the lesson on maps.

The address of a slice element can be taken — and right away you can see what happens to the address of an element that has moved.

Output of bench/goptr/internals.go, section 5; labels translated:

5) ADDRESS OF A SLICE ELEMENT AND append
────────────────────────────────────────
  s := []int{1, 2, 3}; e := &s[0]; *e = 10 -> s = [10 2 3]
  len 3, cap 3
  s = append(s, 4)         -> len 4, cap 6
  e == &s[0]               -> false   (array reallocated)
  *e = 100                 -> s[0] = 10, *e = 100
  with spare capacity: make([]int, 3, 8), e2 := &s2[0], append, *e2 = 100
  e2 == &s2[0]             -> true
  s2[0]                    -> 100

There was no spare capacity, so append allocated a new array and copied the elements over. s now looks at the new array and e at the old one. The write *e = 100 succeeded, but into an array the slice no longer sees: s[0] = 10. With spare capacity the array is the same, and the link is kept.

Note what is not happening here: a dangling pointer as in C. The pointer e is not broken — reading and writing through it is legal, and the old array has not gone anywhere. That is exactly why it stays in memory as long as e is alive.

Output of bench/goptr/audit.go, section 2; labels translated:

2) THE OLD ARRAY AFTER REALLOCATION
───────────────────────────────────
  s := make([]byte, 8 MB); e := &s[0]; s = append(s, 1)
  *e = 5; *e, s[0]                -> 5 0   (the write is legal, but goes to the old array)
  live heap after GC, e alive     -> 18 MB
  live heap after GC, e = nil     -> 10 MB
  While e is alive, the whole old 8 MB array is alive too.

Hence the rule for code: a pointer to a slice element is linked to the slice's current array until append reallocates it; after that it works with the old array and keeps it in memory. Holding such a pointer across an append means depending on a capacity nobody usually controls. How growth works and when the array is reallocated is in the lesson on slices.

Mechanism 4: a pointer to a local variable is legal

In C, returning the address of a local variable is a bug: the function's frame has been freed and the pointer looks at garbage. In Go it is an ordinary constructor: the variable lives as long as something points to it. Where to place it — in the function's frame (on the stack) or on the heap, memory that outlives the call — is decided by the compiler. In the run the function is marked //go:noinline, that is, it is not inlined into the call site.

Fragment of bench/goptr/internals.go:

//go:noinline
func newCounter() *int {
    c := 0
    return &c
}

Output of bench/goptr/internals.go, section 6; labels translated:

6) A POINTER TO A LOCAL VARIABLE
────────────────────────────────
  c1, c2 := newCounter(), newCounter(); *c1 += 1
  *c1, *c2                 -> 1 0
  c1 == c2                 -> false   (each call gets its own variable)
  allocations per call:
    newCounter() (return &c)   -> 1
    localOnly()  (&c stays in) -> 0

Each call yields its own variable, and it outlived the function. In this context — the function is not inlined, the caller needs the result — each call cost one allocation. The specification says nothing about the stack and the heap — it speaks of variables. The compiler's decision can be seen.

Output of bench/goptr/escape.sh (file cases/escape/main.go); the header translated:

go1.24.7 linux/amd64 | go build -gcflags='-m -l': compiler decisions

  ./main.go:9:2: moved to heap: c
  ./main.go:22:34: new(Point) escapes to heap
  ./main.go:24:31: &Point{} escapes to heap
  ./main.go:28:10: new(Point) does not escape
  ./main.go:34:7: &Point{} does not escape

Line 9 is c in newCounter: its address is returned, the variable must outlive the frame, and the compiler moves it to the heap. Lines 22–34 are new(Point) and &Point{} in identical positions: when the pointer is returned, both escapes to heap; when it stays inside the function, both does not escape. That is the answer to "are new(Point) and &Point{} the same": the compiler does not tell them apart even here.

These lines also show the reverse: taking an address does not by itself mean a heap allocation. In localOnly the address of c is taken but does not leave the function, and there are zero allocations.

And one more thing: moved to heap: c on line 9 is a decision about the function compiled on its own (the -l flag forbids inlining). If the function can be inlined, the compiler decides again at every call site. The same newCounter without //go:noinline and without -l.

Output of bench/goptr/inline.sh (file cases/inline/main.go; local is line 16, global line 23); the header translated:

go1.24.7 linux/amd64 | go build -gcflags='-m': inlining and the call site

  ./main.go:16:17: inlining call to newCounter
  ./main.go:23:20: inlining call to newCounter
  ./main.go:27:7: inlining call to newCounter
  ./main.go:28:8: inlining call to newCounter
  ./main.go:7:2: moved to heap: c
  ./main.go:23:20: moved to heap: c
  ./main.go:28:8: moved to heap: c

Output of bench/goptr/audit.go, section 3 (allocations per call, testing.AllocsPerRun); labels translated:

3) ALLOCATIONS DEPEND ON THE CALL SITE
──────────────────────────────────────
  newCounterInl is inlined (no //go:noinline):
    p := newCounterInl(); *p++; sinkN = *p  -> 0
    sinkP = newCounterInl()                 -> 1
  newCounter with //go:noinline:
    p := newCounter(); *p++; sinkN = *p     -> 1

In the function local (line 16) the pointer does not leave it, and there is no moved to heap line for that call site; the measurement gives zero allocations. In global (line 23) the pointer goes into a global variable — one allocation. Hence the correct statement: returning the address of a local variable is correct; whether there is an allocation, and how many, is decided by the compiler at the specific call site. The allocation counts here are an observation of go1.24.7 (the same on go1.25.1), not a promise of the language. How the compiler decides and which other cases send a variable to the heap — the lesson on escape analysis.

Mechanism 5: no pointer arithmetic — only through unsafe

In C, p + 1 is a pointer to the next element. In Go it does not compile.

Output of bench/goptr/compile.sh, case ptrarith (the file intentionally does not compile):

ptrarith:
  ./main.go:8:6: invalid operation: p + 1 (mismatched types *int and untyped int)
  ./main.go:9:2: invalid operation: p++ (non-numeric type *int)

There are no arithmetic operations on pointers: no addition, no subtraction, no ++, no < between pointers. They can be compared only for equality (including with nil). So a pointer in Go does not leave the variable it points to — you move to the neighbouring array element by index, and the index is bounds-checked.

If address arithmetic is really needed — say, to parse a binary format without copying — it is in the unsafe package.

Output of bench/goptr/internals.go, section 7; labels translated:

7) ARITHMETIC — ONLY THROUGH unsafe
───────────────────────────────────
  arr := [4]int32{10, 20, 30, 40}; q := &arr[0]
  unsafe.Sizeof(arr[0])    -> 4
  *(*int32)(unsafe.Add(unsafe.Pointer(q), 4))  -> 20
  *(*int32)(unsafe.Add(unsafe.Pointer(q), 12)) -> 40
  without unsafe: arr[1]   -> 20

The offset is counted in bytes, not elements, and there is no bounds check. The package documentation names the price plainly:

And one more thing: packages that import unsafe, in the words of the same documentation, "may be non-portable and are not protected by the Go 1 compatibility guidelines". In an interview that is enough: the language has no pointer arithmetic, unsafe is the way out for rare places, and you pay for it with guarantees.

Deeper: value or pointer — the cost of a copy against the cost of the heap

"Pass large structs by pointer, it is faster" is advice that is half right. The first half is the copy.

Fragment of the output of bench/goptr/practice.go, task 2; labels translated:

  size     value      pointer     ratio
    16 B     1.66 ns    1.56 ns    1.07
  1024 B    23.01 ns    1.65 ns   13.92

The function reads two fields and nothing else. At 16 bytes the difference is a fraction of a nanosecond: there is almost nothing to copy. At a kilobyte the value is 13.92 times more expensive: every call copies 1024 bytes. The same dependence for a method receiver is covered in the lesson on receivers.

The second half is where the pointer comes from. Two functions build the same kilobyte struct; one returns it by value, the other returns a pointer to its own variable.

Fragment of bench/goptr/practice.go; comments removed:

//go:noinline
func makeBig() Big {
    var b Big
    b.A[0] = 1
    return b
}
 
//go:noinline
func newBig() *Big {
    b := &Big{}
    b.A[0] = 1
    return b
}

Fragment of the output of the same run; labels translated:

  makeBig() Big     25.62 ns   allocs 0, bytes 0
  newBig()  *Big   301.79 ns   allocs 1, bytes 1024
  ratio newBig / makeBig            11.8

Here the pointer is more expensive, by 11.8 times. Copying a kilobyte takes a few tens of nanoseconds; newBig makes a 1024-byte heap allocation on every call, and that memory later has to be reclaimed by the garbage collector. Mechanism 4 showed where the allocation comes from: a variable whose address was returned must outlive the frame.

A summary of this measurement, instead of the rule "a pointer is faster". The mechanism explains where the difference comes from; whether it exists in your code and how large it is, only a measurement on your side shows:

The last row is the main one. The choice between a value and a pointer starts with "must the function change the original" and "may the value be absent (nil)", and the cost is checked with a profiler where it matters — the numbers above answer "can it go either way", not "how it will be in your code".

How to answer in an interview

Short answer: a pointer is a value that holds the address of a variable. In Go everything is passed by value, the pointer too: a function receives a copy of the address. A write through the pointer (*p = 42) is visible to the caller because both copies lead to one variable; assigning to the parameter itself (p = nil) is not, because only the copy changes.

This is enough to answer correctly. What follows is what you add if the interviewer digs.

If the interviewer digs deeper

On "by reference", show the two address labels. "Outside, p holds <addr 1> and lives at <addr 2>; inside the function it holds the same <addr 1> but lives at <addr 3>. One value, two variables — that is why p = nil inside is not visible outside."

On "a method on nil", the line is the dereference. "A method with a pointer receiver can be called on nil: the receiver is just a parameter. It panics if the body touches a field, or if the method is declared on the value — then *p has to be copied. Nil-safe methods like Sum on an empty tree are built on this."

On "the address of a map element", addressability. "&m[k] does not compile, and neither does m[k].X = 1. A slice element does have an address, but after an append that reallocated the array the pointer writes into the old array — in the run s[0] = 10, *e = 100."

On "returning a pointer to a local", lifetime is separate from placement. "It is legal: the variable lives as long as something points to it. Where to place it is up to the compiler: for a function compiled on its own -gcflags=-m prints moved to heap: c, but in our run an inlined call whose pointer did not leave it made no allocation."

On "which is faster", both sides. "Passing an existing large struct by pointer is cheaper than copying it. But returning a pointer to a new struct can cost more than returning it by value, because of the heap allocation; in the measurement I have seen, it did. By how much depends on the machine and the code — that is measured."

Next they ask

8) SLICE AND MAP AS A PARAMETER: A COPY OF THE HEADER
─────────────────────────────────────────────────────
  setFirst(s): s[0] = 100          outside s = [100 2 3]    — visible
  grow(s):     s = append(s, 4)    outside len(s) = 3    — not visible
  put(m):      m["k"] = 1          outside len(m) = 1    — visible
  resetMap(m): m = nil             outside m == nil: false    — not visible

Common misconceptions

Version history

The lesson's measurements were taken on go1.24.7 and go1.25.1, linux/amd64; the language rules were checked against their specifications on 14.10.2026. Newer versions had been released by that date; of their release notes, one change in Go 1.26 concerns this lesson — it is in the last row of the table, and the lesson did not measure it: Go 1.26 is not in the measurement environment.

Practice

Two tasks. Answer first, then check against the real output: in both, the correct answer is taken from the script's run, not assigned.

func reset(p *int) { p = nil }
func set(p *int)   { *p = 7 }

x := 1
p := &x
reset(p)
fmt.Println(p == nil)
set(p)
fmt.Println(x)
s := []int{1, 2, 3}
q := &s[0]
s = append(s, 4)
*q = 100
fmt.Println(s[0], *q)

false
7
1 100

true
7
100 100

false
7
100 100

false
1
1 100

Knowledge check