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.
> On Jul 12, 2016, at 9:09 AM, Mark Lacey via swift-evolution
> <[email protected]> wrote:
>
>
>> On Jul 11, 2016, at 11:55 PM, Jacob Bandes-Storch <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
