> 在 2016年10月19日，11:43，Kevin Nattinger <sw...@nattinger.net> 写道： > >> >> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> 在 2016年10月19日，07:10，Jeremy Pereira <jeremy.j.pere...@googlemail.com> 写道： >>> >>> >>>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>>> <swift-evolution@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. > > I’ve only needed an array of optionals once, maybe twice. I don’t think > arrays of optionals are widely used to begin with, and the reason there are > few optional integers in the stdlib is because the interface is from objc, > which doesn’t have optionals. I doubt any thought at all was given in > designing the standard library to the extra space for an optional. > Swift stdlib is independent from objc. Currently, "Int?" storage has a tradeoff between less space (n + 1 bytes) and unaligned access, and more space (n * 2 bytes) and fast access. Neither of them is optimal.
>>> >>>> >>>> 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. > > In my experience, ints are used orders of magnitude more often than optional > int?s. Why optimize for the rare case? > If we were to have safe arithmetic that produces optionals, or lenient subscript, it is important to have efficient optional integers. I do agree that Int slowing down is unacceptable. - Guoye _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
