[mikebenfield]

> plus 8 bytes for the tag

The tag can often be stored inline in the data, so doesn't necessarily require extra space.

> because they always take up as much space as the largest wrapped type

Yeah... but what's the alternative?

[estebank]

The alternative would be for Rust to generate machine code for the following

    enum Foo {
        Bar,
        Qux([i32; 1024]),
    }

as if the user had written

    enum Foo {
        Bar,
        Qux(Box<[i32; 1024]>),
    }

I don't think it's a good idea to do that kind of silent transformation, instead teach the developer about their options. That way the application's performance doesn't suddenly shift after changing a few parts of unrelated code that accidentally causes some threshold to be crossed that changes the performance characteristics of binary being produced.

Today, clippy does what I think is the right thing: it teaches the user

  warning: large size difference between variants
   --> src/main.rs:1:1
    |
  1 | / enum Foo {
  2 | |     Bar,
    | |     --- the second-largest variant carries no data at all
  3 | |     Qux([i32; 1024]),
    | |     ---------------- the largest variant contains at least 4096 bytes
  4 | | }
    | |_^ the entire enum is at least 4100 bytes
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#large_enum_variant
    = note: `#[warn(clippy::large_enum_variant)]` on by default
  help: consider boxing the large fields to reduce the total size of the enum
    |
  3 |     Qux(Box<[i32; 1024]>),
    |         ~~~~~~~~~~~~~~~~

[chriskrycho]

When you combine this with rust-analyzer's hints for the sizes of items, it makes it much easier to spot this kind of stuff and resolve it automatically while developing, too.