[swift-evolution] Optional comparison operators

[Mark Lacey]

> On Jul 12, 2016, at 12:58 AM, Charlie Monroe <charlie at charliemonroe.net> wrote:
> 
> An example to keep in mind:
> 
> let dict: [String : String] = ...
> if dict["key"] == "value" { // String? == String
> 	// Do something
> }
> 
> If I understand correctly, when the proposal is accepted, you'd need to do something like:
> 
> if let value = dict["key"], value == "value" { } 
> -- OR --
> if dict["key"] == Optional("value") { }
> 
> It's not an end of the world, but makes life a bit more difficult and such usecase should be kept in mind.

Yes, Jacob also pointed this out.

Sometime later today I will push out an updated proposal that calls this out, and also discusses the overloads for equality and identity comparisons where one side is optional. I want to take another quick look at some of the changes I had to make to projects I looked at before I do so.

Mark

> 
> 
>> On Jul 12, 2016, at 9:09 AM, Mark Lacey via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Jul 11, 2016, at 11:55 PM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto: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 <mailto:mark.lacey at apple.com>> wrote:
>>> 
>>>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> You'd have to unwrap it, or use the ??/==/!= operators: https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38 <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 <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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/61e915ee/attachment.html>