<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't think this solves the precision issue. It makes it harder to use fmod, but doesn't stop people wanting to, life finds a way. I completely agree with your rationale, but if someone wants mod they'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'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'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'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 'fmod', consider rewriting to use 'remainder' 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'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's probably an overlap with clang'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"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> 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 <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> 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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 "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'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'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>