[swift-evolution] Optional comparison operators

[Mark Lacey]

> 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).

Mark

> 
> On Mon, Jul 11, 2016 at 18:57 Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:mark.lacey at apple.com>> wrote:
> 
>> On Jul 11, 2016, at 4:32 PM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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.devel/2089>
>>> - http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095 <http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095>
>>> - rdar:// <>16966712&22833869
>>> - Replies to https://twitter.com/jtbandes/status/646914031433871364 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/1abc750b/attachment.html>