[swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

[Kevin Ballard]

I find it useful because Optionals show up all over the place, and it’s very convenient to be able to compare Optional values in a straightforward fashion. Especially when you have two Optional values to compare (as opposed to comparing an Optional with a non-Optional). `nil < .some(x)` evaluating to true makes sense because it’s the logical way to define that operator if you’re trying to make Optionals comparable (and if we had conditional protocol conformances then I’d say Optional should in fact be Comparable), as the absence of a value would quite reasonably be considered to be less than the presence of a value, assuming that there is an ordered relationship at all. And there’s already precedent for “empty” values sorting less than all other values (namely, the empty string sorts less than all other strings).

As for optional comparisons making the code cleaner, I end up using them all over the place. The case that motivated my email looked something along the lines of

  if request?.httpVersion < HTTPVersion(1.0) {
    // no keepalive
    disconnect()
  }

This particular case could be trivially replaced with

  if request.map({ $0.httpVersion < HTTPVersion(1.0) }) ?? true {

but it’s uglier and harder to read.

It’s easy to come up with contrived examples of comparing two optionals as well. A simplistic example is just sorting an array of optionals, or sorting an array of structs that contain an optional value.

-Kevin Ballard

> On Aug 26, 2016, at 7:36 PM, Tim Vermeulen <tvermeulen at me.com> wrote:
> 
> What do you find so useful about them? And in what context does it make sense to you that `nil < .some(x)` always evaluates to true? When I found that out, I was very surprised by that behaviour (just like many others). Do you have examples of then an optional comparison makes the code clearer?
> 
>> Goddammit. I completely missed this thread, because Pipermail regularly decides not to deliver the swift-evolution-announce version of review threads (which means they bypass my inbox). Why does it do this? Most of the emails get delivered, but it just skips some of them, and I keep ending up missing review threads because of it.
>> 
>> This change is going to have a HUGE impact for me. I use this sort of comparison _all the time_ and find it incredibly useful, and have had literally zero bugs caused by this. Surely I can't be the only one who uses this. I am not looking forward to copying&pasting a reimplementation of the comparison functions into every single project I work on.
>> 
>> I'm also really concerned about how fast such a hugely-impactful change was proposed, accepted, and implemented. The proposal PR was submitted on July 12, merged the same day, and a review kicked off again on the same day. And the first thread the proposal referenced only happened the previous day, on July 11. And the implementation landed only 12 days later on July 24th. This was extremely fast and didn't even have time to have the proposal listed on apple/swift-evolution for people to find before the review kicked off. It looks like this was done so the change could be made before the end of source-breaking changes, but the fast-tracking of something like this means that people like me completely missed it, and now we're stuck with a highly-impactful change that we don't want. Fast-tracking proposals is understandable when they're largely additive, or they fix something that is widely accepted as a problem. But being able to compare optionals is not universally recognized as a problem, and I know for a fact I've weighed in on this subject in the past on swift-evolution. I do not think it was appropriate to fast-track this proposal.
>> 
>> -Kevin Ballard
>> 
>> On Wed, Jul 20, 2016, at 05:38 PM, Chris Lattner via swift-evolution wrote:
>>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md
>>> 
>>> The review of "SE-0121: Remove Optional Comparison Operators" ran from Active review July 12...19. The proposal has been *accepted*.
>>> 
>>> Feedback has been universally positive from both the community and the core team, because it eliminates a surprising part of the Swift model at very little utility cost.
>>> 
>>> Thank you to Jacob Bandes-Storch for driving this discussion forward.
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>>