[swift-dev] [swift-evolution] Possible bug with arithmetic optional comparison ?
Joe Pamer
jpamer at apple.com
Tue May 24 13:14:16 CDT 2016
> On May 24, 2016, at 11:03 AM, Chris Lattner <clattner at apple.com> wrote:
>
>
>> On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>
>> I wouldn’t phrase it this way. “nil” could just as easily been above all of the integers.
>>
>> We added overloads for < and friends that took optionals so that you could sort an array by passing < and get something reasonable out without having to provide your own comparison function, but you’re not the first to find it counterintuitive. We could consider removing it (going through the Swift Evolution Process <https://github.com/apple/swift-evolution/blob/master/process.md>).
>
> One of the ideas that Joe Pamer has been discussing is whether the implicit promotion from T to T? should be disabled when in an operator context. Doing so would fix problems like this, but making the code invalid.
>
> Joe, is this something that you think will come up for discussion in the Swift 3 timeframe?
Yes - I believe so. I’ve been collecting my notes on the topic, with the hopes of getting a pitch out to swift-evolution soon.
- Joe
>
> -Chris
>
>
>>
>> Best,
>> Jordan
>>
>>
>>> On May 24, 2016, at 09:07, Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> Behaves as intended, albeit counterintuitively.
>>>
>>> [~ indicates appropriate coercion]
>>>
>>> 1) (nil : Optional<T ~ Int>) == (0 : Int ~ Optional<Int>) false because nil is the lower bound of all possible integers.
>>> 2) (nil : Optional<T ~ Int>) < (0 : Int ~ Optional<Int>) true for reasons above
>>> 3) (nil : Optional<T ~ Int>) > (0 : Int ~ Optional<Int>) false for reason above.
>>>
>>> ~Robert Widmann
>>>
>>> 2016/05/24 2:27、Yaman JAIOUCH via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> のメッセージ:
>>>
>>>> nil == 0 // false
>>>> nil < 0 // true
>>>> nil > 0 // false
>>>>
>>>> Is this a potential bug or an intended behavior ?
>>>> _______________________________________________
>>>> swift-dev mailing list
>>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160524/2cabdd27/attachment.html>
More information about the swift-dev
mailing list