[swift-evolution] Optional comparison operators

[Jacob Bandes-Storch]

On Mon, Jul 11, 2016 at 5:32 PM, Mark Lacey <mark.lacey at apple.com> wrote:

>
> On Jul 11, 2016, at 4:59 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Yup, I too would prefer removing the functions over removing coercion.
>
>
> Hi Xiaodi,
>
> Is there a reason you think the coercion is important to keep?
>
> I see these as somewhat orthogonal issues (allowing or disallowing
> coercion vs. keeping or removing certain operators that take optionals or
> for that matter changing the defined behavior in the case of nil operands
> mixed with non-nil operands).
>

Hypothetically, if the </<=/>/>= operators taking optionals were removed,
coercion would still be useful for ==(T?, T?) and !=(T?, T?).

But, you make a good point about ?? — it probably shouldn't be allowed to
pass a non-optional value on the left-hand side. That's enough evidence for
me to support removing coercion regardless of what happens to these
comparison operators.


>
> Mark
>
>
> On Mon, Jul 11, 2016 at 18:57 Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Personally I think we should just remove these optional-taking variants
>> of the comparison operators. Does anyone agree/disagree?
>>
>> It does make sense to keep ==(T?, T?) and !=(T?, T?), and if coercion
>> were removed, we might want to add (T, T?) and (T?, T) versions. Are there
>> any other operators that would be affected by your proposal? If not,
>> removing the optional </<=/>/>= would obviate the need to remove coercion.
>>
>> Jacob
>>
>> On Mon, Jul 11, 2016 at 4:45 PM, Mark Lacey <mark.lacey at apple.com> wrote:
>>
>>>
>>> On Jul 11, 2016, at 4:32 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
>>> wrote:
>>>
>>> Great, thanks Mark! I look forward to it.
>>>
>>>
>>> To be clear, I’m specifically looking at making the change to remove the
>>> coercion from T to T? for operator arguments.
>>>
>>> I agree there might be other things worth looking at regarding operators
>>> that take optionals, but I’m not currently looking at those issues.
>>>
>>> Mark
>>>
>>>
>>> On Mon, Jul 11, 2016 at 4:31 PM, Mark Lacey <mark.lacey at apple.com>
>>> wrote:
>>>
>>>> Hi Jacob,
>>>>
>>>> On Jul 11, 2016, at 4:23 PM, Jacob Bandes-Storch via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>> Bump for Swift 3.
>>>>
>>>> On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch <jtbandes at gmail.com
>>>> > wrote:
>>>>
>>>>> These operators cause some potential for confusion:
>>>>>
>>>>>     public func <<T : Comparable>(lhs: T?, rhs: T?) -> Bool
>>>>>     public func ><T : Comparable>(lhs: T?, rhs: T?) -> Bool
>>>>>     public func <=<T : Comparable>(lhs: T?, rhs: T?) -> Bool
>>>>>     public func >=<T : Comparable>(lhs: T?, rhs: T?) -> Bool
>>>>>
>>>>> 1. The meaning of T? < T? is not immediately obvious (Why is nil <
>>>>> .some(x) for any x? Personally, my intuition says that Optional should only
>>>>> provide a partial order, with .none not being ordered w.r.t. .some(x).)
>>>>>
>>>>> 2. Even if the meaning is understood, it can be surprising when the
>>>>> (T?, T?) -> Bool version is used instead of (T, T) -> Bool.
>>>>>
>>>>> Prior discussion:
>>>>> - http://thread.gmane.org/gmane.comp.lang.swift.devel/2089
>>>>> - http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095
>>>>> - rdar://16966712&22833869
>>>>> - Replies to https://twitter.com/jtbandes/status/646914031433871364
>>>>>
>>>>> In the swift-dev thread from May, Chris said:
>>>>>
>>>>> One of the ideas that Joe Pamer has been discussing is whether the
>>>>>>> implicit promotion from T to T? should be disabled when in an operator
>>>>>>> context.  Doing so would fix problems like this, but making the code
>>>>>>> invalid.
>>>>>>
>>>>>>
>>>>>>
>>>>> A change like this would be source-breaking, so if the core team has
>>>>> recommendations for how to handle these issues, now is probably the time to
>>>>> get it done.
>>>>>
>>>>
>>>> I overlooked your previous message on this.
>>>>
>>>> I’m actually writing up a proposal for this now, and have an
>>>> implementation that I’ve done a bit of testing with.
>>>>
>>>> I’m hoping to get the proposal out in the next couple days.
>>>>
>>>> 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/20160711/c459899b/attachment.html>