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

[Dave Abrahams]

on Thu Oct 20 2016, Guoye Zhang <swift-evolution at swift.org> wrote:

>>>>> 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.
>> 
>> I wouldn’t want to trade Int performance off against Int?
>> performance. I think the former is much more common.
>
> Slowing down Int is never my intent. I hope to have Int? that gives on
> par performance with Int, and the possibility to have safe arithmetics
> that doesn't impose overhead.

Swift arithmetic is already safe.

-- 
-Dave