<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 <<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. 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. 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. </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]. 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, 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 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). 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 <<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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>