> Le 18 oct. 2016 à 21:09, Charlie Monroe via swift-evolution
> <email@example.com> a écrit :
> Talking about bridging - my guess is that it would mess with NSNotFound which
> still has legit use cases even in Swift (when dealing with ObjC APIs) and is
> defined as NSIntegerMax at this moment, though its usage is slowly on the
Bridge the API that may return NSNotFound to return optional. It would work
perfectly well as the nil optional and NSNotFound would have the same binary
> But there are still many many APIs (mostly C-based) that define some "magic"
> constants as (unsigned)(-1), which I believe this would mess with.
> Given this, it would IMHO have huge consequences for backward compatiblity.
>> On Oct 18, 2016, at 8:54 PM, Kevin Nattinger via swift-evolution
>> <firstname.lastname@example.org> wrote:
>> 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
>> - 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
>>> <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
>>> 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
>>> 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
> swift-evolution mailing list
swift-evolution mailing list