> On Nov 6, 2017, at 3:46 AM, Kelvin Ma via swift-dev <swift-dev@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.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
