<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Has it been proposed to eventually make CGFloat into a typealias for Double to reduce the amount of explicit conversion necessary? (I realize as a proposal this would be better suited for corelibs-libfoundation)<div class=""><br class=""></div><div class="">- For Apple platforms, eventually CGFloat will *always* be a Double value, as Swift does not have a 32-bit OS X runtime, and my understanding is that new builds are no longer accepted via the App Store for 32 bit IOS versions. I believe this would limit Apple platform impact to 32-bit iOS apps shipped outside the App Store which have upgraded to some future version of XCode.</div><div class=""><br class=""></div><div class="">- Within corelibs-libfoundation, I believe CGFloat is only used for CGPoint and NSAfflineTransform. How useful is it to have these be 32 bit on a 32 bit target, where they aren’t being defined as floats for compatibility?</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 16, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Jun 16, 2017 at 11:08 Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></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" class="">Hello,<div class=""><br class=""></div><div class="">Appr. a year ago I suggested to allow implicit conversion between floating point number types,</div><div class="">that is between Float, CGFloat Double..Float80 … </div><div class="">(Note that CGFloat IS a Double on 64-bit systems btw),</div><div class=""><br class=""></div><div class="">E.g I am currently making things using SceneKit 3D, wich obviously involves a lot</div><div class="">of floating point arithmetic, using functions from several libraries where</div><div class="">some use Floats, others Double or CGFloat etc.. </div><div class="">That wouldn't be so bad, were it not that all the work that I do contains</div><div class="">a lot of of unavoidable explicit Floating point conversions like so:</div><div class=""><br class=""></div><div class="">let ypos = CGFloat(1080.0 - (yGravity * yfactor)) // double in expression to CGFloat</div><div class=""><br class=""></div><div class="">camera1.reorientate (<br class=""> SCNVector3(x: Float(motionGravityY * -0.08),<br class=""> y: Float(motionGravityX * -0.1),<br class=""> z: roll ) )</div><div class=""><br class=""></div><div class="">This is tedious and makes source less readable.</div><div class=""><br class=""></div><div class="">With implicit floating point number conversion It could be like this</div><div class=""><br class=""></div><div class="">var float1,float2,float3: Float</div><div class="">var double1,double2,double3: Double</div><div class="">var cgfloat1, cgfloat2, ccgfloat3 CGFloat </div><div class=""><br class=""></div><div class="">float1 = cgfloat2 * double3 + float1 // implicit conversion should be allowed (whereby everything </div><div class="">in the expression should be promoted to the highest precision var in the expression (Double here) </div><div class="">which then would be type wise: </div><div class="">Float = CGFloat(implicitly. promoted to Double) * Double) + Float (imp. promoted to Double) </div><div class=""><br class=""></div><div class="">Also, implicit conversion when passing function parameters would be very convenient as well e.g.</div><div class=""><br class=""></div><div class="">This function: </div><div class=""> func someMath(p1: Float, p2: Float, result: Inout Float) {…}</div><div class=""><br class=""></div><div class="">could then be called without explicit conversion like so:</div><div class=""><br class=""></div><div class=""> someMath(p1: double1, p2: cgfloat1, result: &double3) </div><div class=""><br class=""></div><div class="">// yes, also on inout parameters. This is done 2 times during the call and when returning.</div><div class=""> </div><div class=""><br class=""></div><div class="">As I vaguely remember there were objections to this implicit conversion of FP numbers,</div><div class="">because this was (as viewed back then) too complicated to implement?</div><div class=""><br class=""></div><div class="">Note that people that regularly work with floating point numbers are</div><div class="">well aware about having a precision loss when e.g. when converting</div><div class="">from Double to Float, or indeed between other numerical types as well </div><div class="">no problem.</div><div class=""><br class=""></div><div class="">For those not desiring such flexibility, there could be a new compiler option(s)</div><div class="">that disallows this freedom of implicit floating point number conversion.</div><div class=""><br class=""></div><div class="">or have at least (suppressible) compiler warnings about precision loss,</div><div class="">e.g when doing this: float = double.. </div><div class=""><br class=""></div><div class="">?</div><div class=""><br class=""></div><div class="">Kind Regards from Speyer, Germany</div><div class="">TedvG</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>