[swift-evolution] Proposal: Remove % operator for floating-point types

[Andrew Bennett]

First of all great proposal, and thank you for trying to make it easier to
write safe code with Swift.

I feel like this proposal is more about human error than floating point
error.

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.

Regarding binding % to remainder, I think this is way too unexpected (a
much bigger gotcha):

3.0 % 4.0 == -1.0
3 % 4 == 3

I don't think we should change the binding to remainder.

If X.remainder(Y) is added to FloatingPointType I'm fairly neutral about
the proposal to remove % on floating point types.

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.

The deprecation warning could be something like this:

Deprecated due to precision issues, renamed to 'fmod', consider rewriting
to use 'remainder' instead.

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.

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.

On Sat, Dec 19, 2015 at 12:10 PM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Dec 18, 2015, at 3:40 PM, August Joki via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> -August
>
> On 18 Dec, 2015, at 15:31, Kevin Ballard via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Fri, Dec 18, 2015, at 03:04 PM, Chris Lattner via swift-evolution wrote:
>
>
>
> On Dec 18, 2015, at 3:03 PM, Stephen Canon <scanon at apple.com> wrote:
>
>
>
> On Dec 18, 2015, at 5:57 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi everybody —
>
> I’d like to propose removing the “%” operator for floating-point types.
>
>
> 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?
>
>
> 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.
>
>
> Great, I’d prefer decimal and the float types to have a consistent
> interface where possible.  +1 from me on the proposal.
>
>
> Agreed. +1 from me too. The `10.0 % 0.1` behavior is sufficiently
> surprising that I think that justifies removal by itself.
>
> 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).
>
> Shouldn’t that be added to any Arithmetic type?
>
>
> 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.
>
> -Joe
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151219/f75bf6ba/attachment.html>