[swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[davesweeris at mac.com]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution