Does the Go compiler reorder struct fields to eliminate padding?

## The answer and the reason The gc compiler assigns offsets by walking the fields in declaration order and padding as alignment demands. It does not sort them, and it does not reorder them under optimisation. Two structs with the same field types in different orders are genuinely different types with different layouts and potentially different sizes. The Go specification is deliberately quiet about layout — it says only that an implementation may insert padding, and it pins down the relationship between a field's address and `unsafe.Offsetof`. But no Go implementation reorders, and a great deal of working software would break if one started: - **cgo** relies on a Go struct's fields lining up with the C declaration it mirrors. - **`unsafe.Offsetof`** is used to reason about layouts and would become unpredictable. - **`encoding/binary`** and `encoding/json` walk fields in declaration order, so the output of a program would depend on the compiler's mood. - **Reviewability** — the size of a type is a function of code you can read, not of an optimiser pass you cannot see. This is a real design difference between languages. Rust's default `repr(Rust)` explicitly permits the compiler to reorder fields, and it does, which is why a Rust programmer moving to Go is often surprised that field order shows up in `unsafe.Sizeof`. C and C++ keep declaration order like Go, but they hand you `#pragma pack` and `_Alignas` to override the rules; Go has no equivalent, so the C programmer's other habit — packing a struct until its bytes are the wire format — does not port either. ## What you can control, and what you cannot You can: - **Reorder fields**, declaring them in descending order of alignment. This is the whole toolkit for removing interior padding. - **Choose narrower types.** A status that fits in a `uint8` should not be an `int`. Two `int32` timestamps beat two `int64`s if the range allows it. - **Split the type.** If a hot loop touches two fields out of twenty, pulling those two into their own struct, or holding parallel slices, cuts far more memory traffic than any amount of padding removal. You cannot: - **Force packing.** There is no way to make a struct with an `int64` field occupy a size that is not a multiple of 8. - **Ask for extra alignment.** There is no over-alignment attribute; 8 is the ceiling in the gc toolchain. - **Rely on layout as a serialisation format.** If bytes must match a fixed wire layout, encode field by field with `encoding/binary` — a translation you can read and test — rather than reinterpreting a struct's memory and hoping the padding matches. ## The porting mindset to correct An engineer arriving from a language whose compiler compacts structs will write declarations in the order the schema or the domain suggests, assume the compiler tidies up, and never look at the size. An engineer arriving from C will do the opposite: order the fields carefully, then reach for a packing pragma that does not exist, and be tempted to cast the struct's memory into a byte slice. The Go position sits between them. Order is yours, padding is automatic and unavoidable, and the bytes on the wire come from an encoder rather than from memory. The practical habit that follows is small: for a type you expect to exist in very large numbers, write down `unsafe.Sizeof` of it once, and if the number is embarrassing, reorder the declaration and leave a comment saying why the fields are grouped the way they are. For everything else, declare fields in whatever order reads best — a struct you allocate a handful of times owes nobody an optimisation.