Such comparisons with optionals can result in hard to find bugs.
For example consider:
let f = x < 5 // x is of type Int? and may be nil
The proposed ? suffix would be used as follows and makes the possibility of nil very clear:
let f = x? < 5
Agreed — or, I think, these operators could/should simply be removed.
I filed <rdar://22833869> about this a while ago, which was marked as
Duplicate/<rdar://16966712>.
Summary:
This returns true:
(nil as Int?) < 0
This also returns true, which makes even less sense:
(nil as Int?) < Int.min
Expected Results:
nil < 0, nil > 0, and nil == 0, should all be false. nil != 0 should be true.
Alternatively, just *don't* provide < and > operators that accept optional arguments.
Actual Results:
nil < 0 is true. Others are as expected.
See also: https://twitter.com/jtbandes/status/646914031433871364
Jacob
···
On Thu, Dec 3, 2015 at 3:42 PM, Amir Michail <a.michail@me.com> wrote:
Such comparisons with optionals can result in hard to find bugs.
For example consider:
let f = x < 5 // x is of type Int? and may be nil
The proposed ? suffix would be used as follows and makes the possibility
of nil very clear:let f = x? < 5
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I completely disagree. Being able to compare `Optional` values is very
handy in a lot of cases. Adding special syntax for this is just
unnecessary language complication, especially as the proposed syntax
conflicts with the existing meaning of the postfix-? operator and the
optional-chaining operator.
-Kevin Ballard
Agreed — or, I think, these operators could/should simply be removed.
I filed <rdar://22833869> about this a while ago, which was marked as
Duplicate/<rdar://16966712>.Summary:
This returns true:
(nil as Int?) < 0 This also returns true, which makes even less
sense: (nil as Int?) < Int.min
Expected Results:
nil < 0, nil > 0, and nil == 0, should all be false. nil != 0 should
be true.
Alternatively, just *don't* provide < and > operators that accept
optional arguments.
Actual Results:
nil < 0 is true. Others are as expected.
See also: https://twitter.com/jtbandes/status/646914031433871364
Jacob
Such comparisons with optionals can result in hard to find bugs.
For example consider:
let f = x < 5 // x is of type Int? and may be nil
The proposed ? suffix would be used as follows and makes the possibility
of nil very clear:
let f = x? < 5
···
On Thu, Dec 3, 2015, at 04:17 PM, Jacob Bandes-Storch wrote:
On Thu, Dec 3, 2015 at 3:42 PM, Amir Michail <a.michail@me.com> wrote:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_________________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
To me it seems logical that comparing Optional<Int> with Int (or another
Optional<Int>), if it's allowed at all, should return Optional<Bool>. Since
conditional statements only accept Bool, the user is forced to handle the
nil case explicitly.
Jacob
···
On Thu, Dec 3, 2015 at 4:33 PM, Kevin Ballard <kevin@sb.org> wrote:
I completely disagree. Being able to compare `Optional` values is very
handy in a lot of cases. Adding special syntax for this is just unnecessary
language complication, especially as the proposed syntax conflicts with the
existing meaning of the postfix-? operator and the optional-chaining
operator.-Kevin Ballard
On Thu, Dec 3, 2015, at 04:17 PM, Jacob Bandes-Storch wrote:
Agreed — or, I think, these operators could/should simply be removed.
I filed <rdar://22833869> about this a while ago, which was marked as
Duplicate/<rdar://16966712>.Summary:
This returns true:
(nil as Int?) < 0
This also returns true, which makes even less sense:
(nil as Int?) < Int.minExpected Results:
nil < 0, nil > 0, and nil == 0, should all be false. nil != 0 should be true.
Alternatively, just *don't* provide < and > operators that accept optional arguments.Actual Results:
nil < 0 is true. Others are as expected.See also: https://twitter.com/jtbandes/status/646914031433871364
Jacob
On Thu, Dec 3, 2015 at 3:42 PM, Amir Michail <a.michail@me.com> wrote:
Such comparisons with optionals can result in hard to find bugs.
For example consider:
let f = x < 5 // x is of type Int? and may be nil
The proposed ? suffix would be used as follows and makes the possibility
of nil very clear:let f = x? < 5
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution*_______________________________________________*
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution