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.<br><br>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.)<br><br>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.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 16, 2017 at 11:08 Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hello,<div><br></div><div>Appr. a year ago I suggested to allow implicit conversion between floating point number types,</div><div>that is between Float, CGFloat Double..Float80 … </div><div>(Note that CGFloat IS a Double on 64-bit systems btw),</div><div><br></div><div>E.g I am currently making things using SceneKit 3D, wich obviously involves a lot</div><div>of floating point arithmetic, using functions from several libraries where</div><div>some use Floats, others Double or CGFloat etc.. </div><div>That wouldn't be so bad, were it not that all the work that I do contains</div><div>a lot of of unavoidable explicit Floating point conversions like so:</div><div><br></div><div>let ypos = CGFloat(1080.0 - (yGravity * yfactor)) // double in expression to CGFloat</div><div><br></div><div>camera1.reorientate (<br> SCNVector3(x: Float(motionGravityY * -0.08),<br> y: Float(motionGravityX * -0.1),<br> z: roll ) )</div><div><br></div><div>This is tedious and makes source less readable.</div><div><br></div><div>With implicit floating point number conversion It could be like this</div><div><br></div><div>var float1,float2,float3: Float</div><div>var double1,double2,double3: Double</div><div>var cgfloat1, cgfloat2, ccgfloat3 CGFloat </div><div><br></div><div>float1 = cgfloat2 * double3 + float1 // implicit conversion should be allowed (whereby everything </div><div>in the expression should be promoted to the highest precision var in the expression (Double here) </div><div>which then would be type wise: </div><div>Float = CGFloat(implicitly. promoted to Double) * Double) + Float (imp. promoted to Double) </div><div><br></div><div>Also, implicit conversion when passing function parameters would be very convenient as well e.g.</div><div><br></div><div>This function: </div><div> func someMath(p1: Float, p2: Float, result: Inout Float) {…}</div><div><br></div><div>could then be called without explicit conversion like so:</div><div><br></div><div> someMath(p1: double1, p2: cgfloat1, result: &double3) </div><div><br></div><div>// yes, also on inout parameters. This is done 2 times during the call and when returning.</div><div> </div><div><br></div><div>As I vaguely remember there were objections to this implicit conversion of FP numbers,</div><div>because this was (as viewed back then) too complicated to implement?</div><div><br></div><div>Note that people that regularly work with floating point numbers are</div><div>well aware about having a precision loss when e.g. when converting</div><div>from Double to Float, or indeed between other numerical types as well </div><div>no problem.</div><div><br></div><div>For those not desiring such flexibility, there could be a new compiler option(s)</div><div>that disallows this freedom of implicit floating point number conversion.</div><div><br></div><div>or have at least (suppressible) compiler warnings about precision loss,</div><div>e.g when doing this: float = double.. </div><div><br></div><div>?</div><div><br></div><div>Kind Regards from Speyer, Germany</div><div>TedvG</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div><div><br></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>