In Go, what is the difference between a keyed struct literal and a positional one?

## The two forms A composite literal builds a value of a struct, array, slice or map type by listing its elements inside braces. For a struct there are exactly two ways to write the element list, and Go does not let you blend them. **Positional.** `User{1, "ada", true}` binds the first value to the first declared field, the second to the second, and so on. You must supply a value for *every* field, in the order the fields are declared in the type. **Keyed.** `User{ID: 1, Name: "ada"}` names the field each value belongs to. Keys may appear in any order, and any field you omit is set to its zero value — `0`, `""`, `false`, or nil for a pointer, slice, map, channel, function or interface field. That is why `User{}` is legal and gives you an all-zero `User`. Mixing is a compile error: `User{ID: 1, "ada"}` does not build. A literal is either all keyed or all positional. One extra rule bites across package boundaries: you cannot set an unexported field of a struct that belongs to another package, and you cannot skip it either. So a positional literal of an imported struct type that has any unexported field simply does not compile — keyed is your only option there. ## What actually breaks, and how loudly The usual one-line justification for keyed literals — *"otherwise adding a field silently shifts your values"* — is not quite right, and knowing why is what separates a memorised rule from an understood one. * **A field is added.** The positional literal now has too few values, and the compiler rejects it. That is noisy, mechanical churn: every construction site in the codebase must be edited. Annoying, but safe. * **Two same-typed fields are reordered** (or one field is repurposed into another of the same type). The literal still has the right number of values, and every value still type-checks. It compiles, and every field now holds the neighbouring field's data. Nothing warns you. This is the silent failure, and it survives the test suite whenever the tests build their fixtures the same positional way. * **A field's type changes.** Usually a compile error, so it behaves like the first case. So the honest statement is: positional literals turn a struct's *declaration order* into part of its public contract, and Go gives you no way to signal that the contract changed. ## The tooling that catches it `go vet` ships a `composites` analyzer that reports composite literals of struct types **imported from another package** that use unkeyed fields. It deliberately does not flag literals of types declared in the same package, on the theory that you can see and fix those together. Since `go test` runs a subset of vet automatically, an unkeyed literal of a dependency's type tends to surface the first time somebody runs the tests. Treat that report as a real defect, not noise: it names exactly the case where the fields can move without you noticing. ## Generated code and review This matters most where literals are produced in bulk rather than typed. A code generator that emits Go source — turning a schema or a template with placeholders into `[]Config{ ... }` — is emitting hundreds of construction sites at once. If the template writes positional literals, a single reordering upstream silently rewrites every generated record; if it writes keyed literals, the worst case is a compile error in one place. The same reasoning applies to a reviewer reading a pull request: `Rule{true, false, 3}` is unreviewable at a glance, because nothing on screen says which flag is which, whereas `Rule{Enabled: true, DryRun: false, Retries: 3}` reads without opening the type. A related trick: `fmt.Printf("%#v\n", v)` prints a value in Go syntax, and for a struct it prints the **keyed** form, e.g. `main.User{ID:1, Name:"ada"}`. That output can be pasted straight into a test as a fixture, and it is a quick way to confirm that a value you built really has the fields you meant, especially when you inherited a positional literal and want to see what it actually produced. `%+v` is the lighter version, printing `{ID:1 Name:ada}` without the type name and quoting. ## When positional is acceptable Small, closed types that you own and that will never grow — a two-field coordinate pair is the standard example, and the standard library itself constructs such types positionally. Even there, the cost of keys is a few characters, and the reader benefit is immediate. The practical rule most Go teams settle on: keyed everywhere by default; positional only inside the package that declares the type, and only for types whose fields are obvious from the type name.