When would you use Struct Definition in a real project
Fast recall
Quick revision
Core answer
Practical understanding of Struct Definition.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
The three forms, in the order you should reach for them:
Keyed literal — field names explicit, any subset of fields (missing = zero):
u := User{Name: "Al", Age: 30}
v := User{Name: "Bo"} // Age: 0 — deliberateThe two properties that make it the default: self-documenting (field names in the call) and refactor-safe (reorder fields, add fields — keyed literals keep compiling with the same semantics).
Positional literal — every field, in exact order:
w := User{"Al", 30} // legal but fragileCompiles only with ALL fields present; breaks at compile time when fields are added (good) or reordered (the compiler catches the type mismatches — mostly). Its honest niche: small, frozen structs — image.Point{1, 2}, a coordinate pair that will never grow. In API code, keyed only.
Zero value — no literal at all:
var u User // Name: "", Age: 0 — executed-verifiedThe zero value is the cheapest and often the most correct: for structs designed for it (Buffer, Builder, sync types), the zero value IS the ready value — the constructor-free style the standard library proves works at scale.
The one form that doesn't exist: mandatory constructors. Go's answer is 'the zero value should be enough; constructors are for the types that can't achieve that' — so most struct creation in real Go is keyed literal or var, and New() functions appear only where invariants genuinely require setup.
When would you use Struct Definition in a real project
Direct Answer
Three: keyed (User{Name: "Al", Age: 30}) — the safe default; positional (User{"Al", 30}) — every field, in order, fragile; var u User — the zero value, every field at zero.
Deep Dive & Architecture
The keyed/positional distinction has a compile-time safety story worth knowing precisely. Positional requires: exact field count, exact order, and every field — the compiler enforces all three. So 'add a field' breaks every positional literal in the codebase with clear errors — you find them all at once. The DANGEROUS case is reordering two same-typed fields: Name/Name2, both string — a positional literal compiles fine with values silently swapped. That's why style guides ban positional except for nameless pairs.
Keyed has its own subtle rule: duplicate field keys (User{Name: "a", Name: "b"}) are a compile error in struct literals — unlike map literals where later keys win. The stricter rule exists because a struct literal is an expression evaluated once, not a mutable assignment sequence.
The zero-value form's mechanics: var u User is a declaration — the struct storage exists at declaration point (stack if it doesn't escape, heap if it does — escape analysis decides), fields already zeroed by the memory allocator (Go's allocator returns zeroed memory, so 'zero value' isn't an extra initialization pass — it's the allocation's default state, and constructors that set everything pay no extra cost for the zeroing they overwrite).
The anonymous-struct corner: var u struct{ X, Y int } — a complete type defined inline in the variable's type. It compares, it assigns, it works — and its niche is when a shape is used exactly once (a test's fixture, a JSON envelope in one handler). Anything used twice deserves a name; the unnamed struct is a local dialect, not a building block.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Struct Definition, and when would you use it?
- How would you compare Struct Definition with an alternative?
- What is a common mistake when using Struct Definition?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.