[swift-evolution] Optional comparison operators

Jacob Bandes-Storch jtbandes at gmail.com
Mon Jul 11 19:44:17 CDT 2016


On Mon, Jul 11, 2016 at 5:29 PM, Mark Lacey <mark.lacey at apple.com> wrote:

>
> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> Personally I think we should just remove these optional-taking variants of
> the comparison operators. Does anyone agree/disagree?
>
>
> I believe that a well-defined ordering of optionals and non-optionals is
> required in order to allow sorting an array of optionals.
>
> You can argue about how useful this is, but it seems like it would be
> important to support this for generic algorithms.
>

I'd be curious whether anyone can come up with a good example of why this
would be useful. Optional itself isn't Comparable (the generics features
required for that don't exist yet), so I don't think there's any way to use
this in generic code without explicitly handling the values as being
Optional, and so you might as well be required to unwrap them.


> Having said that, it also seems entirely reasonable (and safer) to
> disallow comparison of an optional with a non-optional value when done
> explicitly in code (e.g. x < y where one is a known optional), and require
> an explicit cast of the other operand to an optional in order to allow this
> to compile.
>

Just to re-iterate my above paragraph (trying to convince myself), I think
that today the operands are *always* "known optional" or "known
non-optional", so there isn't really a way to distinguish between these
cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/befe3219/attachment.html>


More information about the swift-evolution mailing list