I'd like to pitch it out to swift-evolution but I'm not sure to fully understand the proposed solution of "disabling implicit promotion from T to T?"
Does it mean that the following code won't work anymore? let a: Int? = nil let b: Int = 25 a < b // does not compile anymore If so, I'm not sure it fixed our main problem because the following would still work as currently: let a: Int? = nil let b: Int? = 25 a < b // return true Result is still counterintuitive and could lead to misuses if the above behavior is not specifically known by a developer. 2016-05-24 20:35 GMT+02:00 Chris Lattner <clatt...@apple.com>: > > On May 24, 2016, at 11:14 AM, Joe Pamer <jpa...@apple.com> wrote: > > > On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev < > swift-dev@swift.org> wrote: > > I wouldn’t phrase it this way. “nil” could just as easily been above all > of the integers. > > We added overloads for < and friends that took optionals so that you could > sort an array by passing < and get something reasonable out without having > to provide your own comparison function, but you’re not the first to find > it counterintuitive. We could consider removing it (going through the Swift > Evolution Process > <https://github.com/apple/swift-evolution/blob/master/process.md>). > > > 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. > > Joe, is this something that you think will come up for discussion in the > Swift 3 timeframe? > > > Yes - I believe so. I’ve been collecting my notes on the topic, with the > hopes of getting a pitch out to swift-evolution soon. > > > Awesome, thanks! > > -Chris >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
