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

[Joe Groff]

> On Oct 20, 2016, at 8:25 AM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 20 Oct 2016, at 15:51, Martin Waitz via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Hello,
>> 
>>> It's just that a common data type wasting almost half the space seems inefficient. I guess this is also the reason why they didn't adopt optional integers widely in stdlib.
>> 
>> When someone is really interested in fitting an optional integer into one machine word,
>> then the best way would be to use a smaller integer type (e.g. Int32 instead of Int64).
>> These also can be mapped well into Enums (a single reserved value does not help at all here).
>> 
>> There are some almost 64-bit integers (Builtin.Int60 .. Builtin.Int63).
>> Maybe something like this could also be provided for normal use?
> 
> I mentioned earlier, but it'd be nice to see the ability to specify arbitrary width integers up to the word size. I myself have a type where I could more efficiently use a 7-bit integer, to offset the extra bit for an optional, but currently have to just use a byte (or else use some kind of awkward trickery). Presumably all of the weird builtin sizes are implemented somehow to as 64-bit operations, it's just the size that differs.
> 
> I'm not very knowledgeable on the subject though, so I'm not sure if I'd be the best person to write up a proposal, though I could always keep it high level.

This is supported by LLVM and exposed through the low-level 'Builtin' module in Swift, though the standard library doesn't expose it to user code. If you define an enum { case Foo(Builtin.Int63), Bar }, Swift already knows how to use the spare bits in an Int63 to avoid spilling extra tag bits.

-Joe