The field order of structs is unspecified by default, to allow, e.g. reordering to the smallest size, or even randomising for security/fuzz testing.
One can opt-in to a fixed in-order layout with `#[repr(C)]` and even avoid padding for such a struct with `#[repr(C, packed)]`.
NB. in general it is impossible to pack a struct perfectly manually, e.g. generic structs can have their order for minimal size change depending on what types they're used with. It can even be somewhat platform specific, with e.g. pointers changing size/alignment on 32-bit vs. 64-bit computers (although pointers probably aren't problematic, since they're switching between two adjacent classes).
I know better than the compiler how my data is used. It is really simple as that. I can optimize with the totality of the program in mind while the compiler optimizes on heuristic like `order largest to smallest`. So yes, the compiler is doing it sub-optimally. Not to mention the repetitious hell it creates when writing C bindings, or memory-mapping structures, and so on and so forth.
In the end, however, my reservations are mostly due to a "get off my lawn" mentality.
Only when the difference in performance is end-user discernible. I do make sure the code is well crafted in those bounds though. There's no _valid_ excuse for crafting ugly code.
Coincidently my stuffed toy that I have kept throughout my childhood was named "Mel the Pal." I just noticed the irony of that. :)
The compiler can't know exactly how I intend the data to be read or written to at runtime. You generally don't want to read and write to the same cache line at a time.
That guarantees the same layout that C would have for that struct. There is also #[repr(packed)] which puts things as close as possible without alignment, and then you can insert padding manually with fields of type [u8; N] where N is the number of bytes.
This is great for the general programmer (someone who is not knowledgeable or caring about details like this.)
Unfortunately, this blows for people who do (someone like me.)