How do you make first-use initialization inside a zero-usable Go type safe when several goroutines call its methods?

## The problem lazy initialization creates Keeping a type usable at its zero value often means building an internal member the first time a method needs it. Single-threaded that is trivial. Under concurrency it is a classic race, and the race is easy to write by accident because the code *looks* like it is protected: ```go func (c *Counter) Add(name string, n int64) { if c.counts == nil { // read outside any lock c.counts = make(map[string]int64) } c.mu.Lock() defer c.mu.Unlock() c.counts[name] += n } ``` Two goroutines can both evaluate the nil check before either assigns. Both call `make`. Both assign. One map survives; the other, plus every increment written into it, vanishes. Worse, an unsynchronised read of a field that another goroutine writes is a data race under Go's memory model — the behaviour is undefined, not merely "last writer wins", and a `-race` build reports it with both stacks. ## Option 1: check inside the lock If the type already carries a mutex to protect the member, use it for the creation too: ```go func (c *Counter) Add(name string, n int64) { c.mu.Lock() defer c.mu.Unlock() if c.counts == nil { c.counts = make(map[string]int64) } c.counts[name] += n } ``` One lock covers both the creation and the write, so there is exactly one map and no race. The cost is a branch on every call — negligible next to a mutex acquisition — and the discipline of repeating the check on every write path. If the type has five methods that touch the member, five checks is a maintenance smell; factor them into one unexported `c.ensure()` called under the lock, or move to the next option. ## Option 2: a sync.Once field ```go type Registry struct { once sync.Once mu sync.Mutex names map[string]int } func (r *Registry) init() { r.names = make(map[string]int) } func (r *Registry) Put(name string, v int) { r.once.Do(r.init) r.mu.Lock() defer r.mu.Unlock() r.names[name] = v } ``` `sync.Once` guarantees the function runs exactly once and that every caller of `Do` returns only after that run has completed — so the goroutine that arrives second is guaranteed to see the initialized member, which is the memory-ordering half of the problem, not just the mutual-exclusion half. `Do` is also cheap on the fast path after the first call. Two properties matter for this leaf specifically. First, **`sync.Once`'s own zero value is the not-yet-run state**, so adding it as a field costs nothing and does not itself require a constructor — the pattern stays self-hosting. Second, **`Once` considers the function done even if it panics**, so a setup step that can fail is a poor fit; a later call will proceed against a half-built value rather than retrying. ## The receiver detail people miss Any method that assigns to a field must have a **pointer receiver**. Written with a value receiver, `func (c Counter) Add(...)`, the assignment `c.counts = make(...)` mutates a copy that is discarded at return, so every call re-initializes and nothing is ever stored. This is the one place where lazy initialization interacts with method-set rules: `var c Counter; c.Add(...)` compiles because `c` is addressable and the compiler takes its address for you, but the same type used as a map element cannot have a pointer-receiver method called on it directly. ## When to stop and require a constructor Lazy initialization is not free forever. If first use has to start a goroutine, open a file, or dial something that can fail, you are pushing an error — and a lifetime — into a method that has no good way to report either. At that point the honest answer is a constructor that returns the built value and an error, plus a doc comment saying the zero value is not usable. Lazy setup is for allocation, not for work that can fail.