> On Oct 18, 2016, at 1:54 PM, Kevin Nattinger via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Part of the beauty of how optionals are implemented in Swift is that the 
> compiler doesn’t have to do any magic w.r.t. optionals 
> - I strongly dislike the idea of special-casing optionals just to save a 
> Byte. 
It is nice that enums are generic, but enums do know about extra bits laying 
around and compact themselves if possible.

As I understand it, It would actually save 7.875 bytes of storage.  When the 
next stored value is Int-alignment, 7 extra bytes beyond the optional marking 
are used up.  For code which uses several Int? in a row, it doubles the 
required memory - as I understand it.

>  If anything, this breaks compatibility with the rest of Swift.
Yep.  So if it’s gonna be done, now's the time to do it.

An alternative is to introduce 63-bit and 31-bit integer types just to play 
nice with optionals.  Or to play nice with more than 2 enum cases, why not 
introduce 56- and 24-bit Int/UInt? and leave space for many cases.  Of course, 
there’s an added performance penalty when working with the mask, right?  Maybe 
opting in to these odd byte sizes lets the developer know that.

When working with Int / UInt the developer is not usually specifying “Int64”, 
but instead saying "big integer, oh, 64-bits, that should handle it.”  When 
they say “it might be 32-bits, uh oh”, then they explicitly specify Int64.  So 
maybe "typealias Int = Int56" solves this problem.

There was talk of adding a variable-byte-sized Integers to the built-ins in the 
future.  Maybe these changes could work together with that?


swift-evolution mailing list

Reply via email to