# \[Accepted\] SE-0121: Remove Optional Comparison Operators

**URL:** <https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478>\
**Category:** Announcements\
**Created:** [July 21, 2016, 12:38am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478 "2016-07-21T00:38:08Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\
**Post date:** [July 21, 2016, 12:38am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/1 "2016-07-21T00:38:08Z")

</div>

Proposal Link: [swift-evolution/0121-remove-optional-comparison-operators.md at master · apple/swift-evolution · GitHub](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

---

<div class="post-metadata">

**Author:** ![jtbandes](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jtbandes/32/463_2.png) [@jtbandes](https://forums.swift.org/u/jtbandes)\
**Post date:** [July 21, 2016, 12:43am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/2 "2016-07-21T00:43:07Z")

</div>

Great!

I have an attempted implementation here. Would appreciate if someone can  
kick off a CI build/test.

[https://github.com/apple/swift/pull/3637](https://github.com/apple/swift/pull/3637)

> **···**
>
> On Wed, Jul 20, 2016 at 5:38 PM Chris Lattner via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > Proposal Link:  
> > [https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md](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@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Lily\_Ballard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lily_ballard/32/5050_2.png) [@Lily\_Ballard](https://forums.swift.org/u/Lily_Ballard)\
**Post date:** [August 27, 2016, 1:01am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/3 "2016-08-27T01:01:05Z")

</div>

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](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@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![timv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/timv/32/13304_2.png) [@timv](https://forums.swift.org/u/timv)\
**Post date:** [August 27, 2016, 2:36am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/4 "2016-08-27T02:36:15Z")

</div>

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](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@swift.org  
> > \> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\
**Post date:** [August 27, 2016, 4:21pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/5 "2016-08-27T16:21:50Z")

</div>

Hi Kevin,

This fits into a more general idea of introducing a better “ordering” concept defined in terms of three way comparison results (less/equal/greater). This would then become the primitive that sort would be built on, and would allow deriving the user friendly operators like \< and \<=.

There was a sketch of this posted to swift-evolution several weeks ago, but I don’t have a link offhand.

-Chris

> **···**
>
> On Aug 26, 2016, at 6:01 PM, Kevin Ballard \<kevin@sb.org\> wrote:
> 
> > 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.

---

<div class="post-metadata">

**Author:** ![Haravikk3](https://avatars.discourse-cdn.com/v4/letter/h/df705f/32.png) [@Haravikk3](https://forums.swift.org/u/Haravikk3)\
**Post date:** [August 27, 2016, 11:46am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/6 "2016-08-27T11:46:22Z")

</div>

Can you give some examples as to how this will have such a huge impact? Now that we have the ?? operator it seems that this is fairly easy to replace:

&nbsp;&nbsp;value \< 5 // where value is of type Int?

With:

&nbsp;&nbsp;(value ?? 0) \< 5

The latter is completely clear what the behaviour of nil is.

Also, you can still re-add the operators where you need them, ideally with as limited a type as possible so you can make sure that it's behaviour is well defined.

> **···**
>
> > On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > 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.

---

<div class="post-metadata">

**Author:** ![dabrahams](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dabrahams/32/9815_2.png) [@dabrahams](https://forums.swift.org/u/dabrahams)\
**Post date:** [August 28, 2016, 8:28pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/7 "2016-08-28T20:28:09Z")

</div>

It's very easy to write your own versions of these operators, should you  
choose to keep using them. From that standpoint, I don't see why the  
impact has to be huge.

> **···**
>
> on Fri Aug 26 2016, Kevin Ballard \<swift-evolution@swift.org\> wrote:
> 
> > 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.
> 
> --  
> -Dave

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [August 27, 2016, 4:40pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/8 "2016-08-27T16:40:08Z")

</div>

Here's the link:  
[https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025132.html](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025132.html)

> **···**
>
> On Sat, Aug 27, 2016 at 11:21 AM, Chris Lattner via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > On Aug 26, 2016, at 6:01 PM, Kevin Ballard \<kevin@sb.org\> wrote:  
> > \> 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.
> > 
> > Hi Kevin,
> > 
> > This fits into a more general idea of introducing a better “ordering”  
> > concept defined in terms of three way comparison results  
> > (less/equal/greater). This would then become the primitive that sort would  
> > be built on, and would allow deriving the user friendly operators like \<  
> > and \<=.
> > 
> > There was a sketch of this posted to swift-evolution several weeks ago,  
> > but I don’t have a link offhand.
> > 
> > -Chris
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Charlie\_Monroe1](https://avatars.discourse-cdn.com/v4/letter/c/d6d6ee/32.png) [@Charlie\_Monroe1](https://forums.swift.org/u/Charlie_Monroe1)\
**Post date:** [August 27, 2016, 1:58pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/9 "2016-08-27T13:58:30Z")

</div>

I have personally (ab)used this for the following:

class User {  
&nbsp;&nbsp;var email: String  
&nbsp;&nbsp;var firstName: String?  
&nbsp;&nbsp;var lastName: String?  
}

You have a list of users based on email, so last name is optional. In Swift 2.x, you can do:

users.sort({ $0.lastName \< $1.lastName })

Now, you need to do:

users.sorted({  
&nbsp;&nbsp;guard let firstName = $0.0.lastName else {  
&nbsp;&nbsp;&nbsp;&nbsp;return true  
&nbsp;&nbsp;}  
&nbsp;&nbsp;  
&nbsp;&nbsp;guard let secondName = $0.1.lastName else {  
&nbsp;&nbsp;&nbsp;&nbsp;return false  
&nbsp;&nbsp;}  
&nbsp;&nbsp;  
&nbsp;&nbsp;return firstName \< secondName  
})

Which aside from being a brain teaser how to properly maintain ordering when $0.0's lastName != nil && $0.1's lastName == nil, adds additional few lines.

But I agree that it may come as confusing with Ints, etc. - with strings it kind of makes sense since nil is like an empty string which is placed in front of everything.

> **···**
>
> > On Aug 27, 2016, at 1:46 PM, Haravikk via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > 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.
> > 
> > Can you give some examples as to how this will have such a huge impact? Now that we have the ?? operator it seems that this is fairly easy to replace:
> > 
> > &nbsp;&nbsp;value \< 5 // where value is of type Int?
> > 
> > With:
> > 
> > &nbsp;&nbsp;(value ?? 0) \< 5
> > 
> > The latter is completely clear what the behaviour of nil is.
> > 
> > Also, you can still re-add the operators where you need them, ideally with as limited a type as possible so you can make sure that it's behaviour is well defined.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Lily\_Ballard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lily_ballard/32/5050_2.png) [@Lily\_Ballard](https://forums.swift.org/u/Lily_Ballard)\
**Post date:** [August 28, 2016, 3:20am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/10 "2016-08-28T03:20:13Z")

</div>

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

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

This particular case could be trivially replaced with

&nbsp;&nbsp;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@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](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@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Lily\_Ballard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lily_ballard/32/5050_2.png) [@Lily\_Ballard](https://forums.swift.org/u/Lily_Ballard)\
**Post date:** [August 30, 2016, 4:00am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/11 "2016-08-30T04:00:12Z")

</div>

You could make the same argument for a lot of stuff the stdlib provides. For example, let's remove Optional.map since it's trivial to reimplement.

The problem is, if I have to reimplement this thing in every single project I touch, that's a huge impact. I shouldn't have to copy & paste a bunch of code into every single project. I'm already doing this with my replace(\_:with:) function that you guys (Swift core team; I forget exactly who) didn't like, but that's at least simpler than the Optional comparison operators, and is only one function (and it's easier to work around the lack of this function if I don't want to reimplement it for a particular use).

-Kevin

> **···**
>
> On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote:
> 
> > on Fri Aug 26 2016, Kevin Ballard \<swift-evolution@swift.org\> wrote:
> > 
> > \> 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.
> > 
> > It's very easy to write your own versions of these operators, should you  
> > choose to keep using them. From that standpoint, I don't see why the  
> > impact has to be huge.

---

<div class="post-metadata">

**Author:** ![Javi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/javi/32/404_2.png) [@Javi](https://forums.swift.org/u/Javi)\
**Post date:** [August 27, 2016, 2:07pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/12 "2016-08-27T14:07:24Z")

</div>

My biggest issue with Optional conforming to Comparable is that while a  
default implementation may sometimes be useful, it may not necessarily be  
the one you want. In that last example with lastName, if you wanted to  
change the policy for whether users without last name appear first or last,  
you'd have to write more verbose code anyway. Generally, reading that code  
with just "\<" I would never remember what Swift would do with nil (do they  
go first or last?)

If you don't care that much, a simple one-liner without all those guards  
could also be:

users.sorted { ($0.lastName ?? "") \< ($1.lastName ?? "") }

> **···**
>
> On Sat, Aug 27, 2016 at 6:58 AM Charlie Monroe via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > I have personally (ab)used this for the following:
> > 
> > class User {  
> > var email: String  
> > var firstName: String?  
> > var lastName: String?  
> > }
> > 
> > You have a list of users based on email, so last name is optional. In  
> > Swift 2.x, you can do:
> > 
> > users.sort({ $0.lastName \< $1.lastName })
> > 
> > Now, you need to do:
> > 
> > users.sorted({  
> > guard let firstName = $0.0.lastName else {  
> > return true  
> > }
> > 
> > guard let secondName = $0.1.lastName else {  
> > return false  
> > }
> > 
> > return firstName \< secondName  
> > })
> > 
> > Which aside from being a brain teaser how to properly maintain ordering  
> > when $0.0's lastName != nil && $0.1's lastName == nil, adds additional few  
> > lines.
> > 
> > But I agree that it may come as confusing with Ints, etc. - with strings  
> > it kind of makes sense since nil is like an empty string which is placed in  
> > front of everything.
> > 
> > On Aug 27, 2016, at 1:46 PM, Haravikk via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > 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.
> > 
> > Can you give some examples as to how this will have such a huge impact?  
> > Now that we have the ?? operator it seems that this is fairly easy to  
> > replace:
> > 
> > value \< 5 // where value is of type Int?
> > 
> > With:
> > 
> > (value ?? 0) \< 5
> > 
> > The latter is completely clear what the behaviour of nil is.
> > 
> > Also, you can still re-add the operators where you need them, ideally with  
> > as limited a type as possible so you can make sure that it's behaviour is  
> > well defined.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> 
> --  
> Javier Soto

---

<div class="post-metadata">

**Author:** ![ahltorp](https://avatars.discourse-cdn.com/v4/letter/a/a587f6/32.png) [@ahltorp](https://forums.swift.org/u/ahltorp)\
**Post date:** [August 27, 2016, 2:11pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/13 "2016-08-27T14:11:29Z")

</div>

Without having tested it, something like this should work. In more complicated cases, make it a method on the struct.

users.sorted({ ($0.lastName ?? "") \< ($1.lastName ?? "") })

/Magnus

> **···**
>
> > 27 Aug. 2016 15:58 Charlie Monroe via swift-evolution \<swift-evolution@swift.org\> wrote:  
> > Now, you need to do:
> > 
> > users.sorted({  
> > &nbsp;&nbsp;guard let firstName = $0.0.lastName else {  
> > &nbsp;&nbsp;&nbsp;&nbsp;return true  
> > &nbsp;&nbsp;}  
> > &nbsp;&nbsp;  
> > &nbsp;&nbsp;guard let secondName = $0.1.lastName else {  
> > &nbsp;&nbsp;&nbsp;&nbsp;return false  
> > &nbsp;&nbsp;}  
> > &nbsp;&nbsp;  
> > &nbsp;&nbsp;return firstName \< secondName  
> > })

---

<div class="post-metadata">

**Author:** ![hartbit](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hartbit/32/738_2.png) [@hartbit](https://forums.swift.org/u/hartbit)\
**Post date:** [August 27, 2016, 4:00pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/14 "2016-08-27T16:00:25Z")

</div>

I totally agree with Javier here. There is nothing obvious about nil being \< or \> than a non-nil value. As it's not obvious at all, having a default behaviour can be very surprising. i much prefer the explicitness that the proposal brought.

> **···**
>
> > On 27 Aug 2016, at 16:07, Javier Soto via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > My biggest issue with Optional conforming to Comparable is that while a default implementation may sometimes be useful, it may not necessarily be the one you want. In that last example with lastName, if you wanted to change the policy for whether users without last name appear first or last, you'd have to write more verbose code anyway. Generally, reading that code with just "\<" I would never remember what Swift would do with nil (do they go first or last?)
> > 
> > If you don't care that much, a simple one-liner without all those guards could also be:
> > 
> > users.sorted { ($0.lastName ?? "") \< ($1.lastName ?? "") }
> > 
> > > On Sat, Aug 27, 2016 at 6:58 AM Charlie Monroe via swift-evolution \<swift-evolution@swift.org\> wrote:  
> > > I have personally (ab)used this for the following:
> > > 
> > > class User {  
> > > &nbsp;&nbsp;var email: String  
> > > &nbsp;&nbsp;var firstName: String?  
> > > &nbsp;&nbsp;var lastName: String?  
> > > }
> > > 
> > > You have a list of users based on email, so last name is optional. In Swift 2.x, you can do:
> > > 
> > > users.sort({ $0.lastName \< $1.lastName })
> > > 
> > > Now, you need to do:
> > > 
> > > users.sorted({  
> > > &nbsp;&nbsp;guard let firstName = $0.0.lastName else {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;return true  
> > > &nbsp;&nbsp;}  
> > > &nbsp;&nbsp;  
> > > &nbsp;&nbsp;guard let secondName = $0.1.lastName else {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;return false  
> > > &nbsp;&nbsp;}  
> > > &nbsp;&nbsp;  
> > > &nbsp;&nbsp;return firstName \< secondName  
> > > })
> > > 
> > > Which aside from being a brain teaser how to properly maintain ordering when $0.0's lastName != nil && $0.1's lastName == nil, adds additional few lines.
> > > 
> > > But I agree that it may come as confusing with Ints, etc. - with strings it kind of makes sense since nil is like an empty string which is placed in front of everything.
> > > 
> > > > > On Aug 27, 2016, at 1:46 PM, Haravikk via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > > > 
> > > > > On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > > > 
> > > > > 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.
> > > > 
> > > > Can you give some examples as to how this will have such a huge impact? Now that we have the ?? operator it seems that this is fairly easy to replace:
> > > > 
> > > > &nbsp;&nbsp;value \< 5 // where value is of type Int?
> > > > 
> > > > With:
> > > > 
> > > > &nbsp;&nbsp;(value ?? 0) \< 5
> > > > 
> > > > The latter is completely clear what the behaviour of nil is.
> > > > 
> > > > Also, you can still re-add the operators where you need them, ideally with as limited a type as possible so you can make sure that it's behaviour is well defined.  
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > --  
> > Javier Soto  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Lily\_Ballard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lily_ballard/32/5050_2.png) [@Lily\_Ballard](https://forums.swift.org/u/Lily_Ballard)\
**Post date:** [August 28, 2016, 3:34am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/15 "2016-08-28T03:34:42Z")

</div>

> My biggest issue with Optional conforming to Comparable is that while  
> a default implementation may sometimes be useful, it may not  
> necessarily be the one you want.

Isn't that true for almost everything? I could use the same argument to  
say String shouldn't implement \<, because it's not always the comparison  
you want. For example, with the lastName example, you probably want case-  
insensitive comparisons instead of case-sensitive comparisons, so you  
probably shouldn't be using \< at all.

> In that last example with lastName, if you wanted to change the policy  
> for whether users without last name appear first or last, you'd have  
> to write more verbose code anyway. Generally, reading that code with  
> just "\<" I would never remember what Swift would do with nil (do they  
> go first or last?)

Why would nil sort to the end? Empty values typically sort before  
non-empty values, for example the empty string sorts before all  
other strings.

-Kevin

> **···**
>
> On Sat, Aug 27, 2016, at 07:07 AM, Javier Soto via swift-evolution wrote:
> 
> > If you don't care that much, a simple one-liner without all those  
> > guards could also be:
> > 
> > users.sorted { ($0.lastName ?? "") \< ($1.lastName ?? "") }  
> > On Sat, Aug 27, 2016 at 6:58 AM Charlie Monroe via swift-evolution \<swift- \> evolution@swift.org\> wrote:
> > 
> > > I have personally (ab)used this for the following:
> > > 
> > > class User {  
> > > var email: String  
> > > var firstName: String?  
> > > var lastName: String?  
> > > }
> > > 
> > > You have a list of users based on email, so last name is optional. In  
> > > Swift 2.x, you can do:
> > > 
> > > users.sort({ $0.lastName \< $1.lastName })
> > > 
> > > Now, you need to do:
> > > 
> > > users.sorted({  
> > > guard let firstName = $0.0.lastName else {  
> > > return true  
> > > }
> > > 
> > > guard let secondName = $0.1.lastName else {  
> > > return false  
> > > }
> > > 
> > > return firstName \< secondName  
> > > })
> > > 
> > > Which aside from being a brain teaser how to properly maintain  
> > > ordering when $0.0's lastName != nil && $0.1's lastName == nil, adds  
> > > additional few lines.
> > > 
> > > But I agree that it may come as confusing with Ints, etc. - with  
> > > strings it kind of makes sense since nil is like an empty string  
> > > which is placed in front of everything.
> > > 
> > > > On Aug 27, 2016, at 1:46 PM, Haravikk via swift-evolution \<swift- \>\>\> evolution@swift.org\> wrote:
> > > > 
> > > > > On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution \<swift- \>\>\>\> evolution@swift.org\> wrote:
> > > > > 
> > > > > 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.
> > > > 
> > > > Can you give some examples as to how this will have such a huge  
> > > > impact? Now that we have the ?? operator it seems that this is  
> > > > fairly easy to replace:
> > > > 
> > > > value \< 5 // where value is of type Int?
> > > > 
> > > > With:
> > > > 
> > > > (value ?? 0) \< 5
> > > > 
> > > > The latter is completely clear what the behaviour of nil is.
> > > > 
> > > > Also, you can still re-add the operators where you need them,  
> > > > ideally with as limited a type as possible so you can make sure that  
> > > > it's behaviour is well defined.  
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > --  
> > Javier Soto  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Patrick\_Smith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/patrick_smith/32/3428_2.png) [@Patrick\_Smith](https://forums.swift.org/u/Patrick_Smith)\
**Post date:** [August 29, 2016, 10:26am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/16 "2016-08-29T10:26:29Z")

</div>

A little nicer I think is:

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

It’s very explicit what the fallback is too, the original’s ambiguity makes me uncomfortable.

BTW, did you want to be checking for \<= 1.0? With HTTP 1.0, it’s opt in. [HTTP persistent connection - Wikipedia](https://en.wikipedia.org/wiki/HTTP_persistent_connection)

Patrick

> **···**
>
> > On 28 Aug 2016, at 1:20 PM, Kevin Ballard via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > 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) {  
> > &nbsp;&nbsp;&nbsp;// no keepalive  
> > &nbsp;&nbsp;&nbsp;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.

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [August 30, 2016, 6:43am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/17 "2016-08-30T06:43:36Z")

</div>

> > > 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.
> > 
> > It's very easy to write your own versions of these operators, should you  
> > choose to keep using them. From that standpoint, I don't see why the  
> > impact has to be huge.
> 
> You could make the same argument for a lot of stuff the stdlib provides. For example, let's remove Optional.map since it's trivial to reimplement.

I think a case for removing it may be how much Optional.map is used to work around any pains regarding using optionals.

> **···**
>
> Sent from my iPhone
> 
> > On 30 Aug 2016, at 05:00, Kevin Ballard via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote:
> > > 
> > > > on Fri Aug 26 2016, Kevin Ballard \<swift-evolution@swift.org\> wrote:
> 
> > The problem is, if I have to reimplement this thing in every single project I touch, that's a huge impact. I shouldn't have to copy & paste a bunch of code into every single project. I'm already doing this with my replace(\_:with:) function that you guys (Swift core team; I forget exactly who) didn't like, but that's at least simpler than the Optional comparison operators, and is only one function (and it's easier to work around the lack of this function if I don't want to reimplement it for a particular use).
> > 
> > -Kevin  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\
**Post date:** [August 28, 2016, 4:01am UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/18 "2016-08-28T04:01:57Z")

</div>

Does an empty Int sort before or after a non-empty Int?

> **···**
>
> Sent from my iPhone
> 
> > On Aug 27, 2016, at 22:34, Kevin Ballard via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > On Sat, Aug 27, 2016, at 07:07 AM, Javier Soto via swift-evolution wrote:  
> > > My biggest issue with Optional conforming to Comparable is that while a default implementation may sometimes be useful, it may not necessarily be the one you want.
> > 
> > Isn't that true for almost everything? I could use the same argument to say String shouldn't implement \<, because it's not always the comparison you want. For example, with the lastName example, you probably want case-insensitive comparisons instead of case-sensitive comparisons, so you probably shouldn't be using \< at all.
> > 
> > > In that last example with lastName, if you wanted to change the policy for whether users without last name appear first or last, you'd have to write more verbose code anyway. Generally, reading that code with just "\<" I would never remember what Swift would do with nil (do they go first or last?)
> > 
> > Why would nil sort to the end? Empty values typically sort before non-empty values, for example the empty string sorts before all other strings.
> > 
> > -Kevin
> > 
> > > If you don't care that much, a simple one-liner without all those guards could also be:
> > > 
> > > users.sorted { ($0.lastName ?? "") \< ($1.lastName ?? "") }  
> > > On Sat, Aug 27, 2016 at 6:58 AM Charlie Monroe via swift-evolution \<swift-evolution@swift.org\> wrote:  
> > > I have personally (ab)used this for the following:
> > > 
> > > class User {  
> > > var email: String  
> > > var firstName: String?  
> > > var lastName: String?  
> > > }
> > > 
> > > You have a list of users based on email, so last name is optional. In Swift 2.x, you can do:
> > > 
> > > users.sort({ $0.lastName \< $1.lastName })
> > > 
> > > Now, you need to do:
> > > 
> > > users.sorted({  
> > > guard let firstName = $0.0.lastName else {  
> > > return true  
> > > }
> > > 
> > > guard let secondName = $0.1.lastName else {  
> > > return false  
> > > }
> > > 
> > > return firstName \< secondName  
> > > })
> > > 
> > > Which aside from being a brain teaser how to properly maintain ordering when $0.0's lastName != nil && $0.1's lastName == nil, adds additional few lines.
> > > 
> > > But I agree that it may come as confusing with Ints, etc. - with strings it kind of makes sense since nil is like an empty string which is placed in front of everything.
> > > 
> > > > On Aug 27, 2016, at 1:46 PM, Haravikk via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > > 
> > > > > On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > > > 
> > > > > 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.
> > > > 
> > > > Can you give some examples as to how this will have such a huge impact? Now that we have the ?? operator it seems that this is fairly easy to replace:
> > > > 
> > > > value \< 5 // where value is of type Int?
> > > > 
> > > > With:
> > > > 
> > > > (value ?? 0) \< 5
> > > > 
> > > > The latter is completely clear what the behaviour of nil is.
> > > > 
> > > > Also, you can still re-add the operators where you need them, ideally with as limited a type as possible so you can make sure that it's behaviour is well defined.  
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)  
> > > --  
> > > Javier Soto  
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\
**Post date:** [August 28, 2016, 1:04pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/19 "2016-08-28T13:04:13Z")

</div>

> > My biggest issue with Optional conforming to Comparable is that while a default implementation may sometimes be useful, it may not necessarily be the one you want.
> 
> Isn't that true for almost everything?

That reminds me on a feature that has been discussed and added before:  
Making tuples conform to Comparable ([https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md\](https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md%5C))  
The implementation doesn't hurt me, but imho it's use is very limited as well.

As for comparing optionals, my preferred result would be an Optional\<Bool\>:  
if (value \< 5) ?? true {…  
It makes no assumptions on the order, is clear and also concise.

Tino

> There was a sketch of this posted to swift-evolution several weeks ago, but I don’t have a link offhand.

That, on the other hand, reminds me on the discussion about switching to another platform, because the mailing list sucks. I couldn't find a link to that one either (guess why ;-)

> **···**
>
> > Am 28.08.2016 um 05:34 schrieb Kevin Ballard via swift-evolution \<swift-evolution@swift.org\>:

---

<div class="post-metadata">

**Author:** ![BigZaphod](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bigzaphod/32/9561_2.png) [@BigZaphod](https://forums.swift.org/u/BigZaphod)\
**Post date:** [August 29, 2016, 2:42pm UTC](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478/20 "2016-08-29T14:42:11Z")

</div>

I agree - I really don’t like these clever map constructs to work around optionals either and I avoid them at all costs. IMO they obscure intent pretty severely and shouldn’t be considered idiomatic Swift.

Depending on circumstances, I might do something along these lines:

guard let version = request?.httpVersion, version \>= HTTPVersion(1.0) else {  
&nbsp;&nbsp;disconnect()  
&nbsp;&nbsp;return  
}

That’s still more verbose, though, but it seems very explicit without relying on map cleverness.

l8r  
Sean

> **···**
>
> > On Aug 29, 2016, at 6:05 AM, Goffredo Marocchi via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > Whenever I see such examples I feel like map is being abused because of some of its properties rather than this. Ring the best way to deal with optionals.
> > 
> > Sent from my iPhone
> > 
> > On 29 Aug 2016, at 11:26, Patrick Smith via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > > A little nicer I think is:
> > > 
> > > if request?.httpVersion.map({ $0 \< HTTPVersion(1.0) }) ?? true {
> > > 
> > > It’s very explicit what the fallback is too, the original’s ambiguity makes me uncomfortable.
> > > 
> > > BTW, did you want to be checking for \<= 1.0? With HTTP 1.0, it’s opt in. [HTTP persistent connection - Wikipedia](https://en.wikipedia.org/wiki/HTTP_persistent_connection)
> > > 
> > > Patrick
> > > 
> > > > On 28 Aug 2016, at 1:20 PM, Kevin Ballard via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > > 
> > > > 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) {  
> > > > &nbsp;&nbsp;// no keepalive  
> > > > &nbsp;&nbsp;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.
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

[Next page](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478.md?page=2)