<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Nov 6, 2017, at 3:46 AM, Kelvin Ma via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="">i noticed that this enum takes up 9 bytes of storage <br class=""><span style="font-family:monospace,monospace" class=""><br class=""> 1> enum QuantizationTable <br class=""> 2. { <br class=""> 3. case q8 (UnsafeMutablePointer<UInt8>), <br class=""> 4. q16(UnsafeMutablePointer<UInt16>) <br class=""> 5. } <br class=""> 6> MemoryLayout<QuantizationTable>.size<br class="">$R0: Int = 9</span><br class=""><br class=""></div>but when i make it optional, it takes up 10<br class=""><div class=""><br class=""><span style="font-family:monospace,monospace" class=""> 7> MemoryLayout<QuantizationTable?>.size <br class="">$R1: Int = 10<br class=""></span><br class=""></div><div class="">can’t the compiler just tack the <span style="font-family:monospace,monospace" class="">nil</span> case onto the original enum as a third case? after all, this works fine <br class=""></div><div class=""><br class=""></div><div class=""><span style="font-family:monospace,monospace" class=""> 1> enum QuantizationTable <br class=""> 2. { <br class=""> 3. case q8 (UnsafeMutablePointer<UInt8>), <br class=""> 4. q16(UnsafeMutablePointer<UInt16>), <br class=""> 5. none <br class=""> 6. } <br class=""> 7> MemoryLayout<QuantizationTable>.size<br class="">$R0: Int = 9</span><br class=""></div><div class=""><br class=""></div><div class="">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?<br class=""></div></div></div></blockquote><div><br class=""></div></div>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.<div class=""><br class=""></div><div class="">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.<br class=""><div class=""><br class=""></div><div class="">John.</div></div></body></html>