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 {
>> 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
>>
>> _______________________________________________
>> 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
