[swift-evolution] Optional comparison operators

[Xiaodi Wu]

On Tue, Jul 12, 2016 at 2:22 AM, Mark Lacey via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jul 12, 2016, at 12:16 AM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> 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.
>
>
> Sure, I mean uncommon in the sense that in the projects I’ve looked at I’m
> seeing them perhaps once every 1,000-2,000 lines of commented code, not
> uncommon in the sense that you will almost never see them in practice. I’m
> sure for some projects it’s going to be much more often than others.
>
> Mark
>

Does this really need to be a separate proposal? I mean, implicit in your
proposal is special casing the assignment operator to do the same thing
(conceptually, at least). Otherwise, let `y = 1, x: Int? = y` wouldn't work
anymore, right? So it'd probably be in scope to say that those scenarios in
which coercion currently makes sense would be preserved by the addition of
the appropriate overloads concomitant with removal of coercion generally.


>
> 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
>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> 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/2fb87cbd/attachment.html>