Struct types
Struct semantics cover field identity, comparability, embedding syntax, tags, and literal shape; they matter beyond plain data grouping.
Canonical guidance
- a struct type is defined by its ordered field list
- embedded fields change selector and method promotion behavior
- a struct is comparable only if all of its fields are comparable
Use when
- designing data types
- checking equality legality
- reviewing embedded field exposure
Avoid
- positional literals for large exported structs
- assuming tags affect type identity or control flow by themselves
- embedding fields casually
Preferred pattern
type User struct {
ID string
Name string
}
Anti-pattern
- relying on positional struct literals across package boundaries
Explanation: This is tempting because it is short, but keyed literals survive field reordering and make reviews clearer.
Why
- struct rules affect comparability, selectors, method promotion, and literal safety all at once