In that case, NSNotFound can be seamlessly converted to nil. Those magic might 
also be better represented in optionals. It is indeed bad for compatibility 

- Guoye

> 在 2016年10月18日,15:09,Charlie Monroe <> 写道:
> 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 
> decline...
> 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 
>> <> 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 
>> 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

swift-evolution mailing list

Reply via email to