Optimizing Rust Struct Size
This is pretty cool!<p>A few thoughts from a C&#x2F;C++ perspective (I have only tinkered briefly with Rust):<p>- This effectively makes the optimization algorithm part of the Rust ABI; you cannot change (or even fix a bug in) the layout algorithm without breaking binary compatibility. The simpler the algorithm, the less of a concern this would be.<p>- In a systems programming context, you don&#x27;t always want to optimize a struct for size. You may reorder a large struct to optimize for other properties like cache coherency, or because you have to match a memory layout specified by other software or even hardware. Obviously one can still use &#x27;repr(C)&#x27; for these cases.<p>- Related to the prior point, it&#x27;s a little disconcerting that adding a field to the end of a struct declaration can completely change the layout. Sometimes in C&#x2F;C++ land programmers &#x27;cheat&#x27; by adding fields to the end of a struct that&#x27;s used in multiple modules, and initially only recompile the modules that need to know about the new field. (For purposes of compilation expediency&#x2F;iteration speed.)<p>- This seems like it may violate the principle of least-surprise pretty badly. As long as we continue to use debuggers and have crash dumps, systems programmers will sometimes need to look at raw memory data and figure out what the structure is. If the field layout isn&#x27;t easily predicted, that may be very difficult. In my experience there can be huge benefits to minimizing the number of opaque&#x2F;hard-to-predict transformations between authored data and its final representation. (In this case, the struct declaration and its final memory layout.)<p>For these reasons it seems like this auto-reorder behavior might be better as an opt-in rather than opt-out behavior (which it sounds like it is.) Regardless, it&#x27;s still a feature I wish I could have in C++ from time to time!