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.). 
- I strongly dislike the idea of special-casing optionals just to save a Byte. 
- 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.
- 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 
> <> 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.

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

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

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

> - Guoye
> _______________________________________________
> swift-evolution mailing list

swift-evolution mailing list

Reply via email to