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