Variadic Functions and Argument Passing

## What the declaration means A parameter written with a leading `...` is **variadic**: the caller may supply zero, one or many arguments for it, and the function body sees them as a single slice. ```go func sum(xs ...int) int { total := 0 for _, x := range xs { total += x } return total } ``` The type of `xs` inside `sum` is `[]int` — not an array, not a pointer, not some special argument object. Everything you can do with a slice you can do with `xs`: `len(xs)`, `cap(xs)`, `xs[0]`, `xs[1:]`, `for i, x := range xs`. There is no separate variadic machinery at run time; the `...` exists only so the **call site** can be written without building a slice by hand. ## The two call forms **Loose arguments.** `sum(1, 2, 3)` is the form the sugar exists for. The compiler creates a backing array holding `1, 2, 3`, forms a slice over it, and passes that slice as `xs`. That slice belongs to this call and nobody else holds a reference to it. **Spread.** When the values are already in a `[]int`, you append three dots to the argument: `sum(nums...)`. This is not a conversion and not a copy — the parameter receives the slice header you passed, so `xs` has the same pointer, length and capacity as `nums`. This form is the reason a wrapper function can forward its own variadic parameter onward unchanged. The forms cannot be combined. `sum(1, nums...)` does not compile, and neither does `sum(nums)` — a `[]int` is not an `int`, so it is not a valid loose argument for a `...int` parameter. If you need both, build one slice first and spread that. ## Zero arguments `sum()` is legal and gives a nil slice: `xs == nil` is true, `len(xs)` is 0, and `range` runs zero times. Nothing is allocated. Note the consequence for API design: a callee cannot distinguish "the caller passed nothing" from "the caller spread an empty slice" by length — both are 0 — and distinguishing them by a nil check is fragile, because a caller who spreads an empty-but-non-nil slice and a caller who spreads a nil one behave differently for reasons they will never guess. Do not build meaning on that difference. ## Placement rules Only the **last** parameter may be variadic. `func f(xs ...int, sep string)` is a compile error; the fixed parameters go first, as in `func f(sep string, xs ...int)`. This is why every stdlib function of this shape puts its fixed arguments first — `fmt.Sprintf(format string, a ...any)`, `strings.Join` taking an explicit slice instead, `append(dst []T, elems ...T)`. It also has a design consequence worth knowing early: **you can never add a parameter after a variadic one**, so a variadic signature is a commitment. Once a package exports `func New(opts ...Option)`, every future knob must arrive as another `Option`, not as a new argument. ## `append` is the canonical example The builtin is declared, conceptually, as `append(slice []T, elems ...T) []T`. That explains both spellings you see everywhere: `append(dst, a, b)` supplies loose elements, and `append(dst, src...)` spreads an existing slice. There is one extra special case in the spec: when the destination is a `[]byte` you may spread a `string`, as in `append(b, "hello"...)`, because Go defines that conversion for this position. ## When not to reach for variadic Variadic parameters read well when the argument count is genuinely open and each argument is the same kind of thing: `max(a, b, c)`, a formatting call, a list of options. They read badly when they hide arity that actually matters — a function taking `...string` where exactly two strings are required has thrown away a compile-time check that a two-parameter signature would have given you for free. And a `...any` parameter throws away the element type entirely; the compiler stops helping and mistakes surface at run time. Prefer an explicit `[]T` parameter when the caller always has a slice anyway: it costs the caller three characters and it tells the reader the truth about what is being shared.