<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="">Thank you, Robert & Haravikk<div class="">Please allow me to respond in-line hereunder, thanks.<div class="">Ted.<br class=""><div><blockquote type="cite" class=""><div class="">On 30.03.2016, at 16:15, Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I’m in favour of implicit conversion for integers where no data can be lost (UInt32 to Int64, Int32 to Int64 etc.), in fact I posted a similar thread a little while ago but can’t find it; there’s something being done with numbers so this may be partly in the works.</div><div class=""><br class=""></div><div class="">I definitely think that implicit conversion for floating point should be avoided, as it can’t be guaranteed </div></div></div></blockquote><div>Why? and What cannot be guaranteed? </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">except in certain edge cases; for example, Javascript actually technically uses a double for all of its numeric types, effectively giving it a 52-bit (iirc) integer type,</div></div></div></blockquote>awful, didn’t know that<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> so in theory conversion of Int32 to Double is fine, and Int16 to Float might be as well, but I’m not certain if it’s a good idea or not, as it’s not quite the same as just extending the value.</div></div></div></blockquote>It simply would cause a float with less precision as an integer like </div><div>10000 -becomes e.g - 9999.999999, (depending on magnitude, of course) </div><div>but that is normal in a floating point domain; E.g. also with: </div><div> var v:Double = 10000.0 // Double to Double </div><div><br class=""></div><div>v would have the same imprecision… and could be anywhere between 9999.9998…10000.00001 </div><div>(rough estimation, depending on magnitude and the floating point type used) </div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 30 Mar 2016, at 14:57, Developer 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class="">What you describe, all those cases where one fixes losing precision by simply "ignoring it", that's part of why I'm hesitant about simply throwing in C-like promotion rules into any language. </div></div></div></div></blockquote></div></div></div></blockquote><br class="">E.g. if I assign an Int to a Double, then I know very well what I am doing.</div><div> often occurring simple example here:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>for i in 0..<10</div><div> {</div><div> dTemperature = dInterval * i / / Double = Double * Int (not possible yet in Swift)</div><div> foo(dTemperature) </div><div> }</div><div> </div><div> Here I still have to write: </div><div> dTemperature = dInterval * Double(i) </div><div><br class=""></div><div> However, Swift will accept: </div><div><div> dTemperature = dInterval * 3 // 3 inferred to Double. could be regarded as an implicit conversion? </div><div><br class=""></div><div> </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""> Once you add implicit type coercions, even just between integer or floating point types, your language gains a hundred unspoken rules</div></div></div></div></blockquote></div></div></div></blockquote>Could you please explain these “unspoken rules” you mention more in detail? </div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""> and little guard rails you have to cling to lest you slip and hit the next pitfall. </div></div></div></div></blockquote></div></div></div></blockquote><div>I am counting on the average intelligence of programmers.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""> Though you may be dismissive of information loss, it is a serious issue in coercions, and one with implications that are never completely grokked by experts</div></div></div></div></blockquote></div></div></div></blockquote><div>In practice, the implications/effects/behavior of a programming language </div><div>cannot be fully predicted and understood, there are simply too many possibilities, </div><div>Functional Programming attempts to solve this, trying to make/do everything mathematically </div><div>correct but fails for the aforementioned reason.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">and serve as yet another hindrance to novices trying to adopt the language. </div></div></div></div></blockquote></div></div></div></blockquote>I don’t agree here. Even novices should have a good understanding </div><div>of the basic data types of a programming language,</div><div>Also note that concepts of integer, natural, rational, irrational numbers etc.</div><div>is very basic mathematics as learned in high school. </div><div>or your country’s equivalent education. </div><div><br class=""></div><div><br class=""></div><div>So aDouble = anInt should -in the programmer’s mind- </div><div>appear as an explicit conversion, that is, he/she should realize the consequences. </div><div>The same applies also doing it explicitly like so:</div><div> </div><div> aDouble = Double(anInt) </div><div>Same effect: even a fool can use this as well and not knowing the implications.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><br class=""></div><div class="">So, I don't think coercion under this scheme is the complete end-all-be-all solution to this problem, [though it may certainly <i class="">feel</i> right]. Sure, it is always defined behavior to "downcast" a value of a lower bitwidth to one of a higher bitwidth, but to dismiss Int -> Float, Float -> Int, </div></div></div></div></blockquote></div></div></div></blockquote>I wrote that I don’t want implicit conversion for Float -> Int. <br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">and Double -> Float, etc. coercions as mere trifles is an attitude I don't want enshrined in the language's type system.</div><div class=""><br class=""></div></div></div></div></blockquote></div></div></div></blockquote>Could you give me an example where Double -> Float is problematic (apart from loosing precision) ? </div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">Perhaps there is a middle ground. Say, one could declare conformance to a special kind of protocol declaring safe implicit convertibility (see: Idris' solution of having an `implicit` conversion mechanism). </div></div></div></div></blockquote></div></div></div></blockquote><div>Please spare me from this kind of contraptions.</div><div><br class=""></div><div> -=side note: =-</div><div>Thanks for bringing Idris to my attention. Investigating... </div><div>Idris is a FP language. I am not against it, but to me, FP is almost unreadable.</div><div>I doubt if I will ever use it. </div><div>I use strictly OOD/OOP. It’s natural. Like in Smalltalk. Proven. Solid.</div><div>For now, the only reason I use protocols in Swift are to accommodate delegating/callbacks.</div><div> -= end side note =- </div><div> </div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">Or perhaps a good first step may be to not deal with information loss at all, and only keep the parts of this proposal that are always defined behavior.</div></div></div></div></blockquote></div></div></div></blockquote>To me, there is no unintended information loss, because I know what I am doing regarding implicit conversion.</div><div>Then again, in all the cases for which I suggested implicit data type conversion, there is no data loss (apart from precision)<br class=""><br class=""></div><div>TedvG</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><br class=""></div><div class=""><div class="">~Robert Widmann</div></div><div class=""><br class="">2016/03/30 8:01、Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">Currently, one has to deal with explicit conversion between numerical types,</div><div class="">which in many cases is unnecessary and costing time to code </div><div class="">for things that are quite obvious,</div><div class="">and cluttering the source, making it less readable.</div><div class=""><br class=""></div><div class="">Especially dealing all the time with often unavoidable intermixing </div><div class="">of floating point types CGFloat, Float, and Double </div><div class="">is really very annoying. </div><div class=""><br class=""></div><div class="">Conversion beween floating point types is always harmless as </div><div class="">floating point types are essentially the same. </div><div class="">They differ only in precision.</div><div class=""><div class=""><br class=""></div><div class="">Therefore, I would recommend allowing the following implicit type conversions:</div><div class=""><br class=""></div><div class="">-between all floating point types e.g. Double, Float, CGFloat </div><div class=""><br class=""></div><div class="">-from any integer type to floating point types</div><div class=""><br class=""></div><div class="">-Also, personally, I wouldn’t mind assigning from a float to a (signed) integer</div><div class="">because I know what I am doing: that the fraction is lost </div><div class="">and that assigning a too large float to an Integer would then cause </div><div class="">a run time error, which I can try/catch, of course. </div><div class=""><br class=""></div><div class="">-from unsigned integer to signed integer </div><div class="">(nothing is lost here, but overflow should cause a run time error) </div><div class=""><br class=""></div><div class="">but no implicit conversion for:</div><div class="">- from integer to unsigned integer (loosing sign here)</div><div class="">- from a larger integer type to a smaller one e.g. Int32 <- Int64 (truncation) </div><div class=""><br class=""></div><div class="">Note however, that the compiler should issue warnings </div><div class="">when you do implicit conversions, but these warnings </div><div class="">are for most programmers of the “Yeah I know, don’t bug me.”</div></div><div class="">type, so one should be able to switch off these type of warnings.</div><div class=""><br class=""></div><div class="">Even a programmer with little experience simply knows </div><div class="">that bringing integers into the floating point domain </div><div class="">causes precision loss. </div><div class="">He/she also knows that assigning a Double to a smaller floating</div><div class="">point type also cause precision loss. </div><div class="">the reverse is not true.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Very much interested in your opinion!</div><div class=""><br class=""></div><div class="">----</div><div class="">N.B. the above does not yet include </div><div class="">the fixed decimal numerical type as this type is not yet</div><div class="">available in Swift. However, it should be implemented </div><div class="">*as soon as possible* because the fixed decimal type </div><div class="">is really needed for applications working with financial data!</div><div class="">E.g. </div><div class="">var depositPromille: Decimal(10,3)</div><div class="">typealias Money = Decimal(20,2) </div><div class=""> </div><div class="">For more info on how this could be implemented</div><div class="">in Swift. please read a PL/1 manual, ( i grew up in this world)</div><div class="">like this one: </div><div class=""><br class=""></div><div class=""><a href="http://www.ibm.com/support/knowledgecenter/#!/SSY2V3_4.3.0/com.ibm.entpli.doc_4.3/lr/preface_plugin.htm" class="">http://www.ibm.com/support/knowledgecenter/#!/SSY2V3_4.3.0/com.ibm.entpli.doc_4.3/lr/preface_plugin.htm</a></div><div class=""><br class=""></div><div class="">especially under sub-topic “Data elements” </div><div class=""><br class=""></div><div class=""><div class="">(however, don’t take everything for granted, PL/1 is still a very young language :o) </div></div><div class="">Unfortunately OOP never made it into PL/1 because with it, it would be nearly perfect.)</div><div class=""><br class=""></div><div class="">Should I make a new swift-evolution topic for fixed decimal?</div><div class=""><br class=""></div><div class="">Kind Regards</div><div class="">TedvG</div><div class=""><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>