<div dir="ltr">On Tue, May 23, 2017 at 8:55 PM, Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-">On Tue, May 23, 2017 at 5:27 PM, Guillaume Lessard via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
&gt; On May 23, 2017, at 13:25, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; The doc comments in the proposal text were meant as explanation for readers of the proposal; they undergo editing for accuracy during implementation. That wording is, notably, not found in the implemented protocol.<br>
<br>
</span>What? It shows up in my browser! This is how it looks right now: (in <a href="https://github.com/apple/swift/blob/368847b5c7581b9024347f0a73fc83eb6d9866a8/stdlib/public/core/Integers.swift.gyb#L1366" rel="noreferrer" target="_blank">https://github.com/apple/swift<wbr>/blob/368847b5c7581b9024347f0a<wbr>73fc83eb6d9866a8/stdlib/<wbr>public/core/Integers.swift.<wbr>gyb#L1366</a>)<br>
<span><br>
/// Creates an integer from the given floating-point value, truncating any<br>
/// fractional part.<br>
</span>///<br>
/// Truncating the fractional part of `source` is equivalent to rounding<br>
/// toward zero.<br>
<br>
Let’s not cherry-pick.<br></blockquote><div><br></div></span><div>You are quite right; this is still there, and I didn&#39;t see it! Well, let&#39;s fix that.</div><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Is there another lossy initializer for Int or BinaryInteger that doesn’t have a parameter label?</blockquote></span></div></div></div></blockquote><div><br></div><div>Yes. First, the Foundation initializer converting from NSNumber has the same behavior:</div><div><br></div><div>```</div><div>import Foundation</div><div>let x = Int(42.5 as NSNumber) // x == 42</div><div>```</div><div><br></div><div>More broadly, though, there is a default initializer (i.e., one that does not use a label for its argument) for conversion from essentially any standard library numeric type to any other numeric type. Unless every value of the source type is representable in the destination type (e.g., Int8 to Int16), all of these initializers can trap at runtime. Now, you might argue that trapping does not meet your definition of &quot;lossy,&quot; but it certainly causes problems in the example posed above:</div><div><br></div><div>```</div><div>var someValue = someMethod()</div><div>var someInt = Int(someValue)</div><div>// Unless you already know the type of `someValue`, there</div><div>// is absolutely _no_ guarantee that you&#39;ll even reach this</div><div>// point, let alone what the value of `someInt` might be.</div><div>//</div><div>// Trapping is arguably very lossy...</div><div>```</div><div><br></div></div></div></div>