> On 18 Oct 2016, at 20:46, Guoye Zhang via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> 
>> 在 2016年10月18日,15:30,David Waite <da...@alkaline-solutions.com 
>> <mailto:da...@alkaline-solutions.com>> 写道:
>> 
>> 
>>> On Oct 18, 2016, at 12:17 PM, Guoye Zhang via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@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.
>> 
>> There are two ways to do this (using Int8 for example)
>> 1. 0xFF reserved to mean nil. As this normally means -1, all negative 
>> numbers now use complements rather than two’s complement form. This breaks a 
>> lot of binary math.
>> 
>> 2. 0x80 reserved to mean nil. This is normally -128. Overflow would have to 
>> be modified in order to support this (otherwise, 127 + 1 == nil). bit 
>> padding no longer works (0x80 would expand to 0xFF80 for a Int16 with bit 
>> padding, not 0x8000)
> 
> Yes, 0x80 is better for arithmetic, checking for nil might be slower.
> 
>> 
>>> 
>>> Interacting with C/Obj-C is a major concern, but since we are already 
>>> importing some of the unsigned integers as Int which loses half the values, 
>>> one value is not such big a drawback. Alternatively, we could leave current 
>>> behavior as CInt/CUInt. Converting them to the new Int?/UInt? doesn't 
>>> generate any instructions since the invalid value already represents nil.
>>> 
>> 
>> As the appropriate integer minimum value may already be in use in C or 
>> Objective C code, I believe you would need to define a new integer types to 
>> support this sort of constrained type. 
>> 
>> Where I would see something like this be most appropriate would be for 
>> supporting a “BigNumber” type in the language, preferably as the default 
>> integer type. Ruby does this for example with Fixnum/Bignum - all values in 
>> Ruby are actually tagged pointers (where the lower bits are set to cause 
>> invalid alignment of a pointer in order to indicate it is a special case 
>> immediate value). So if the lowest bit is set, the value is a FixNum integer 
>> with a lower max/higher min than a traditional integer. On overflow, the 
>> value is promoted to be a BigNum, which is a reference to an arbitrary sized 
>> integer on the heap.
>> 
>> -DW
> 
> I would also like to see big number some day.

I've just finished the implementation of Decimal in Foundation on Linux, which 
provides for a greater (though not unlimited) space of numbers.

https://github.com/apple/swift-corelibs-foundation/pull/687

Alex
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to