<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="">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 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, 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><br class=""><div><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. &nbsp;Once you add implicit type coercions, even just between integer or floating point types, your language gains a hundred unspoken rules and little guard rails you have to cling to lest you slip and hit the next pitfall. &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 and serve as yet another hindrance to novices trying to adopt the language.&nbsp;</div><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, 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 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). 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 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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>