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

[David Sweeris]

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 at 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 at 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 at swift.org> wrote:
>>> 
>>> 
>>>> On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution <swift-evolution at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> -- 
>> Javier Soto
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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-evolution/attachments/20160827/bbeb7ea7/attachment.html>