
A pointer holds the memory address of a value. Go has pointers but no pointer arithmetic - you cannot increment a pointer to step through memory the way C allows. This keeps pointers useful (sharing, avoiding copies, mutating through function calls) without most of the footguns.

<ExamplePair>
<ExampleProse>

`&` takes the address of a value and produces a pointer. `*` dereferences a pointer - it reads the value at that address. Assigning through a dereferenced pointer mutates the original.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func increment(n *int) {
    *n++ // dereference and mutate
}

func main() {
    x := 42
    p := &x // p is *int, holds address of x

    fmt.Println(x, *p) // 42 42 - same value, two ways to reach it

    *p = 100
    fmt.Println(x) // 100 - x was mutated through p

    increment(&x)
    fmt.Println(x) // 101
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Struct fields are accessed through a pointer with the same `.` syntax as value access - Go automatically dereferences the pointer. The `new` built-in allocates a zeroed value and returns a pointer to it.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

type Point struct {
    X, Y int
}

func main() {
    // Pointer to struct via & on a literal
    p := &Point{X: 1, Y: 2}

    // Field access through pointer - no explicit dereference needed
    fmt.Println(p.X, p.Y) // 1 2
    p.X = 10
    fmt.Println(p.X) // 10

    // new: allocates a zeroed Point and returns *Point
    q := new(Point)
    fmt.Println(q.X, q.Y) // 0 0
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

The zero value of a pointer is `nil`. Dereferencing a nil pointer causes a panic at runtime. Always check before dereferencing a pointer that may be nil.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func describe(p *Point) string {
    if p == nil {
        return "<nil>"
    }
    return fmt.Sprintf("(%d, %d)", p.X, p.Y)
}

type Point struct{ X, Y int }

func main() {
    var p *Point // nil
    fmt.Println(describe(p))            // <nil>
    fmt.Println(describe(&Point{3, 4})) // (3, 4)
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
If any method on a type needs to mutate the receiver, all methods on that type should use pointer receivers - mixing pointer and value receivers on the same named type breaks the method set and can cause a type to fail to satisfy an interface in non-obvious ways. The rule of thumb: use a pointer receiver if the struct is large (avoids copies on every call), if any method needs to mutate state, or if the zero value of the type is not meaningful. Use a value receiver only when the struct is small and all methods are read-only. Consistency within a type is more important than the size heuristic.
</InProduction>


The & and * operators, pointer to struct, nil pointer, and the pointer vs value semantics decision.

Pointers


A struct groups related fields under one name. Structs are the primary way to define domain types in Go - Go has no classes, but structs with methods give you all the encapsulation you need.

<ExamplePair>
<ExampleProse>

Define a struct with `type Name struct { ... }`. Fields have a name and a type. Access fields with `.`. The zero value of a struct is a struct with all fields zeroed - no constructor required.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

type Person struct {
    Name string
    Age  int
}

func main() {
    // Struct literal - positional (fragile, avoid in production)
    p1 := Person{"Alice", 30}

    // Named fields - order-independent, recommended
    p2 := Person{Name: "Bob", Age: 25}

    // Zero value - all fields are zeroed
    var p3 Person

    fmt.Println(p1, p2, p3)
    fmt.Println(p2.Name, p2.Age) // Bob 25

    p2.Age = 26 // field mutation
    fmt.Println(p2.Age) // 26
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

An anonymous struct has no named type. Use them for one-off groupings - test table entries, local temporary aggregations - where defining a named type would be noise.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func main() {
    point := struct {
        X, Y int
    }{X: 3, Y: 7}

    fmt.Println(point.X, point.Y) // 3 7

    // Common in table-driven tests:
    cases := []struct {
        input    int
        expected int
    }{
        {1, 2},
        {5, 10},
    }
    for _, c := range cases {
        fmt.Println(c.input, "->", c.expected)
    }
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Embedding includes one struct type inside another without a field name. The outer struct promotes the embedded type's fields and methods - they are accessible directly. This is composition, not inheritance.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

type Animal struct {
    Name string
}

func (a Animal) Speak() string {
    return a.Name + " makes a sound"
}

type Dog struct {
    Animal        // embedded - Dog promotes Name and Speak
    Breed  string
}

func main() {
    d := Dog{
        Animal: Animal{Name: "Rex"},
        Breed:  "Labrador",
    }

    // Promoted fields and methods - accessed directly on Dog
    fmt.Println(d.Name)   // Rex  (promoted from Animal)
    fmt.Println(d.Speak()) // Rex makes a sound (promoted from Animal)
    fmt.Println(d.Breed)  // Labrador
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Struct embedding promotes methods but the embedded type is still the receiver - the promoted method runs on the embedded value, not on the outer struct. If `Dog` tries to override `Speak` by defining its own `Speak` method, the outer method shadows the promoted one - but there is no polymorphic dispatch the way inheritance provides. Teams that treat embedding as inheritance get surprised when promoted methods bypass overrides, especially when the promoted method holds a reference to the embedded type and calls back into it. The [outbox pattern](/patterns/outbox) is a case where embedded structs appear in event payloads - the field ordering and zero-value behaviour of embedded types must be understood before serialising them.
</InProduction>


Struct definition, field access, struct literals, anonymous structs, embedding, and promoted fields.

Structs


A closure is a function that references variables from the scope in which it was defined. The function and the captured variables form a bundle - the closure retains a live reference to the variable, not a copy of its value at the moment of creation.

<ExamplePair>
<ExampleProse>

A factory function returns a closure that captures a variable from the enclosing scope. Each call to the factory produces a new, independent closure with its own captured state.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func makeAdder(x int) func(int) int {
    return func(y int) int {
        return x + y
    }
}

func main() {
    add5 := makeAdder(5)
    add10 := makeAdder(10)

    fmt.Println(add5(3))  // 8
    fmt.Println(add10(3)) // 13
    fmt.Println(add5(7))  // 12 - add5 and add10 are independent
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

A closure can capture and mutate a variable in the enclosing scope. Each call to the returned function updates the shared counter.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func makeCounter() func() int {
    count := 0
    return func() int {
        count++
        return count
    }
}

func main() {
    counter := makeCounter()
    fmt.Println(counter()) // 1
    fmt.Println(counter()) // 2
    fmt.Println(counter()) // 3

    other := makeCounter() // independent counter
    fmt.Println(other())   // 1
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

The goroutine-loop closure bug: on Go versions before 1.22, a goroutine launched inside a loop captures the loop variable itself - a single shared variable - not a snapshot of its value at that iteration. By the time the goroutines run, the loop has finished and every goroutine sees the last value. Go 1.22 changed loop-variable scoping so each iteration gets its own variable, fixing the bug automatically. The safe fix for all versions: pass the loop variable as an argument to the goroutine function literal.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup

    // BUG (Go < 1.22): every goroutine captures the same `i` variable.
    // All likely print 5 (or whatever i is when they run).
    // On Go 1.22+ each iteration gets its own variable, so this is no longer buggy.
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Println("buggy:", i) // captures variable, not value (pre-1.22)
        }()
    }
    wg.Wait()

    fmt.Println("---")

    // FIX: pass i as an argument - a copy is made at call time.
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(n int) {
            defer wg.Done()
            fmt.Println("fixed:", n) // each goroutine gets its own n
        }(i)
    }
    wg.Wait()
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
The goroutine-loop closure bug is one of the most common sources of data races in real Go services. Before Go 1.22, the loop variable was shared across all iterations - capturing it in a goroutine produced a race between the goroutine read and the loop increment. Go 1.22 changed loop-variable scoping so each iteration gets its own variable, fixing the bug automatically - but services on older toolchain versions (or using `-gcflags=-lang=go1.21` for compatibility) still hit it. The defensive fix - passing the loop variable as an argument - works on all Go versions and is worth making a team habit until you can guarantee Go 1.22+ everywhere.
</InProduction>


Functions that capture and retain their lexical environment - the factory pattern and the goroutine-loop closure pitfall.