We should not be designing standard library interfaces around what's fastest to do in hardware. This is what C did (if we read "in hardware" as "on a Digital PDP" for some older features and possibly "on x86" for some more recent things), and we're all worse off for it.
We should ensure that it is possible to take advantage of hardware fast paths where appropriate, and that we have a sound rationale when we diverge from common practice, but the design goal for the standard library cannot be "map as closely as possible to the x86 or arm ISA"; assembly language will always be better at that.
Replacing %
is a non-starter for me because:
-
%
is not a modulo operator. It is a remainder operator, directly tied to/
. We're not going to change the behavior of/
, so we won't change%
either. - The current behavior of
%
matches the overwhelming majority of programming languages. Changing it to do something else would completely violate the principle of least surprise, and there's no argument in favor of changing it that clears the necessary bar.
Adding a .mod
or .modulo
together with more general divide and remainder operations with rounding control is a complete no-brainer to me. Of course we should do that, and I'm planning to write an actual proposal in the next few days, which I will post here for feedback and contributions from anyone who feels like helping.