Is it reasonable to think that the hypothetical type promotion system that Chris Lattner was alluding to *might* result in function signatures that are subtly different than what you’re proposing? If so, I’d be very hesitant to introduce them into the standard library. Perhaps there could be a “PossiblySketchyInSwift4MathStuff” package, once the package manager is ready?
- Dave Sweeris > On Mar 30, 2016, at 6:10 PM, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> wrote: > > Would a valid stop-gap be to define operators for some of the common cases? > > For example: > > func * (lhs:Double, rhs:Int)->Double > > Are there issues with this approach that I am unaware of? It seems like the > desired cast (and the resulting effect) is obvious there, and you don’t get > surprising casts elsewhere. > > Basically, the rule (as thought of by the programmer) would be in math which > mixes Ints & Doubles, the Int is treated as a double. You could make a > similar rule for Int + CGFloat. > > For math on mixed types, the result IMHO should follow this scale of > promotion (with the parameter farthest left on the scale also being the > result type): > > CGFloat <- Double <- Float <- Int > > I put CGFloat as the highest because in real-world code you often multiply a > CGFloat by a constant Double such as M_PI. I can’t think of many cases where > you have a CGFloat and want anything but a CGFloat in return. > > Thanks, > Jon > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
