proposal: spec: define/imply memory layout of tagged struct fields (original) (raw)

This is half-baked idea that needs more thought, written down so it doesn't get forgotten.

Currently, the spec does not specify how struct fields are laid out in memory (e.g. source order, or optimally packed, or any other order). That is, theoretically, a compiler is free to optimize the layout. However, currently all (?) compilers lay out struct fields in source order, possibly wasting significant amounts of space due to padding (struct internal fragmentation).

It is not unlikely that code depends on this property.

Instead of requiring all structs to follow source order layout of fields, we could say that structs with tagged fields are the ones that are laid out in source order. Here are some variants of the same idea:

• struct fields are laid out in source order if there's at least one field that's tagged
• struct fields are laid out in source order if all fields are tagged
• tagged struct fields are laid out in source order (relative to other tagged fields), but untagged fields are free to be where the compiler decides
• tagged fields are laid out contiguously, in source order, at the beginning (or the end) of the struct; untagged fields are in compiler-determined order at the opposite end (and the end or beginning) of the struct