[swift-evolution] [Pitch] Ban the top value in Int/UInt

[Benjamin Spratling]

> On Oct 18, 2016, at 1:54 PM, Kevin Nattinger via swift-evolution <swift-evolution at 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?

-Ben