In Go's functional options pattern, what happens when two options in the same New call set the same field?

## The mechanism There is no magic in option ordering. The constructor holds a loop: ```go func New(addr string, opts ...Option) *Client { c := &Client{addr: addr, timeout: 5 * time.Second} for _, opt := range opts { opt(c) } return c } ``` Ranging over a slice visits index 0, 1, 2 and so on, so options run in exactly the order they were written at the call site. Each one performs an assignment. Two assignments to the same field mean the second overwrites the first, the same as `x = 1; x = 2`. So `New(addr, WithTimeout(2*time.Second), WithTimeout(30*time.Second))` yields a client with a 30-second dial timeout. The compiler says nothing — the two calls are distinct expressions producing distinct values — and the constructor says nothing either, because it never inspects what an option touched. ## Consequence one: where defaults go Defaults must be written into the struct before the loop. If you set them after, every option a caller passed is thrown away. If you set them by appending a `defaults()` option to the end of the slice, the same thing happens. The safe order inside the constructor is: build the struct with defaults, apply options, then validate. A related habit worth adopting: keep the defaults in one place. `newDefaults() *Client` or a package-level `defaultTimeout` constant means the value appears once, not scattered through both the constructor and the documentation. ## Consequence two: wrappers and forwarding The bug this leaf is really about shows up when one package wraps another's constructor. Suppose a shared internal package wants every client in the fleet to use its own keep-alive and a longer timeout: ```go func NewInternal(addr string, opts ...Option) *Client { return New(addr, append(opts, WithTimeout(30*time.Second))...) } ``` This compiles, reads plausibly, and is wrong. A caller who writes `NewInternal(addr, WithTimeout(2*time.Second))` gets 30 seconds. Their explicit setting is applied and then immediately overwritten. There is no error and no warning; the only symptom is a request that hangs for 30 seconds when the team expected it to fail fast at 2. The fix is to reverse the precedence. The wrapper's opinions are *defaults*, so they go first and the caller's options go last: ```go func NewInternal(addr string, opts ...Option) *Client { all := append([]Option{WithTimeout(30 * time.Second)}, opts...) return New(addr, all...) } ``` Building a fresh slice rather than appending onto the caller's is also the honest thing to do, since it cannot disturb whatever slice the caller handed you. ## Order matters between *different* fields too Most options are independent, but not all. An option that derives one field from another — say a `WithProfile("low-latency")` that sets a timeout and a backoff window together — is order-sensitive against the individual `WithTimeout`. Whichever runs last wins for the overlapping field. If you ship a composite option like that, document its precedence, or make it set only fields the caller has not already touched, which means tracking whether they were set at all. ## What to do about it as an API author Three defensible positions, and you should pick one deliberately: 1. **Last write wins, documented.** The simplest, and what almost every package does. Say so in the doc comment for the `Option` type: "Options are applied in order; later options override earlier ones." 2. **Detect and reject duplicates.** Possible if options carry an identity — for example, if `Option` is an interface or a struct with a key rather than a bare function. It costs you the simplicity of a function type and is rarely worth it. 3. **Make the composite options additive.** An option that appends to a slice field (an interceptor chain, a list of allowed hosts) does not overwrite, so ordering only decides the sequence, not the survivor. Be explicit about which of your options replace and which accumulate — a caller who expects `WithInterceptor` to accumulate but finds it replaces will lose interceptors silently. ## Testing for it The cheap regression test is to pass the same option twice with different values and assert the second one won, plus a test that a wrapper's defaults are actually overridable by a caller. Two short table tests catch the entire class of ordering bug, and they are the tests reviewers most often forget to ask for.