Go Pointers vs Values in Parameters and Return Values

By the end of this page, you will understand how Go handles values, pointers, and slices in function parameters and return values. You will learn when to return a struct value, when to return a pointer, when to modify data through parameters, and how to choose between []T and []*T in idiomatic Go code.

In Go, the choice between values and pointers is mostly about ownership, mutation, clarity, and cost.

Struct values vs pointers

A struct value like MyStruct is copied when passed to a function or returned from one. That copy is independent from the original.

A pointer like *MyStruct points to one shared struct value. If multiple parts of your program hold that pointer, they all refer to the same underlying data.

This leads to a practical rule:

• Use values when the data is small, self-contained, and should behave independently.
• Use pointers when the function needs to modify the original, when copying would be undesirable, or when nil is a meaningful state.

Slices are small headers, not raw arrays

A slice in Go is a small descriptor containing:

• a pointer to an underlying array
• a length
• a capacity

So a slice itself is already cheap to pass around. Passing []T does not copy all elements. It copies only the slice header.

That means:

• Passing []T is usually fine.
• Returning []T is usually fine.
• Passing *[]T is uncommon and usually only needed if the function must replace the slice itself and the caller must observe that exact new slice header.

Think of a struct value as a printed form and a pointer as a house address.

• If you hand someone a printed form, they get their own copy. They can write on it, but your copy does not change.
• If you hand someone a house address, they can go to the same house you use and change what is inside.

A slice is like a note that says:

• where the storage starts
• how many items are currently used
• how much room is available

When you pass a slice, you are copying that note, not copying all the items. But both notes may still refer to the same underlying storage.

So:

• T means “here is your own item”
• *T means “here is access to the shared item”
• []T means “here is a lightweight view of a list”
• []*T means “here is a list of references to shared items”

Returning a struct value

package main

import "fmt"

type User struct {
    Name string
    Age  int
}

func NewUser() User {
    return User{Name: "Ava", Age: 30}
}

func main() {
    u := NewUser()
    fmt.Println(u)
}

Use this when:

• the struct is reasonably small
• copying is acceptable
• you want value semantics
• nil is not needed

Returning a pointer to a struct

package main

import "fmt"

type User struct {
    Name string
    Age  int
}

func NewUser() *User {
    return &User{Name: "Ava", Age: 30}
}

func  {
    u := NewUser()
    u.Age = 
    fmt.Println(*u)
}

Consider this example:

package main

import "fmt"

type Item struct {
    Value int
}

func changeValue(i Item) {
    i.Value = 99
}

func changePointer(i *Item) {
    i.Value = 99
}

func main() {
    a := Item{Value: 1}
    b := Item{Value: 1}

    changeValue(a)
    changePointer(&b)

    fmt.Println(a.Value)
    fmt.Println(b.Value)
}

What happens step by step

1. a := Item{Value: 1} creates a struct value.
2. b := Item{Value: 1} creates another struct value.
3. changeValue(a) passes a copy of a into the function.
4. Inside changeValue, i.Value = 99 changes only the local copy.
5. Back in main, a.Value is still .

Return struct values

Common for:

• configuration values
• timestamps or coordinates
• small domain objects
• result objects that should not be shared implicitly

Example:

func DefaultConfig() Config {
    return Config{Port: 8080, Debug: false}
}

Return struct pointers

Common for:

• objects with methods that mutate state
• database models shared across layers
• large structs
• optional results where nil means "not found"

Example:

func FindUser(id int) *User {
    // return nil if not found
    return &User{ID: id, Name: "Ava"}
}

Use pointer parameters

Common for:

• decoders and unmarshallers
• functions that fill or update existing values
• performance-sensitive code that reuses buffers

Example:

In real Go codebases, developers usually follow a few practical patterns.

1. Prefer returning values instead of output parameters

This is usually clearer:

func BuildUser() User {
    return User{Name: "Ava"}
}

Instead of:

func BuildUser(u *User) {
    u.Name = "Ava"
}

The output-parameter style is mostly used when:

• mutation is the point of the API
• avoiding allocation matters
• matching an interface or framework pattern

2. Use pointer receivers consistently when needed

If a struct's methods mutate state or the struct is large, methods often use pointer receivers:

type Counter struct {
    Value int
}

func (c *Counter) Inc() {
    c.Value++
}

If some methods use pointer receivers, it is often best to keep the method set consistent.

3. Prefer []T for collections by default

A slice of values is often simpler:

Mistake 1: Assuming pointers are always faster

Pointers can cause:

• more heap allocations
• more shared mutable state
• worse cache locality
• more nil checks

Do not choose pointers automatically.

Mistake 2: Using *[]T when []T is enough

Broken idea:

func Add(nums *[]int) {
    (*nums)[0] = 10
}

A pointer is unnecessary if you only want to modify elements.

Better:

func Add(nums []int) {
    nums[0] = 10
}

Mistake 3: Using []*T without needing shared identity

This adds complexity:

• each element can be nil
• more allocations
• harder memory behavior

Prefer []T unless you need pointer semantics.

Quick rules

• Prefer return values over output parameters.
• Prefer struct values by default.
• Use pointers when:
  • the function must mutate the original
  • the struct is large
  • nil is meaningful
  • identity/shared state matters
• Prefer []T by default.
• Use []*T when elements need shared identity or mutation.
• Use *[]T rarely.

Structs

func Make() T
func Make() *T
func Update(t *T)

• T: copy semantics
• *T: shared semantics
• Update(t *T): mutate caller's value

Slices

 []T
 []*T

Should I return a struct or a pointer in Go?

Usually return a struct value unless you need shared mutation, nil, identity, or the struct is large enough that copying is undesirable.

Is passing a slice by value expensive in Go?

No. A slice is a small header. Passing []T copies the header, not all the elements.

When should I use a pointer to a slice in Go?

Rarely. Use *[]T only when the function must replace the caller's slice header itself. Most of the time, return the new slice instead.

Should I use []T or []*T in Go?

Use []T by default. Use []*T when elements need shared identity, mutation, or are expensive to copy.

Can a function modify a slice without using *[]T?

Yes. It can modify existing elements through []T, because the slice refers to shared underlying storage.

Are pointers always more memory efficient in Go?

No. Pointers may cause extra allocations and add indirection. They are not automatically more efficient.

Why do some APIs use output parameters like func Decode(dst *T)?

Usually to fill an existing value, reduce allocations, or match a specific API style such as decoding, unmarshalling, or scanning.

• Pointer receivers — closely related because methods often follow the same value-vs-pointer rules as functions.
• Method sets in Go — important for understanding how value and pointer receivers affect interface implementation.
• Slices in Go — directly relevant because slices behave differently from arrays and structs.
• Arrays vs slices in Go — useful for understanding what actually gets copied.
• Escape analysis — helps explain when returning pointers may cause heap allocation.
• Nil in Go — relevant when choosing pointers because nil can represent missing values.
• Interfaces in Go — important when values and pointers are assigned to interfaces.
• Struct copying in Go — useful for understanding the cost and behavior of value semantics.