> On Oct 20, 2016, at 8:25 AM, Haravikk via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On 20 Oct 2016, at 15:51, Martin Waitz via swift-evolution
>> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
