Value Semantics and Copies

A deployment tool clones a config before stamping environment-specific values. The clone works — until two environments disagree about a shared tag:

type Config struct {
	Name string
	Tags []string
}

func main() {
	base := Config{Name: "api", Tags: []string{"core"}}
	prod := base            // "independent copy"

	prod.Name = "api-prod"  // fine — base.Name still "api"
	prod.Tags[0] = "urgent" // base.Tags[0] is now "urgent" too!
}

The struct assignment did copy — completely, by the language's rules. What the rules copy is the representation: Name's bytes, and Tags' three-word slice header. The backing array the header points at was never part of the copy, so both structs are windows over one array. Value semantics say "assignment gives you your own value"; for reference-shaped fields, your own header still references shared storage.

Each type has its own answer to "what does copying duplicate":

The practical consequence: a Session struct with a Meta map[string]string field copies as a.Meta["role"] = "x" visible through b — maps inside copied structs share buckets wholesale (append, copy, and Slice Aliasing covers the slice half of this trap). Whenever a copy crosses an ownership boundary — returning a cached struct, storing caller data into your own state — decide whether sharing is intended. If not, clone the reference fields before the handoff. Predicting copies starts with reading your struct field by field, asking of each one: value, or window onto something shared?

Methods inherit the copy rule through their receivers, and the receiver choice is the API decision Go asks you to make for every type.

type Temperature float64

func (t Temperature) ToF() float64 { // value receiver: works on a copy
	return float64(t)*9/5 + 32
}

type Counter struct {
	n int
}

func (c *Counter) Inc() { c.n++ }      // pointer receiver: mutates the caller's
func (c Counter) Value() int { return c.n } // read-only half may stay a value

Temperature is a logical value — a reading does not change when you convert it, and returning new values (t + 5) rather than mutating keeps it honest. Counter carries mutable state; a value receiver's c.n++ would edit a per-call copy and silently do nothing for the caller. The default rules that keep codebases consistent:

• Pointer receiver when the method mutates, when the type embeds sync.Mutex (copying locks is a race — Pointers as Function Parameters), or when the struct is large enough that copying per call shows up.
• Value receiver for small immutable operations that return new values — numeric wrappers, coordinates, durations.
• Do not mix receiver kinds across one type's methods. func (c Counter) Reset() beside func (c *Counter) Inc() compiles, but callers cannot predict which methods preserve identity, and half the methods stop feeling like they belong to the same type.

Method sets add a hard constraint underneath the style rules: a type T with any pointer-receiver method satisfies interfaces only through *T, because plain T values cannot serve methods that might mutate (Interface Basics). Value-receiver methods, by contrast, belong to both T and *T. This is why Error() on a pointer-receiver error type forces &MyErr{} into returns, and why interface-heavy packages settle receiver kinds early — changing them later is a breaking change to every call site.

The performance reflex — "pointers are faster, so pass pointers" — misreads what value semantics buy. Three production properties come only from copies.

Independence under concurrency. A value passed into two goroutines is two values; neither can observe the other's writes. Race detectors stay quiet because there is nothing shared to race on. A time.Duration or a small config snapshot handed to workers is safe without a mutex precisely because the copy severed the connection.

No aliasing surprises. for _, job := range jobs gives each iteration its own job. If job is a struct whose fields are values, no other iteration can rewrite what you are processing. Aliasing bugs live where reference-shaped fields appear — which is a reason to keep hot-loop structs free of shared slices rather than a reason to distrust structs.

Predictable lifetimes and simple APIs. A function returning Report rather than *Report cannot leave the caller holding a pointer into your internal buffer. The caller cannot mutate your cache by accident. Nothing to nil-check, nothing to clone, nothing that outlives the call.

The costs are equally concrete, and they set the boundary for when to switch to pointers:

type Snapshot struct {          // ~10 words: two strings, a slice, a map...
	User    string
	Query   string
	Results []string
	Meta    map[string]string
}

func render(s Snapshot) string  // copies fields; headers still share storage
func renderSlow(s *Snapshot)    // needed only if mutation or size demands it

A ten-word struct by value is a handful of register moves — passing *Snapshot instead trades it for a memory load and a nil obligation. Reach for pointers when the method must mutate, the struct is genuinely large, a lock lives inside, or interfaces require it. Everything else stays a value, field-shared or not, until a benchmark (benchmarks and coverage) says otherwise. The habit to build: before every assignment or call, name what is copied and who shares what — because in Go, that question is answered per type, and half your bugs will be the type you did not think about.