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.
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.
The major problem with this is type checker scalability. It would drive it to be much more exponential than it is today, by completely exploding the overload sets for these operators.
-Chris
···
On Mar 30, 2016, at 4: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.