[swift-evolution] Optional comparison operators

Jacob Bandes-Storch jtbandes at gmail.com
Mon Jul 11 20:02:45 CDT 2016

On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner <clattner at apple.com> wrote:

> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
> > Personally I think we should just remove these optional-taking variants
> of the comparison operators. Does anyone agree/disagree?
> >
> > It does make sense to keep ==(T?, T?) and !=(T?, T?), and if coercion
> were removed, we might want to add (T, T?) and (T?, T) versions. Are there
> any other operators that would be affected by your proposal? If not,
> removing the optional </<=/>/>= would obviate the need to remove coercion.
> My opinion:
>  - We need to remove T -> T? promotion from operators for a whole lot of
> reasons.  People are frequently surprised by the behavior of the ??
> operator promoting the LHS to optional, for example.  There are a ton of
> “bugs” that people file that are related to issues like that.

Thinking about this a bit more, couldn't the same class of "gotcha" happen
with regular functions, too? Why should this be changed for operators

Maybe it makes more sense to have some kind of "@noncoercing" parameter, so
that coercion can still take place, but operator could be defined as `func
??<T>(lhs: @noncoercing T?, rhs: T?)`

>  - We don’t have conditional conformances, so Optional cannot
> conditionally conform to Equatable and Comparable in Swift 3.  In a later
> release, we can consider whether adding them is a good idea.
>  - We currently support equatable comparing an arbitrary optional to nil
> (one in which T is not necessarily Equatable), which I think is useful to
> keep around.
>  - If we allow that, then it makes sense to allow == and != operators for
> optionals where T is Equatable, even though the optional itself cannot
> conditionally conform to Equatable.  The “surprising” aspect of equatable
> comparison doing promotions will have been removed.
> The questionable piece is what to do with </<=/>/>=.  I would lean towards
> removing them in Swift 3 simply because it is easier to "remove now, but
> add them back later" if they really are important.  The argument for
> keeping them is that the surprising aspect will be solved by removing the
> first promotion - "42 > nil” will cease to type-check, so they may not
> actually be harmful anymore.
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/e81a0849/attachment.html>

More information about the swift-evolution mailing list