> 在 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 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. >> >> 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
