[swift-dev] [swift-evolution] Possible bug with arithmetic optional comparison ?

[Jordan Rose]

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

Best,
Jordan


> On May 24, 2016, at 09:07, Robert Widmann via swift-evolution <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> のメッセージ:
> 
>> 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
>> https://lists.swift.org/mailman/listinfo/swift-dev
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160524/baa602c9/attachment.html>