<div dir="ltr"><div>First of all great proposal, and thank you for trying to make it easier to write safe code with Swift.</div><div><br></div>I feel like this proposal is more about human error than floating point error.<div><br></div><div>I don&#39;t think this solves the precision issue. It makes it harder to use fmod, but doesn&#39;t stop people wanting to, life finds a way. I completely agree with your rationale, but if someone wants mod they&#39;ll use mod. The question probably comes down to whether stackoverflow will tell them to use fmod or remainder.<div><br></div><div>Regarding binding % to remainder, I think this is way too unexpected (a much bigger gotcha):</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace">3.0 % 4.0 == -1.0</font></div><div><font face="monospace, monospace">3 % 4 == 3</font></div></blockquote>I don&#39;t think we should change the binding to remainder.<font face="monospace, monospace"><br></font><div><br></div><div>If X.remainder(Y) is added to FloatingPointType I&#39;m fairly neutral about the proposal to remove % on floating point types.</div><div><br></div><div>I feel like the deprecation warning is basically teaching people that instead of using % you now have to use fmod, you haven&#39;t gained anything except making their code less readable. Perhaps an automatic migration is better, or perhaps the warning should make it clear there are potential precision issues.</div><div><br></div><div>The deprecation warning could be something like this:</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>Deprecated due to precision issues, renamed to &#39;fmod&#39;, consider rewriting to use &#39;remainder&#39; instead.</div></div></blockquote><div><div>The issue with this I guess is that it is non-obvious how to change between them, and I suspect attempts could just introduce similar or worse precision issues<font face="arial, helvetica, sans-serif">.</font></div><div><br></div><div>It&#39;s almost a cliché on swift-evolution proposals, but I feel like my main concerns here could almost be solved by a linter.  Has Apple considered adding built-in support for an easily customisable linter? There&#39;s probably an overlap with clang&#39;s static analyser.</div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 19, 2015 at 12:10 PM, Joe Groff 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Dec 18, 2015, at 3:40 PM, August Joki via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><br><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">-August</span></div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div>On 18 Dec, 2015, at 15:31, Kevin Ballard via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div><div>On Fri, Dec 18, 2015, at 03:04 PM, Chris Lattner via swift-evolution wrote:<br></div><blockquote type="cite"><div> </div><div><blockquote type="cite"><div>On Dec 18, 2015, at 3:03 PM, Stephen Canon &lt;<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>&gt; wrote:<br></div><div> </div><div><div style="word-wrap:break-word"><div> </div><div><blockquote type="cite"><div>On Dec 18, 2015, at 5:57 PM, Chris Lattner &lt;<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>&gt; wrote:<br></div><div> </div><div><div style="word-wrap:break-word"><div>On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div>Hi everybody —<br></div><div> </div><div>I’d like to propose removing the “%” operator for floating-point types.<br></div></div></div></blockquote><div> </div><div>I support removing this - it is actively harmful for a surprising operation like this to have such short and inviting syntax.  As asked downthread, have you given any thought into whether a Decimal type would support this operation?<br></div></div></div></div></blockquote><div> </div></div><div>The same concerns apply to decimal.  It makes sense to have the operation (for both binary and decimal floating-point) as “Type.remainder(a,b)” or a free function like &quot;remainder(a, b)”, but I would prefer not to use the operator “%” for it because it behaves very differently from integer %, and in ways that are not at all obvious to most users.<br></div></div></div></blockquote><div> </div></div><div>Great, I’d prefer decimal and the float types to have a consistent interface where possible.  +1 from me on the proposal.<br></div></blockquote><div> </div><div>Agreed. +1 from me too. The `10.0 % 0.1` behavior is sufficiently surprising that I think that justifies removal by itself.<br></div><div> </div><div>I&#39;m also in favor of adding mod and remainder as instance methods of the floating point types, e.g. `10.0.mod(0.1)` (as opposed to static methods or free functions).<br></div></div></div></blockquote>Shouldn’t that be added to any Arithmetic type?<br></div></div></blockquote><div><br></div></span>We don&#39;t offer protocols that abstract over both integer and float arithmetic. They behave differently, and require different algorithms and interfaces. Floating-point types gaining a `mod` member does not necessarily mean integer types should get the same.</div><div><br></div><div>-Joe<br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uQFKl6aWB0uo7-2F8NFAb-2FCKKagd5iBYeIW8W0NTTsT7sGtChiYyyvZ9TFMYMc1kY0HZUQ4rk7pgPuQZ-2BPBTo7rW-2BtvhHhaQe2uHUBHtwiMVRfc29f-2FWRfUS71QRY19NHeTWPX27HW3vyBdaYUfICS7Jm3S5iPOFNt49m1rV98JD8D-2BEngycR4QRsyhTKrZ7JYF8-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div></div></div>