[swift-evolution] Optional comparison operators
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>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution