How does a `//go:build` expression differ from the legacy `// +build` line in syntax and precedence?

## Two spellings of the same idea Go has had file-level build constraints for a long time, and for most of that time they were written as `// +build` lines. The syntax was compact but positional, and people got it wrong constantly. The `//go:build` form was added later as a plain boolean expression, in the same `//go:` directive family as `//go:embed` and `//go:generate`, and it is now the form you write. ## The legacy grammar, decoded A `// +build` line is a list of space-separated options; the file is built if **any** option matches. Each option is a comma-separated list of terms; an option matches if **all** its terms match. A term may be prefixed with `!` to negate it. And if the file has several `// +build` lines, **all** of them must be satisfied. So: - `// +build linux darwin` — linux OR darwin. - `// +build linux,386` — linux AND 386. - `// +build linux,386 darwin,!cgo` — (linux AND 386) OR (darwin AND NOT cgo). - two lines, `// +build linux darwin` and `// +build !cgo` — (linux OR darwin) AND NOT cgo. The two easy mistakes are reading the space as AND (it is OR) and forgetting that separate lines are ANDed. Both produce a file that compiles in the wrong set of builds, silently. ## The modern grammar `//go:build` takes one expression, using `&&`, `||`, `!` and parentheses with the usual precedence: ``` //go:build (linux || darwin) && !cgo ``` There is nothing positional left to misread, and parentheses let you write groupings the old form could not express directly. ## Placement, which is shared Both forms live in the file header: before the `package` clause, preceded only by blank lines and other line comments, and followed by a blank line so they are not absorbed into the package doc comment. Neither form does anything below the package clause — it is a plain comment there. `go vet` ships a `buildtag` analyzer that reports misplaced constraints and malformed lines, and it is the cheapest way to catch a constraint that is quietly inert. ## Precedence and gofmt When a file contains both forms, the `//go:build` line is authoritative and the `// +build` lines are ignored for the build decision. That rule matters because the two can drift apart during an edit: someone changes the expression on one line and not the other. gofmt closes that gap — it synchronises the pair, deriving the `// +build` lines from the `//go:build` expression, and adding a `//go:build` line to a file that has only the legacy form. `go vet` also reports a mismatch between them. In practice this means you edit the `//go:build` line and let the formatter deal with the rest; hand-editing a `+build` line is how the two end up disagreeing. ## What to do in a real codebase Write `//go:build` only. Keep a `// +build` line only if something in your world still builds the package with a toolchain that predates the newer form — and if you do keep it, never edit it by hand. When you inherit files carrying only the legacy syntax, running gofmt over the tree converts them mechanically, and the diff is reviewable because the boolean meaning is preserved by construction rather than by someone re-deriving it. ## The subtlety worth naming in an interview Because the legacy grammar is positional, a `+build` line cannot express every expression the new one can without splitting into multiple lines, and a negation applies to a single term only — there is no `!(a || b)` in the old form; you write `!a,!b`. That is the practical reason the newer syntax exists: the old one made complex constraints hard to write correctly and even harder to review.