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-
> evolut...@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-
>>> evolut...@swift.org> wrote:
>>>
>>>
>>>> On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution <swift-
>>>> evolut...@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
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
