In Go, when you forward a slice with `f(s...)`, can the callee's writes to that parameter change the caller's slice?

## Two call forms, two very different memory stories A variadic parameter is a slice, and a Go slice value is a three-word header: a pointer to a backing array, a length and a capacity. Passing it copies the header, never the array. That single fact drives the whole answer. When you call with loose arguments — `normalize("Ann@x", "Bo@x")` — the compiler builds a backing array **for that call**, forms a slice over it and passes the header. The callee is the only holder of that array, so it may write into it freely and nothing outside notices. When you call with the spread — `normalize(list...)` — there is no new array. The parameter gets the header of `list`, pointing at the array `list` already points at. Now the callee and the caller are two names for the same storage. ```go func normalize(addrs ...string) { for i := range addrs { addrs[i] = strings.ToLower(addrs[i]) } } ``` Call it as `normalize(recipients...)` and `recipients` comes back lowercased. Nothing in the signature warned you. `...string` looks exactly as harmless as it did at the literal-argument call site. ## Why this bites in real code and not in tests This is the shape of the failure that makes it worth an interview question. A mail-merge composer has one call site that spreads a live recipient list, and a test suite whose calls all look like `normalize("a@x", "b@x")`. The test call sites build their own arrays, so the mutation is invisible there and every test is green. The production call site shares the caller's list, and downstream code that expected the original casing — a dedupe against a stored set, an audit log, a retry that re-reads the list — quietly works on rewritten data. Nothing in the toolchain flags it. `go vet` has no check for a callee writing through a shared backing array, and the race detector is silent because there is no race: one goroutine, ordinary ordered writes. The only mechanical way to surface it is a test that spreads a slice and then asserts on **that slice** after the call returns. ## What to do about it **Copy at the top, if the function must reorder or rewrite.** `local := make([]string, len(addrs)); copy(local, addrs)` gives you a private array; `copy` moves `min(len(dst), len(src))` elements and returns that count. This costs one allocation per call, which is usually irrelevant and occasionally is not — measure before you decide it matters. **Or document the mutation.** "Reorders its arguments" is a perfectly respectable contract; the standard library has several functions that sort in place. It stops being respectable when it is undocumented, because a caller reading `normalize(addrs ...string)` has no way to infer it. **Or change the signature.** `func normalize(addrs []string)` says out loud that you are handing over a slice, and readers of the call site are primed to think about aliasing in a way that `normalize(list...)` does not prime them. When a function only ever gets called with a slice anyway, the variadic sugar buys three characters and costs clarity. **Or return new values instead of mutating.** For a composer that produces normalised addresses, returning a fresh `[]string` sidesteps the whole question, at the price of an allocation the caller can see. ## The mirror-image mistake The other way to get this wrong is to over-correct: to believe that because slices share storage, a callee can also change the caller's **length**. It cannot. The header is copied, so `addrs = addrs[:1]` inside the callee reslices only the callee's copy of the header, and the caller's length is untouched. What crosses the boundary is writes to elements the caller can still see through its own header — nothing about the header itself. So the rule to carry: **the spread form shares elements, not the slice variable.** Mutating `addrs[i]` reaches the caller; rebinding `addrs` does not.