<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=""><div class="">Hi Xiaodi </div><div class=""><br class=""></div><div class="">in 1966-1970 PL/I, a static-typed procedural block-structured programming language</div><div class="">far ahead of its time, with the purpose of giving "all things to all programmers” </div><div class="">was introduced by IBM as their main (mainframe) programming flagship.</div><div class=""><br class=""></div><div class="">I’ve worked with PL/I very often during my life. It is truly general purpose and has tons </div><div class="">of features and is because of that quite overwhelming for starters like me in 1976 after </div><div class="">Fortran as my first PL. PL/I is a bit like riding a gigantic powerful motor cycle without </div><div class="">much instruction from the start and without training wheels back then of course. </div><div class="">Took some time to master PL/I (no screens let alone IDEs back then), however, with </div><div class="">the great reward to be in control of one of the most powerful PLs on the planet.</div><div class=""><br class=""></div><div class="">You might ask, what’s the context of this somewhat nostalgic emission: :o) </div><div class=""><br class=""></div><div class="">PL/I also has many data types like Binary, Bit, Character Complex, Decimal</div><div class="">Fixed, Float,Picture etc. of various lengths and storage</div><div class="">.</div><div class="">Implicit data type conversion (coercion) between almost all PL/I data types has </div><div class="">been available in PL/I right from the start. No problem - that is if you know what you are doing.</div><div class="">What exactly to expect from conversions in PL/I is always predictable, also</div><div class="">because it is described in detail in the programming manuals.</div><div class="">Furthermore PL/I diagnostics and warnings are excellent. </div><div class=""><br class=""></div><div class="">So, implicit data type conversion (coercion) has been successfully implemented and used in an </div><div class="">already complex programming language (in some cases far more advanced as Swift - apart from</div><div class="">OOP) almost 40 years ago… </div><div class="">It is now 2017 and you’re telling me that coercion is too difficult to implement in Swift ?? </div><br class=""><div><blockquote type="cite" class=""><div class="">On 16. Jun 2017, at 18:19, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</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=""></div></blockquote><div>It should be not so difficult I think… as it simply replaces</div><div>explicit casts and the compiler can detect implicit conversions easily; </div><div>be it in assignments, with expression operands or as call parameters. </div><div><br class=""></div><blockquote type="cite" class=""><div 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=""></div></blockquote>Yes, can’t react on this need more information, I don’t see this in context of “user expectations” either.</div><div><br class=""></div><div>btw, I was merely discussing Floating Point conversion <=> Integers? </div><div><br class=""><div><br class=""></div><blockquote type="cite" class=""><div class="">Implicit promotion would be much more complicated. </div></blockquote><div>Why do you think so? </div><div>float = double // compiler inferred type conversion, what’s so difficult about this assignment?</div><div><div>Currently you’d have to use </div><div>float = Float(double) // and you’re doing (explicitly) exactly the same thing. </div><div><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class="">There is little point in discussing whether such a feature in the abstract is desirable or not. </div></blockquote><div>Abstract? I don’t think so and have described this subject fairly concrete, </div><div>illustrated with some examples. </div><div>To me and certainly also many others this feature is desirable.</div><div>As your say yourself</div><div>“it has been brought forward so many times” </div><div>Obviously many desire this feature and find this important.</div><br class=""><blockquote type="cite" class=""><div class="">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. </div></blockquote>after gathering more insight, yes. <br class=""><br class=""><blockquote type="cite" class=""><div class="">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=""><div class="gmail_quote"></div></div></blockquote>As you know, Swift currently does not facilitate implicit conversion (coercion),</div><div>which implies that current code (which of course does not contain implicit conversions) </div><div>will function exactly as it does now, when it was compiled in a Swift version in which</div><div>implicit conversion were implemented. </div><div><br class=""></div><div>Kind Regards,</div><div>TedvG</div><div><a href="http://www.tedvg.com" class="">www.tedvg.com</a></div><div><br class=""></div><div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div 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>
</div></blockquote></div><br class=""></body></html>