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.
> On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution
> <email@example.com> 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
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