> 在 2016年10月18日,14:54,Kevin Nattinger <sw...@nattinger.net> 写道:
> 
> Part of the beauty of how optionals are implemented in Swift is that the 
> compiler doesn’t have to do any magic w.r.t. optionals besides a bit of 
> syntactic sugar (`T?` -> `Optional<T>`, `if let x` -> `if let case .some(x)`, 
> auto-boxing when necessary, etc.). 
Swift compiler is already using magic for optional pointers. Invalid address 
are used for optional pointers. `MemoryLayout<ManagedBuffer<Int, 
String>???>.size` is still 8.

> - I strongly dislike the idea of special-casing optionals just to save a 
> Byte. 
Not just a byte, it saves half the space in arrays. [Int?] is double the size 
of [Int].

> - Optionals were presented as explicitly removing the need for such a 
> sentinel value in the first place.
> - There are reasonable cases where such a bit pattern is reasonably necessary 
> to the data (e.g. bit fields, RSSI, IP addresses, etc.) and removing that 
> value would force ugly workarounds and/or moving to a larger int size because 
> of an ill-advised implementation detail.
I agree. Perhaps we just special case Int, and keep UInt intact for bitwise 
operations?

> - If performance or memory is so critical to your specific use case, use a 
> non-optional and your own sentinel value. It’s likely no less efficient than 
> having the compiler do it that way.
> 
> (more below)
> 
>> On Oct 18, 2016, at 11:17 AM, 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.
>> 
>> 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,
> 
> I’d argue those imports are bugs and should be fixed to the correct 
> signedness.

It is for indexing Swift array easier.
> 
>> one value is not such big a drawback.
> 
> Unless you happen to need all $width bits.
> 
>> 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.
> 
> Trying to convert an invalid value like that crashes in most of Swift.

CInt to Optional<Int> would not crash because invalid value becomes nil.
> 
>> 
>> With optional integers improved, we could implement safe arithmetic 
>> efficiently, or even revisit lenient subscript proposals,
> 
> I don’t see how losing a particular value has any effect on either of those, 
> but it’s possible there’s some theory or implementation detail I’m not aware 
> of.

Unaligned memory access would be a huge performance hit.
> 
>> 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?
> 
> We can, and do. C.f. structs, non-@objc classes, and enums not 
> RawRepresentable with a C-compatible entity. If anything, this breaks 
> compatibility with the rest of Swift.

I don't want that, either.
> 
>> 
>> - 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

Reply via email to