Why does `var buf bytes.Buffer` work with no constructor, and which other standard library types are usable at their zero value?

## What "usable at the zero value" means Go guarantees that a declared variable is zeroed. A library author can exploit that: if you lay out a type so that the all-zero state is a *valid* state for its methods, then callers never need a constructor. `var x T` is enough. This is a deliberate design idiom in the standard library, not an accident. ## Why `bytes.Buffer` qualifies A `bytes.Buffer` accumulates bytes in an unexported slice plus a read offset. At zero, the slice is nil and the offset is 0. Appending to a nil slice is legal in Go and produces a new backing array, so the very first `Write` or `WriteString` works and allocates exactly then. Reading from an empty buffer returns end-of-file rather than misbehaving. Every method therefore has a sensible answer for the zero state, and the documented contract says the zero value is an empty buffer ready to use. ```go var buf bytes.Buffer buf.WriteString("ready") fmt.Println(buf.Len()) // 5 ``` `strings.Builder` follows the same pattern for building strings. ## Why `sync.Mutex` qualifies Here the trick is choosing the encoding so that zero carries meaning. A mutex's state field uses 0 for *unlocked*, so the zeroed struct is an unlocked mutex and `mu.Lock()` is correct on a freshly declared variable. That is why idiomatic Go writes ```go type counter struct { mu sync.Mutex n map[string]int } ``` and the embedded mutex simply works when the enclosing struct is zeroed, with no constructor to remember. `sync.RWMutex`, `sync.WaitGroup` (counter starts at 0) and `sync.Once` (not yet run) are all the same idea. `sync.Map` is a little different — it initialises its internal storage lazily on first use — but the observable contract is the same: the zero value is an empty map ready to use. ## Others worth knowing - **`http.Client`** — the zero value is a usable client; a nil `Transport` field means the package default is used. `http.DefaultClient` is exactly a zero-valued client behind a pointer. Note the sharp edge: its `Timeout` field is zero too, which for that field means *no timeout at all*. - **`http.Server`** — usable at zero for the common case, with a zero `Addr` meaning the default port and zero timeout fields meaning no timeout. - **`bytes.Reader`** — the zero value reads as empty, though you normally build one with `bytes.NewReader`. - **`time.Time`** — the zero value is a real, valid instant (the very beginning of the calendar it uses), not an error. Test for it with `t.IsZero()`, which exists precisely because "no time set" has to be expressed by that value. ## What does *not* qualify - **`sync.Cond`** — it needs a `Locker` to wait on, and at zero that field is nil, so you must build it with `sync.NewCond(&mu)`. - **`time.Ticker` and `time.Timer`** — their channel and the runtime timer behind it are created by `time.NewTicker` and `time.NewTimer`. A zero one has a nil channel and never delivers anything. - **`regexp.Regexp`** — a compiled pattern is the whole point; a zero one has nothing compiled into it. - **`database/sql.DB`** — it is created by `sql.Open`, which sets up the connection pool it manages. When a type's zero value is not usable, the standard library signals that by shipping a `New...` function, and the doc comment says what the constructor is for. The absence of such a function, plus a doc sentence like "the zero value is an empty buffer ready to use", is your cue in the other direction. ## One caveat about calling the methods Most of these types declare their methods on the pointer receiver: it is `(*bytes.Buffer).WriteString`, not `bytes.Buffer.WriteString`. `var buf bytes.Buffer` still works because a local variable is addressable, so `buf.WriteString(...)` is shorthand for `(&buf).WriteString(...)`. The same value stored somewhere unaddressable — an element of a map, for instance — cannot have those methods called on it directly. That is a property of method calls, not of zero values, but it is where the pattern most often trips people who store these types inside other containers. ## Why it matters for you as a caller It tells you when a `New` call is required and when it is noise. Writing `buf := bytes.NewBuffer(nil)` where `var buf bytes.Buffer` would do is harmless but unidiomatic; forgetting `sync.NewCond` is a nil dereference. Reading the type's doc comment for a zero-value sentence is the reliable way to tell the two apart.