> On Oct 18, 2016, at 1:54 PM, Kevin Nattinger via swift-evolution
> <firstname.lastname@example.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
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