[swift-evolution] [Pitch] Ban the top value in Int/UInt
dabrahams at apple.com
Wed Oct 19 11:57:05 CDT 2016
on Wed Oct 19 2016, Kevin Nattinger <swift-evolution at swift.org> wrote:
>> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution <swift-evolution at swift.org> wrote:
>>> 在 2016年10月19日，07:10，Jeremy Pereira <jeremy.j.pereira at googlemail.com> 写道：
>>>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution <swift-evolution at swift.org> wrote:
>>>> Currently, Swift Int family and UInt family have compact
>>>> representations that utilize all available values, which is
>>>> inherited from C. However, it is horribly inefficient to implement
>>>> optional integers. It takes double the space to store [Int?] than
>>>> to store [Int] because of alignment.
>>> Is this a general problem with Swift? Are lots of people complaining that they are running out of
> space for their Optional<Int> arrays?
>> 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.
> I’ve only needed an array of optionals once, maybe twice. I don’t
> think arrays of optionals are widely used to begin with, and the
> reason there are few optional integers in the stdlib is because the
> interface is from objc,
For the record, the interface of the stdlib is not from objc.
> which doesn’t have optionals. I doubt any thought at all was given in
> designing the standard library to the extra space for an optional.
That's not true; we made several implementation changes based on that
extra space. We never felt there was a good reason to consider it in
making API choices, though.
>>>> I propose to ban the top value in Int/UInt which is 0xFFFF... in
>>>> hex. Int family would lose its smallest value, and UInt family
>>>> would lose its largest value. Top value is reserved for nil in
>>>> optionals. An additional benefit is that negating an Int would
>>>> never crash.
>>> Well the “top value” for signed ints would have to be 0x8000... not
>>> 0xffff... which is the representation of -1. The top value for
>>> unsigned ints cannot be banned because unsigned integers are often
>>> used as bit fields either directly or in OptionSets.
>>> Furthermore, how would the semantics of &+ and &- be affected? What about the performance of
> those two operators?
>> I was originally going for the symmetry between Int and UInt as in
>> compatible bit patterns. Now that I think of it, UInt is commonly
>> used for bitwise operations, and it doesn't make sense to optimize
>> for "UInt?" which is uncommon. So I agree that 0x80... is better.
>> Int performance would surely suffer because of current instruction sets, but Int? would improve.
> In my experience, ints are used orders of magnitude more often than
> optional int?s. Why optimize for the rare case?
Yes, that's the core of the issue.
>>>> So what do you think? Can we break C compatibility a bit for better Swift types?
>>> Well it’s not just C compatibility, it’s underlying processor
>>> compatibility. And actually, yes, I think C compatibility is vastly
>>> more important than being able to make your [Int?] arrays smaller
>>> considering that full 2’s complement numbers is what the OS calls
>>> and libc calls are expecting.
>> Yes, that is also the result Joe said of their previous internal
>> discussion. Anyway, I know this is improbable, and I'm just glad
>> that this possibility is considered.
>> - Guoye
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution