on Wed Oct 19 2016, Kevin Nattinger <swift-evolution@swift.org> wrote:
>> 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, For the record, the interface of the stdlib is not 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. That's not true; we made several implementation changes based on that extra space. We never felt there was a good reason to consider it in making API choices, though. >>> >>>> >>>> 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? Yes, that's the core of the issue. >> >>>> >>>> So what do you think? Can we break C compatibility a bit for better Swift >>>> types? >>> >>> >>> Well it’s not just C compatibility, it’s underlying processor >>> compatibility. And actually, yes, I think C compatibility is vastly >>> more important than being able to make your [Int?] arrays smaller >>> considering that full 2’s complement numbers is what the OS calls >>> and libc calls are expecting. >>> >> Yes, that is also the result Joe said of their previous internal >> discussion. Anyway, I know this is improbable, and I'm just glad >> that this possibility is considered. >> >> - Guoye >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution