> 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