Golang Pointers: & and *, new, nil and When to Use Them

& and *

A pointer holds the memory address of a value. &x gives you a pointer to x. *p follows the pointer to the value.

package main

import "fmt"

func main() {
	x := 10
	p := &x // p has type *int

	fmt.Println(*p) // read through the pointer: 10
	*p = 20         // write through the pointer
	fmt.Println(x)  // x changed: 20

	fmt.Printf("%T\n", p)
	fmt.Println(p != nil)
}

The star has two roles. In a type (*int) it means "pointer to int". In an expression (*p) it means "the value p points to". Printing p itself shows an address like 0xc000012345, which differs between runs.

Why pointers exist: sharing instead of copying

Go passes everything by value. A function gets a copy of each argument, so it cannot change the caller's variable. Passing a pointer copies the address instead, and both sides reach the same value.

package main

import "fmt"

func doubleCopy(n int) {
	n *= 2
}

func doublePtr(n *int) {
	*n *= 2
}

func main() {
	v := 21
	doubleCopy(v)
	fmt.Println(v) // 21

	doublePtr(&v)
	fmt.Println(v) // 42
}

Go has no references in the C++ sense. "Pass by reference" in Go means passing a pointer by value.

Pointers to structs

Struct pointers are the most common pointers in Go code. Field access dereferences automatically: p.Name means (*p).Name.

package main

import "fmt"

type Account struct {
	Owner   string
	Balance int
}

func (a *Account) Deposit(n int) {
	a.Balance += n // no explicit * needed
}

func main() {
	acc := &Account{Owner: "Ana"} // pointer to a new struct
	acc.Deposit(100)
	acc.Balance -= 30
	fmt.Println(acc.Owner, acc.Balance)

	same := acc
	same.Balance = 0
	fmt.Println(acc.Balance) // 0: both variables point at one Account
}

Methods follow the same logic: a pointer receiver lets the method change the struct. The methods page covers the value vs pointer receiver choice.

new

new(T) allocates a zeroed T and returns its address. It is the same as declaring a variable and taking its address.

p := new(int) // *int pointing at 0
var x int
q := &x           // same thing, two lines
a := new(Account) // same as &Account{}

In practice &T{...} is more common for structs because it lets you set fields in the same expression. new is handy for pointers to basic types. Do not confuse it with make, which builds slices, maps and channels and returns them ready to use, not as pointers.

Returning a pointer to a local variable is safe

In C, returning the address of a local variable is a bug. In Go it is ordinary code.

package main

import "fmt"

type Config struct {
	Port int
	Mode string
}

func defaultConfig() *Config {
	c := Config{Port: 8080, Mode: "dev"}
	return &c // c outlives the call, so it lives on the heap
}

func main() {
	cfg := defaultConfig()
	cfg.Mode = "prod"
	fmt.Printf("%+v\n", *cfg)
}

The compiler's escape analysis decides whether a value lives on the stack or the heap. You never choose, and you never free memory: the garbage collector reclaims it when nothing points to it. go build -gcflags=-m prints those decisions if you are curious.

nil pointers

The zero value of any pointer type is nil. Dereferencing nil panics.

package main

import "fmt"

type Node struct {
	Val  int
	Next *Node
}

func main() {
	defer func() {
		fmt.Println("recovered:", recover())
	}()

	list := &Node{Val: 1, Next: &Node{Val: 2}}
	for n := list; n != nil; n = n.Next {
		fmt.Println(n.Val)
	}

	var missing *Node
	fmt.Println(missing == nil)
	fmt.Println(missing.Val) // panics
}

Output:

1
2
true
recovered: runtime error: invalid memory address or nil pointer dereference

Without the recover, the program would crash with that message and a stack trace starting with panic: runtime error: invalid memory address or nil pointer dereference and [signal SIGSEGV: segmentation violation ...]. The usual sources:

• a pointer variable or struct field that was never set
• m[key] on a map[string]*T for a missing key, which returns nil
• ignoring an error: f, _ := os.Open(path) leaves f nil on failure
• a method with a pointer receiver called on a nil pointer, which then reads a field

Calling a method on a nil pointer is itself legal. The panic happens only when the method touches the receiver's fields.

When to use a pointer

Use a pointer when:

• a function or method must change the caller's value
• the value is a large struct and is passed around often
• the type must not be copied (it contains a sync.Mutex, or it represents a unique resource like a connection)
• you need to express "no value" with nil, for example an optional field in a JSON struct (*int distinguishes "absent" from 0)

Do not use a pointer when:

• the value is small and read-only (time.Time, a Point)
• the type is already a reference-like value: slices, maps, channels, functions and interfaces rarely need * in front of them. A *[]int or *map[string]int is almost always a mistake

Pointers are not automatically faster. Copying a small struct is cheap, and a pointer can force a heap allocation and add work for the garbage collector.

Pointers and loop variables

Taking the address of a loop variable is safe since Go 1.22, because each iteration has its own variable:

package main

import "fmt"

func main() {
	var ptrs []*int
	for i := range 3 {
		ptrs = append(ptrs, &i)
	}
	for _, p := range ptrs {
		fmt.Print(*p, " ")
	}
	fmt.Println()
}

This prints 0 1 2. Before Go 1.22 (which also introduced range 3), the same loop written as for i := 0; i < 3; i++ printed 3 3 3, since all three pointers shared one variable. Note that &v in for _, v := range items points to a copy of the element, not the element in the slice. To get a pointer to the element itself, use &items[i].

Common mistakes

• Dereferencing without checking. Check if p == nil wherever nil is possible.
• Pointer to a range value. &v points at a copy; use &s[i].
• Pointers to slices and maps. Rarely needed. Return the new slice instead.
• Holding &s[i] across an append. If append reallocates, the pointer still refers to the old array and later writes go nowhere visible.