How does strings.Builder produce its final string without copying the bytes it accumulated?

## The problem it solves Building a string by repeated concatenation allocates a new array on every step, because strings are immutable. Building into a `[]byte` and converting once at the end is better, but that final `string(buf)` is itself an allocation and a full copy of everything you just assembled. `strings.Builder` removes that last copy. ## How the type is put together A `strings.Builder` has two fields: a `[]byte` buffer, and a pointer it uses to detect being copied. Its zero value is ready to use — `var b strings.Builder` needs no constructor, no `make`. The write methods (`Write`, `WriteString`, `WriteByte`, `WriteRune`) all reduce to `append` on the buffer, so the buffer grows amortised like any slice. `Grow(n)` reserves room up front, `Len()` and `Cap()` report the buffer's state, and `Reset()` drops the buffer entirely. ## The zero-copy finish `String()` returns a string whose pointer is the buffer's data pointer and whose length is the buffer's length — in current Go, `unsafe.String(unsafe.SliceData(b.buf), len(b.buf))`. No allocation, no byte copying, whatever the size. The soundness argument is the interesting part, and it is a single invariant: **a Builder only appends.** Bytes below the current length are never rewritten. After you call `String()`, further writes do one of two things — land in spare capacity past the returned string's length, or trigger `append` to allocate a new, larger array and leave the old one alone. Either way, the string you were handed keeps observing the same bytes forever, so its immutability is not violated. This is exactly the invariant that a hand-rolled `unsafe.String` over some other byte slice usually cannot promise. ## Why copying a Builder panics The invariant breaks if two Builders share one array. That is what copying a used Builder by value does: the copy's slice header points at the original's array, and appends through the copy could write into bytes the original also considers spare — two writers, one array, and strings already handed out potentially observing changes. So the Builder stores its own address on first use, and every write checks that the address still matches. Writing to a copy of a non-empty Builder panics with `strings: illegal use of non-zero Builder copied by value`. In practice this catches: passing a Builder by value to a function, storing one in a map or a slice of values and re-reading it, capturing one in a struct that is copied, or `for _, b := range builders`. Pass `*strings.Builder`, or keep the Builder local and return the finished string. Copying a **zero** Builder is fine — there is nothing to alias yet. ## bytes.Buffer is not the same deal `bytes.Buffer` is the older, more general type: it is a read-write buffer with an internal read offset, so bytes can be consumed as well as appended, and its array cannot be handed out as an immutable string. `bytes.Buffer.String()` therefore allocates and copies every time it is called. If the destination is a `string` and you only ever append, `strings.Builder` is the right type; if you need `io.Reader` behaviour or want to read the bytes back out as `[]byte`, `bytes.Buffer` is. ## Practical notes - Call `Grow` when you can estimate the final size; it turns several growth reallocations into one. - `String()` is cheap enough to call more than once, but each call returns a string over the buffer as it stands at that moment. - `Reset()` releases the buffer so the next write starts from nothing; reuse of the Builder itself is fine after a `Reset`. - A Builder is not safe for concurrent use; it has no locking. ## What an interviewer is listening for The words "the final conversion is elided because the Builder never rewrites what it has handed out", and an explanation of the copy check that ties back to that same invariant rather than treating it as an arbitrary rule.