> 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] > <mailto:[email protected]>> wrote: > Hi Jacob, > >> On Jul 11, 2016, at 4:23 PM, Jacob Bandes-Storch via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Bump for Swift 3. >> >> On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch <[email protected] >> <mailto:[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.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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
