Possible bug with arithmetic optional comparison?


(Yaman JAIOUCH) #1

nil == 0 // false
nil < 0 // true
nil > 0 // false

Is this a potential bug or an intended behavior ?


(Robert Widmann) #2

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Jordan Rose) #3

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #4

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?

-Chris

···

On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

Best,
Jordan

On May 24, 2016, at 09:07, Robert Widmann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Joe Pamer) #5

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

···

On May 24, 2016, at 11:03 AM, Chris Lattner <clattner@apple.com> wrote:

On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

-Chris

Best,
Jordan

On May 24, 2016, at 09:07, Robert Widmann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(Chris Lattner) #6

Awesome, thanks!

-Chris

···

On May 24, 2016, at 11:14 AM, Joe Pamer <jpamer@apple.com> wrote:

On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@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.


(Yaman JAIOUCH) #7

I'd like to pitch it out to swift-evolution but I'm not sure to fully
understand the proposed solution of "disabling implicit promotion from T to
T?"

Does it mean that the following code won't work anymore?
let a: Int? = nil
let b: Int = 25
a < b // does not compile anymore

If so, I'm not sure it fixed our main problem because the following would
still work as currently:
let a: Int? = nil
let b: Int? = 25
a < b // return true

Result is still counterintuitive and could lead to misuses if the above
behavior is not specifically known by a developer.

···

2016-05-24 20:35 GMT+02:00 Chris Lattner <clattner@apple.com>:

On May 24, 2016, at 11:14 AM, Joe Pamer <jpamer@apple.com> wrote:

On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev < > swift-dev@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.

Awesome, thanks!

-Chris