On Mon, Jul 11, 2016 at 5:32 PM, Mark Lacey <[email protected]> wrote:
> > On Jul 11, 2016, at 4:59 PM, Xiaodi Wu <[email protected]> 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 < > [email protected]> 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 <[email protected]> wrote: >> >>> >>> On Jul 11, 2016, at 4:32 PM, Jacob Bandes-Storch <[email protected]> >>> 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 <[email protected]> >>> wrote: >>> >>>> Hi Jacob, >>>> >>>> On Jul 11, 2016, at 4:23 PM, Jacob Bandes-Storch via swift-evolution < >>>> [email protected]> wrote: >>>> >>>> Bump for Swift 3. >>>> >>>> On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch <[email protected] >>>> > 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
