<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 30.03.2016, at 20:29, Developer <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</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="">I believe section 6.3 of the ISO/C99 specification describes its integer promotion rules and Appendix J describes undefined behavior as a consequence of integer and floating point coercion. I refer to these when I speak of "rules”.</div></div></div></blockquote>Although ISO compliance makes sense in a lot of cases, for programming languages, </div><div>these rules are extremely bureaucratic, restricting and always far behind fast developments in </div><div>IT. Would you like to see Swift to be ISO compliant? </div><div>Then you could throw away perhaps more than half the language constructs</div><div>currently present in Swift?</div><div><br class=""></div><div>@Chris: </div><div><br class=""></div><div>is there a desire/requirement to make Swift ISO compliant? </div><div>and thus therewith restricting Swift’s flexibility? If so, to what extent? </div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">As long as data loss is an "unintended" effect of a certain class of coercions, I don't believe it deserves to be implicit. If you "know what you're doing", the preference so far has been to tell the compiler that and use the constructors provided in the Swift Standard Library to perform explicit truncation. Even in C, if you can be more specific with a cast in cases where you intend data loss, you probably should be.<br class=""></div></div></div></blockquote>With all due respect, Robert, Imho, I find this all too theoretical and bureaucratic and tons of unnecessary overhead. </div><div>and I am telling the compiler implicitly: </div><div>aFloat = anInt // The compiler will use a builtin function to do the conversion. what can be wrong with that? </div><div>Again, in the cases I mentioned there is no data loss. (precision excluded) </div><div> </div><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""><div class="">~Robert Widmann</div></div><div class=""><br class="">2016/03/30 13:57、Ted F.A. van Gaalen <<a href="mailto:tedvgiosdev@gmail.com" class="">tedvgiosdev@gmail.com</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">Thank you, Robert & Haravikk<div class="">Please allow me to respond in-line hereunder, thanks.<div class="">Ted.<br class=""><div class=""><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 class="">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 class="">10000 -becomes e.g - 9999.999999, (depending on magnitude, of course) </div><div class="">but that is normal in a floating point domain; E.g. also with: </div><div class=""> var v:Double = 10000.0 // Double to Double </div><div class=""><br class=""></div><div class="">v would have the same imprecision… and could be anywhere between 9999.9998…10000.00001 </div><div class="">(rough estimation, depending on magnitude and the floating point type used) </div><div class=""><br class=""></div><div class=""><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 class=""> often occurring simple example here:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for i in 0..<10</div><div class=""> {</div><div class=""> dTemperature = dInterval * i / / Double = Double * Int (not possible yet in Swift)</div><div class=""> foo(dTemperature) </div><div class=""> }</div><div class=""> </div><div class=""> Here I still have to write: </div><div class=""> dTemperature = dInterval * Double(i) </div><div class=""><br class=""></div><div class=""> However, Swift will accept: </div><div class=""><div class=""> dTemperature = dInterval * 3 // 3 inferred to Double. could be regarded as an implicit conversion? </div><div class=""><br class=""></div><div 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=""> 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 class=""><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 class="">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 class="">In practice, the implications/effects/behavior of a programming language </div><div class="">cannot be fully predicted and understood, there are simply too many possibilities, </div><div class="">Functional Programming attempts to solve this, trying to make/do everything mathematically </div><div class="">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 class="">of the basic data types of a programming language,</div><div class="">Also note that concepts of integer, natural, rational, irrational numbers etc.</div><div class="">is very basic mathematics as learned in high school. </div><div class="">or your country’s equivalent education. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">So aDouble = anInt should -in the programmer’s mind- </div><div class="">appear as an explicit conversion, that is, he/she should realize the consequences. </div><div class="">The same applies also doing it explicitly like so:</div><div class=""> </div><div class=""> aDouble = Double(anInt) </div><div class="">Same effect: even a fool can use this as well and not knowing the implications.</div><div class=""><br class=""></div><div class=""><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 class=""><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 class="">Please spare me from this kind of contraptions.</div><div class=""><br class=""></div><div class=""> -=side note: =-</div><div class="">Thanks for bringing Idris to my attention. Investigating... </div><div class="">Idris is a FP language. I am not against it, but to me, FP is almost unreadable.</div><div class="">I doubt if I will ever use it. </div><div class="">I use strictly OOD/OOP. It’s natural. Like in Smalltalk. Proven. Solid.</div><div class="">For now, the only reason I use protocols in Swift are to accommodate delegating/callbacks.</div><div class=""> -= end side note =- </div><div class=""> </div><div class=""><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 class="">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 class="">TedvG</div><div class=""><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></div></blockquote></div></div></blockquote></div><br class=""></body></html>