[swift-evolution] Optional comparison operators

[Jacob Bandes-Storch]

Okay, I guess it's fair that (T, T?) and (T?, T) overloads should have to
be a separate proposal.

My personal motivation is mostly anecdotal; I've found them quite useful,
and I wouldn't say they're uncommon. Some use cases off the top of my head:
- checking whether a dictionary contains a particular value for a key
- checking whether an optional ivar (such as "selectedIndex: Int?")
contains a particular value ("if tappedIndex == selectedIndex")

Jacob

On Tue, Jul 12, 2016 at 12:09 AM, Mark Lacey <mark.lacey at apple.com> wrote:

>
> On Jul 11, 2016, at 11:55 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> Mark,
> Thanks for writing this up. Just to clarify, will these still work if your
> proposal is implemented?
>
>     let x: Int?
>     let y: Int
>     struct NotEquatable {}
>     let z: NotEquatable?
>
>     x == y; x != y
>     x == nil; x != nil
>     z == nil; z != nil
>
> I would hope that these continue to work. If any changes need to be made
> to ensure that, please make sure they're included in the proposal too.
>
>
> The last four would work, but the first two (x == y and x != y) would not
> because they still involve coercing y to an optional.
>
> Similarly, === and !== on reference types where one is an optional would
> require coercing one side, and would not be accepted without an explicit
> cast using Optional().
>
> I’m curious what the motivation is for further special casing these
> operators. They do occur more in practice than <, <=, >, >= (in fact most
> of the source updates I had to make were due to === and !==, with == and !=
> a close second), but overall these are still quite uncommon from what I’ve
> seen.
>
> If you’d like I can certainly update the “alternatives considered” to
> include the suggestion that we add overloads for (T, T?) and (T?, T) for
> those four operators.
>
> Mark
>
>
> Jacob
>
> On Mon, Jul 11, 2016 at 9:35 PM, Mark Lacey <mark.lacey at apple.com> wrote:
>
>>
>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> You'd have to unwrap it, or use the ??/==/!= operators:
>> https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38
>>
>> I'd be okay with </<=/>/>= returning Bool?, as I suggested in an older
>> email (which somehow didn't make it to gmane's archive, but it's quoted in some
>> other messages
>> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095>). I
>> think it would be more convenient in some cases than unwrapping the
>> individual values before comparing them.
>>
>>
>> I’d be strongly opposed to those operator returning “Bool?”.  Doing so
>> would prevent conforming to Comparable and would be extremely surprising.
>>
>> -Chris
>>
>>
>> I just pushed the current draft of the proposal:
>> https://github.com/rudkx/swift-evolution/blob/eliminate-value-to-optional-coercion/proposals/0000-disallow-value-to-optional-coercion-in-operator-arguments.md
>>
>> I haven’t addressed removal of the ordered comparison operators. I
>> suspect this should be a separate proposal, but I can roll that into this
>> one if it’s desired.
>>
>> I’ll update the proposal as the discussion continues until it’s selected
>> for review.
>>
>> Mark
>>
>>
>> _______________________________________________
>> 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/20160712/507f26be/attachment.html>