src/docs/large_enum_variant.txt

   1 ### What it does
   2 Checks for large size differences between variants on
   3 `enum`s.
   4
   5 ### Why is this bad?
   6 Enum size is bounded by the largest variant. Having one
   7 large variant can penalize the memory layout of that enum.
   8
   9 ### Known problems
  10 This lint obviously cannot take the distribution of
  11 variants in your running program into account. It is possible that the
  12 smaller variants make up less than 1% of all instances, in which case
  13 the overhead is negligible and the boxing is counter-productive. Always
  14 measure the change this lint suggests.
  15
  16 For types that implement `Copy`, the suggestion to `Box` a variant's
  17 data would require removing the trait impl. The types can of course
  18 still be `Clone`, but that is worse ergonomically. Depending on the
  19 use case it may be possible to store the large data in an auxiliary
  20 structure (e.g. Arena or ECS).
  21
  22 The lint will ignore the impact of generic types to the type layout by
  23 assuming every type parameter is zero-sized. Depending on your use case,
  24 this may lead to a false positive.
  25
  26 ### Example
  27 ```
  28 enum Test {
  29     A(i32),
  30     B([i32; 8000]),
  31 }
  32 ```
  33
  34 Use instead:
  35 ```
  36 // Possibly better
  37 enum Test2 {
  38     A(i32),
  39     B(Box<[i32; 8000]>),
  40 }
  41 ```