You'd have to unwrap it, or use the ??/==/!= operators: https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38
I'd be okay with </<=/>/>= returning Bool?, as I suggested in an older email (which somehow didn't make it to gmane's archive, but it's quoted in some other messages <http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095>). I think it would be more convenient in some cases than unwrapping the individual values before comparing them. Jacob On Mon, Jul 11, 2016 at 8:08 PM, Saagar Jha <[email protected]> wrote: > Correct me if I’m wrong, but wouldn’t you have to unwrap every comparison > then? > > On Jul 11, 2016, at 20:02, David Sweeris via swift-evolution < > [email protected]> wrote: > > Why not have them return a `Bool?`? If both arguments are non-nil, it can > return the results of the comparison, otherwise it can return nil. > > - Dave Sweeris > > On Jul 7, 2016, at 16:37, Jacob Bandes-Storch via swift-evolution < > [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. > > Jacob > > _______________________________________________ > 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 > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
