<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="">This is getting too muddled, so I'm going to summarise thusly; I believe the principle the OP raised is sound, that any initialiser performing a lossy conversion from another type should be clear that this happening, and that a label can do that best, as it makes the conversion self-documenting at the call-site.</div><div class=""><br class=""></div><div class="">Consider for example; with type-inference it's not always obvious what the type of a variable is, and an unlabelled initialiser does nothing to help, like-so:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var someValue = someMethod()</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>…</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var someInt = Int(someValue)</font></div><div class=""><br class=""></div><div class="">At a glance it's not all obvious what is happening to someValue here; in fact I'd argue that this looks like a lossless conversion, requiring you to find out that someMethod() returns a Float before you can know for sure what's really going on. Whereas the following is more clear:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var someValue = someMethod()</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>…</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var someInt = Int(truncating: someValue)</font></div><div class=""><br class=""></div><div class="">It may not communicate everything that's happening, but at least now it's clear at a glance that <b class="">something</b> is happening, and the term truncating suggests that something is being lost/removed from someValue.</div><div class=""><br class=""></div><div class="">Now I don't really care if truncating is the best term for it or not, though I do still think it is and won't change my mind on that; the key thing here is that it's providing that extra safety to developers by making it clear that an important conversion is taking place, and this to me is more consistent with other initialisers on Int etc. where distinctions are made between types that can and cannot be represented exactly.</div><div class=""><br class=""></div><div class="">I'm not saying it should be limited to floats either; I think any initialiser that cannot, or may not, represent the passed value accurately should be labelled for clarity. So passing an Int16 into Int32(_:) would be fine for example, but the reverse should not be.</div><div class=""><br class=""></div><div class="">It's not just an issue of new developers; experienced ones make mistakes too, or forget to consider whether the conversion will impact their code. A label helps, though I still think forcing a decision on rounding is even better, as both prevent a developer from simply throwing in a value in a way that may be a mistake.</div></body></html>