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

[David Hart]

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 at 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160827/0c1c9338/attachment.html>