compare Struct Literal And Fields with an alternative
Fast recall
Quick revision
Core answer
Practical understanding of Struct Literal And Fields.
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
An anonymous struct is the type spelled where a name would go:
var point struct {
X, Y int
}
point.X = 1
// or as a literal with the type inline
envelope := struct {
Data []string `json:"data"`
Next string `json:"next"`
}{Data: items, Next: cursor}It behaves exactly like a named struct: comparable if its fields are, literal-constructible, JSON-marshalable via tags, nestable. What it lacks is only the name — you cannot refer to the type again; every reuse must respell it identically (and two identical anonymous struct spellings ARE the same type — structural identity).
The honest uses, each 'used exactly once in exactly this shape':
- 1JSON envelopes in one handler — the wire shape that exists nowhere else; spelling it inline keeps the schema next to its use.
- 2Test fixtures — table-driven tests often want a per-test struct of (name, input, want); a named type adds an indirection the test file doesn't need.
- 3Grouping related local variables — a handful of related locals in one function (x, y, count) — a lighter alternative to a named struct when the grouping never escapes.
The line where anonymous stops being right: the SECOND use. The moment a shape appears twice, the name pays for itself (readability, refactorability, a doc target); respelling the anonymous type in two places is a copy-paste type with no identity linking them — the next maintainer can't tell they're 'the same' except by diffing field lists.
And the anti-use: anonymous structs as public API — parameters, returns, exported fields. Callers must respell your inline type to construct arguments — an ergonomics tax, and the type's identity being structural means any field addition is a breaking change at every spell site. Public surfaces get named types; anonymous stays inside functions and test files.
compare Struct Literal And Fields with an alternative
Direct Answer
A struct type defined inline in a variable or field declaration — no name, used once. Niche: one-off shapes — test fixtures, JSON envelopes, nested config — never a reusable type.
Deep Dive & Architecture
The structural-identity mechanics: anonymous struct types are compared field-by-field (names, order, types, and tags — yes, tags participate in type identity). Two identical spellings in different functions denote the SAME type — assignment between them compiles. That's why the 'reuse by respelling' pattern type-checks: the language sees one type; the humans see two copies. The tension is the whole argument for naming at second use — the language won't force it, so discipline must.
The empty anonymous struct — struct{} — is a special case with real jobs: it occupies ZERO bytes (unsafe.Sizeof(struct{}{}) == 0), which is why it's the element type of sets (map[string]struct{} — the idiomatic set: no value storage, just keys) and the payload of done channels (chan struct{} — the channel exists for its close, carries no data; struct{} says so IN the type). A named struct{} would be ceremony; the anonymous one is a term of art.
The embedding corner: an anonymous struct can embed... a named struct (promotion applies — the fields arrive), or another anonymous struct. The JSON nesting patterns sometimes use this — envelope-in-envelope — and the same 'second use' rule applies with more force: two-level anonymous structures lose readers fast. The test: if a reader must count braces to know where they are, the shape needed a name an hour ago.
The standard library's calibration: anonymous structs appear in tests and marshaling glue throughout the stdlib's own test files, and almost never in exported API — the ecosystem's practice matches the rule exactly. Interviewers use this question to check whether a candidate knows the language supports it (not trivia) and has the judgment about where it belongs (the discriminator) — the answer above gives both.
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 Literal And Fields, and when would you use it?
- When would you use Struct Literal And Fields in a real project?
- What is a common mistake when using Struct Literal And Fields?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.