Implicit promotion has been brought up on the list before, many times over many years. The scale and implications of the change not to be underestimated.
To give a taste of what would be involved, consider that new integer protocols were recently implemented that allow heterogeneous comparison; these have proved to be tricky to implement in a way that preserves user expectations in the context of integer literals. (I will write shortly with thoughts on revisiting certain specifics.) Implicit promotion would be much more complicated. There is little point in discussing whether such a feature in the abstract is desirable or not. It would be necessary to have a detailed proposed design and evaluate whether the specific design is desirable, in light of its interactions with other parts of the system. For one, I think it’s important that no code that is currently legal produce a different result: this in itself is not trivial to achieve. On Fri, Jun 16, 2017 at 11:08 Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote: > Hello, > > Appr. a year ago I suggested to allow implicit conversion between floating > point number types, > that is between Float, CGFloat Double..Float80 … > (Note that CGFloat IS a Double on 64-bit systems btw), > > E.g I am currently making things using SceneKit 3D, wich obviously > involves a lot > of floating point arithmetic, using functions from several libraries where > some use Floats, others Double or CGFloat etc.. > That wouldn't be so bad, were it not that all the work that I do contains > a lot of of unavoidable explicit Floating point conversions like so: > > let ypos = CGFloat(1080.0 - (yGravity * yfactor)) // double in expression > to CGFloat > > camera1.reorientate ( > SCNVector3(x: Float(motionGravityY * -0.08), > y: Float(motionGravityX * -0.1), > z: roll ) ) > > This is tedious and makes source less readable. > > With implicit floating point number conversion It could be like this > > var float1,float2,float3: Float > var double1,double2,double3: Double > var cgfloat1, cgfloat2, ccgfloat3 CGFloat > > float1 = cgfloat2 * double3 + float1 // implicit conversion should be > allowed (whereby everything > in the expression should be promoted to the highest precision var in the > expression (Double here) > which then would be type wise: > Float = CGFloat(implicitly. promoted to Double) * Double) + Float (imp. > promoted to Double) > > Also, implicit conversion when passing function parameters would be very > convenient as well e.g. > > This function: > func someMath(p1: Float, p2: Float, result: Inout Float) {…} > > could then be called without explicit conversion like so: > > someMath(p1: double1, p2: cgfloat1, result: &double3) > > // yes, also on inout parameters. This is done 2 times during the call and > when returning. > > > As I vaguely remember there were objections to this implicit conversion > of FP numbers, > because this was (as viewed back then) too complicated to implement? > > Note that people that regularly work with floating point numbers are > well aware about having a precision loss when e.g. when converting > from Double to Float, or indeed between other numerical types as well > no problem. > > For those not desiring such flexibility, there could be a new compiler > option(s) > that disallows this freedom of implicit floating point number conversion. > > or have at least (suppressible) compiler warnings about precision loss, > e.g when doing this: float = double.. > > ? > > Kind Regards from Speyer, Germany > TedvG > > > > > > > > > > > > > > _______________________________________________ > 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