Love this, and I'm glad the conclusion made exactly the point I was about to bring up in my comment:<p>> If Rust had guaranteed that the memory layout of an enum is always a tag followed by a union then it wouldn’t be possible to make this optimization without breaking somebody’s code. Instead, the compiler retains the freedom to optimize the layout of your types, and your code will automatically be more memory efficient, simply by updating to a newer version of the compiler.<p>Having things be lower-level/more-explicit/more-exposed-details is often seen as a win for optimization at the cost of ergonomics. But it's <i>not even always a win for optimization</i>. What it really means is putting more things in the hands of developers, instead of the compiler/runtime, which may be good or it may be bad.<p>One of the most brilliant things about Rust is exactly where it's chosen to draw the contours of that delicate line between explicitness and opaqueness
There are further enum layout optimization implemented: <a href="https://github.com/rust-lang/rfcs/issues/1230" rel="nofollow">https://github.com/rust-lang/rfcs/issues/1230</a>, or is being worked: <a href="https://github.com/rust-lang/rust/issues/46213" rel="nofollow">https://github.com/rust-lang/rust/issues/46213</a>. These simple ideas on the surface sometimes can be very hard to implement in reality due to various compiler internal complexity. It is fascinating that these ideas are getting implemented in rustc so that we see tangible benenfits in real life.