Perhaps not considering the current instruction set. Safe arithmetics that 
produce optionals would be simpler though.

- Guoye

> 在 2016年10月18日,14:43,Nevin Brackett-Rozinsky 
> <> 写道:
> If we went that route, could arithmetic operations still be implemented 
> efficiently?
> Nevin
> On Tuesday, October 18, 2016, Guoye Zhang via swift-evolution 
> <> 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.
> 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.
> 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.
> With optional integers improved, we could implement safe arithmetic 
> efficiently, or even revisit lenient subscript proposals, but they are not in 
> the scope of this pitch. Float/Double optionals could also be improved with 
> the similar idea. (Isn't signaling nan the same as nil) Nested optionals such 
> as "Int??" are still bloated, but I don't think they are widely used.
> So what do you think? Can we break C compatibility a bit for better Swift 
> types?
> - Guoye
> _______________________________________________
> swift-evolution mailing list

swift-evolution mailing list

Reply via email to