[swift-evolution] Optional comparison operators
Xiaodi Wu
xiaodi.wu at gmail.com
Mon Jul 11 18:59:20 CDT 2016
Yup, I too would prefer removing the functions over removing coercion.
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/a004f6e1/attachment.html>
More information about the swift-evolution
mailing list