[swift-evolution] Optional comparison operators

[Xiaodi Wu]

On Mon, Jul 11, 2016 at 8:02 PM, Jacob Bandes-Storch via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
> specifically?
>

You've articulated here the gist of my thinking, probably better than I
could. Taken narrowly, it's clear that coercion + these particular
functions leads to undesirable effects. But more generally, operators are
just a different spelling for functions, and since I've had occasion to
find this coercion behavior useful in calling functions, I can think of no
principled reason why operators could not be similarly make profitable use
of it (in particular circumstances). The flip side is, there are bound to
be scenarios in which coercion with regular functions would be undesirable
as well.

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
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/5f4c446c/attachment.html>