<div><br><div class="gmail_quote"><div>On Mon, May 22, 2017 at 10:39 Haravikk &lt;<a href="mailto:swift-evolution@haravikk.me">swift-evolution@haravikk.me</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 22 May 2017, at 15:51, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div></div></blockquote><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div>If we&#39;re to speak of intuition for new developers who&#39;ve never used a programming language, who are falling back to what they know about mathematics, then quite literally a decimal point _is_ about division by ten.</div></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I don&#39;t think this necessarily follows; the issue here is that the constructor isn&#39;t explicit enough that it is simply lopping off the fractional part. My own experience of maths as taught in school, to go from a decimal to an integer I would expect to round,</div></div></div></blockquote><div><br></div><div>You would also expect that 3 / 4 in integer math gives you 1. With integer division, however, 3 / 4 == 0. By definition the decimal point separates an integer from a fractional part, so the behaviors are inextricably linked. To test this out in practice, I asked the first person with no programming experience I just encountered today.</div><div><br></div><div>I said: &quot;Let me teach you one fact about integers in a programming language. When two integers are divided, the integer result has the fractional part discarded; for example, 3/4 computes to 0. What would you expect to be the result of converting 0.75 to an integer?&quot;</div><div><br></div><div>He answered immediately: &quot;I would have expected that 3/4 gives you 1, but since 3/4 gives you 0, I&#39;d expect 0.75 to convert to 0.&quot;</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>so I think it&#39;s reasonable that Swift should be clear. While it is reflected in the documentation, a good choice of label would allow it to be explicit at the point of use, without requiring a look up each time there is uncertainty.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div><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 style="word-wrap:break-word"><div><span class="m_-4730503486910573711gmail-m_1469358765824769812Apple-tab-span" style="font-family:Monaco;white-space:pre-wrap">        </span><span style="font-family:Monaco">func init(truncating:Float) { … }</span></div></div></blockquote><div><br></div><div>Again, this particular naming suggestion has been discussed as part of the review of integer protocols and not adopted. The rationale was that the term &quot;truncating&quot; is intended to be left for bit patterns only. The term in Swift is exclusively &quot;rounded toward zero.&quot;<br></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>As I understand it truncation is a term of art from C at least (rounding toward zero is the trunc function I believe?), it also makes sense given that what&#39;s happening is that the fractional part is being discarded, regardless of how how high it may be. init(roundTowardZero:Float) seems like it would be very unwieldy by comparison just because truncating is arbitrarily reserved for bit operations.</div><div><br></div><div>Also, when it comes down to it, discarding the fractional part of a float <b>is</b> a bit-pattern operation of a sort,</div></div></div></blockquote><div><br></div><div>Discarding the fractional part of a floating point value is a bit pattern operation only in the sense that any operation on any data is a bit pattern operation. It is clearly not, however, an operation truncating a bit pattern.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>as the conversion is simplistically taking the significand, dropping it into an Int then shifting by the exponent.</div></div></div></blockquote><div><br></div><div>That&#39;s not correct. If you shift the significand or the significand bit pattern of pi by its exponent, you don&#39;t get 3.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div><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 style="word-wrap:break-word"><div><font face="Monaco"><span class="m_-4730503486910573711gmail-m_1469358765824769812Apple-tab-span" style="white-space:pre-wrap">        </span>func init(rounding:Float, _ strategy: FloatingPointRoundingRule) { … }</font></div></div></blockquote><div><br></div><div>Again, here, as an addition to the API, this fails the six criteria of Ben Cohen, as it is strictly duplicative of `T(value.rounded(strategy))`.</div></div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div></div><div>Maybe, but init(rounding:) is explicit that something is being done to the value, at which point there&#39;s no obvious harm in clarifying what (or allowing full freedom). While avoiding redundancy is good as a general rule, it doesn&#39;t mean there can&#39;t be any at all if there&#39;s some benefit to it; in this case clarity of exactly what kind of rounding is taking place to the Float/Double value.</div></div></blockquote><div><br></div><div>The bar for adding new API to the standard library is *far* higher than &quot;some benefit&quot;; `Int(value.rounded(.up))` is the approved spelling for which you are proposing a second spelling that does the same thing.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote></div></div>