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

Javier Soto javier.api at gmail.com
Sat Aug 27 09:07:24 CDT 2016


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


More information about the swift-evolution mailing list