[swift-dev] inefficient enum layout with optionals

[John McCall]

> On Nov 6, 2017, at 3:46 AM, Kelvin Ma via swift-dev <swift-dev at swift.org> wrote:
> i noticed that this enum takes up 9 bytes of storage 
> 
>   1> enum QuantizationTable  
>   2. { 
>   3.     case q8 (UnsafeMutablePointer<UInt8>),  
>   4.          q16(UnsafeMutablePointer<UInt16>)  
>   5. } 
>   6> MemoryLayout<QuantizationTable>.size
> $R0: Int = 9
> 
> but when i make it optional, it takes up 10
> 
>   7> MemoryLayout<QuantizationTable?>.size 
> $R1: Int = 10
> 
> can’t the compiler just tack the nil case onto the original enum as a third case? after all, this works fine 
> 
>   1> enum QuantizationTable  
>   2. { 
>   3.     case q8 (UnsafeMutablePointer<UInt8>),  
>   4.          q16(UnsafeMutablePointer<UInt16>),  
>   5.          none 
>   6. } 
>   7> MemoryLayout<QuantizationTable>.size
> $R0: Int = 9
> 
> the way i’m using it atm it all gets padded to 16 anyway so i don’t care that much but is this something that’s being looked at?

We could, yes.  Our experience with enum layout optimization is that it's one of those things that doesn't seem to bottom out: you can always keep improving it in one way or another.

It is an important goal of our ABI stability plan that future versions of Swift will be able to improve layouts for types that aren't required to interoperate with older versions, crucially including the private and internal types in a module.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171106/6ad0def7/attachment.html>