[swift-evolution] [Pitch] Ban the top value in Int/UInt
cc941201 at me.com
Tue Oct 18 14:10:48 CDT 2016
Perhaps not considering the current instruction set. Safe arithmetics that produce optionals would be simpler though.
> 在 2016年10月18日，14:43，Nevin Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com> 写道：
> If we went that route, could arithmetic operations still be implemented efficiently?
> On Tuesday, October 18, 2016, 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.
> 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 at swift.org
More information about the swift-evolution