<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 &lt;<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>&gt; 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. &nbsp;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,&nbsp;</div><div>these rules are extremely bureaucratic, restricting and always far behind fast developments in&nbsp;</div><div>IT. &nbsp; Would you like to see Swift to be ISO compliant?&nbsp;</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: &nbsp;</div><div><br class=""></div><div>is there a desire/requirement to make Swift ISO compliant?&nbsp;</div><div>and thus therewith restricting Swift’s flexibility? If so, to what extent?&nbsp;</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. &nbsp;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. &nbsp;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.&nbsp;</div><div>and I am telling the compiler implicitly:&nbsp;</div><div>aFloat = anInt &nbsp;// The compiler will use a builtin function to do the conversion. what can be wrong with that?&nbsp;</div><div>Again, in the cases I mentioned there is no data loss. (precision excluded)&nbsp;</div><div>&nbsp;</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 &lt;<a href="mailto:tedvgiosdev@gmail.com" class="">tedvgiosdev@gmail.com</a>&gt; のメッセージ:<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 &amp; 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 &lt;<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>&gt; 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? &nbsp;and &nbsp; What cannot be guaranteed?&nbsp;</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&nbsp;</div><div class="">10000 -becomes e.g - 9999.999999, (depending on magnitude, of course)&nbsp;</div><div class="">but that is normal in a floating point domain; E.g. &nbsp;also with:&nbsp;</div><div class="">&nbsp; &nbsp; &nbsp;var v:Double &nbsp;= 10000.0 &nbsp; &nbsp; &nbsp; // &nbsp; Double to Double&nbsp;</div><div class=""><br class=""></div><div class="">v would have the same imprecision… and could be anywhere between 9999.9998…10000.00001 &nbsp;</div><div class="">(rough estimation, depending on magnitude and the floating point type used)&nbsp;</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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">&nbsp;often occurring simple example here:</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>for i in 0..&lt;10</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; dTemperature = dInterval * i &nbsp; &nbsp; &nbsp; &nbsp; / / &nbsp; Double = Double * Int &nbsp;(not possible yet in Swift)</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;foo(dTemperature) &nbsp;</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</div><div class="">&nbsp;</div><div class="">&nbsp; &nbsp; &nbsp; Here I still have to write: &nbsp; &nbsp;&nbsp;</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dTemperature = dInterval * Double(i) &nbsp; &nbsp; &nbsp;&nbsp;</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; &nbsp; However, Swift will accept:&nbsp;</div><div class=""><div class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dTemperature = dInterval * 3 &nbsp; &nbsp; &nbsp; &nbsp;// 3 inferred to Double. could be regarded as an implicit conversion?&nbsp;</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; &nbsp;&nbsp;</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="">&nbsp;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? &nbsp;</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="">&nbsp;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&nbsp;</div><div class="">cannot be fully predicted and understood, there are simply too many possibilities,&nbsp;</div><div class="">Functional Programming attempts to solve this, trying to make/do everything mathematically&nbsp;</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.&nbsp;</div></div></div></div></blockquote></div></div></div></blockquote>I don’t agree here. Even novices should have a good understanding&nbsp;</div><div class="">of the basic data types of a programming language,</div><div class="">Also note that &nbsp;concepts of integer, natural, rational, irrational numbers etc.</div><div class="">is very basic mathematics as learned in high school.&nbsp;</div><div class="">or your country’s equivalent education.&nbsp;</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">So aDouble = anInt &nbsp;should -in the programmer’s mind-&nbsp;</div><div class="">appear as an explicit conversion, that is, he/she should realize the consequences.&nbsp;</div><div class="">The same applies also doing it explicitly like so:</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp;</div><div class="">&nbsp; &nbsp; &nbsp;aDouble = Double(anInt) &nbsp; &nbsp;</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]. &nbsp;Sure, it is always defined behavior to "downcast" a value of a lower bitwidth to one of a higher bitwidth, but to dismiss Int -&gt; Float, Float -&gt; Int, </div></div></div></div></blockquote></div></div></div></blockquote>I wrote that I don’t want implicit conversion for Float -&gt; Int.&nbsp;<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 -&gt; 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 -&gt; Float is problematic (apart from loosing precision) ?&nbsp;</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. &nbsp;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="">&nbsp; -=side note: =-</div><div class="">Thanks for bringing Idris to my attention. Investigating...&nbsp;</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. &nbsp;</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 &nbsp;delegating/callbacks.</div><div class="">&nbsp; -= end side note =-&nbsp;</div><div class="">&nbsp;</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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; のメッセージ:<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&nbsp;</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&nbsp;</div><div class="">of floating point types CGFloat, Float, and Double&nbsp;</div><div class="">is really very annoying.&nbsp;</div><div class=""><br class=""></div><div class="">Conversion beween floating point types is always harmless as&nbsp;</div><div class="">floating point types are essentially the same.&nbsp;</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 &nbsp;</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&nbsp;</div><div class="">and that assigning a too large float to an Integer would then cause&nbsp;</div><div class="">a run time error, which I can try/catch, of course.&nbsp;</div><div class=""><br class=""></div><div class="">-from unsigned integer to signed integer &nbsp;&nbsp;</div><div class="">(nothing is lost here, but overflow should cause a run time error)&nbsp;</div><div class=""><br class=""></div><div class="">but no implicit conversion for:</div><div class="">- from integer to unsigned integer &nbsp; (loosing sign here)</div><div class="">- from a larger integer type to a smaller one e.g. &nbsp; Int32 &lt;- Int64 &nbsp; (truncation) &nbsp;</div><div class=""><br class=""></div><div class="">Note however, that the compiler should issue warnings&nbsp;</div><div class="">when you do implicit conversions, but these warnings&nbsp;</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&nbsp;</div><div class="">that bringing integers into the floating point domain&nbsp;</div><div class="">causes precision loss.&nbsp;</div><div class="">He/she also knows that assigning a Double to a smaller floating</div><div class="">point type also cause precision loss. &nbsp;</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&nbsp;</div><div class="">the fixed decimal numerical type as this type is not yet</div><div class="">available in Swift. &nbsp;However, it should be &nbsp;implemented&nbsp;</div><div class="">*as soon as possible* &nbsp;because the fixed decimal type&nbsp;</div><div class="">is really needed for applications working with financial data!</div><div class="">E.g.&nbsp;</div><div class="">var depositPromille: Decimal(10,3)</div><div class="">typealias &nbsp;Money = Decimal(20,2)&nbsp;</div><div class="">&nbsp;&nbsp;</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:&nbsp;</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”&nbsp;</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)&nbsp;</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>