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

[Dave Abrahams]

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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave