> On Jul 11, 2016, at 11:55 PM, Jacob Bandes-Storch <jtban...@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.la...@apple.com
> <mailto:mark.la...@apple.com>> wrote:
>
>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
