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

[Dave Abrahams]

on Wed Oct 19 2016, Guoye Zhang <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.

For the record, we made no explicit choice to avoid optional integers.
We'd use them wherever it was appropriate.

>>> 
>>> 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.
>
>>> 
>>> 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

-- 
-Dave