Modulo Operator %%

Isiah Meadows isiahmeadows at
Thu Aug 15 21:01:24 UTC 2019

BTW, I just wrote up a more precise, formalized proposal over here:,
and I'd be more than willing to work with a TC39 champion on it. I
personally prefer syntax (pretty strongly), but I'm not beholden to

I do feel the semantics are simple enough it'd be okay to lower it to
syntax, and it naturally just glides right in. I find it *very* odd
that some languages use a simple operator `%` or relatively short
function for remainder keeping the sign of the dividend but relegate
the version keeping the sign of the divisor (the more useful and
intuitive of them) to a much more verbose function call. Of all
Wikipedia lists in,
here's the four that do this currently - all but one expose an
operator for the first:

- Fortran: `mod` for dividend-dependent, `modulo` for divisor-dependent
- Julia: `%`/`rem` for dividend-dependent, `mod` for divisor-dependent
- Java: `%` for dividend-dependent, `Math.floorMod` for divisor-dependent
- XBase++: `%` for dividend-dependent, `Mod` for divisor-dependent

And it's worth noting most other languages (including some end
user-oriented ones) that show a syntactic preference to one or the
other expose a simpler one where the sign matches the divisor, a more
complicated one where the sign matches the dividend. For a variety of

- Ruby: `%`/`modulo` for divisor-dependent, `remainder` for dividend-dependent
- SML: `mod` for divisor-dependent, `Int.rem` for dividend-dependent
- Elm: `modBy` for divisor-dependent, `remainderBy` for dividend-dependent
- Euphoria: `mod` for divisor-dependent, `remainder` for dividend-dependent
- Python: `%` for divisor-dependent, `math.fmod` for dividend-dependent
- Smalltalk: `\\` for divisor-dependent, `rem:` for dividend-dependent

And of course, many don't even expose a type of modulo where the sign
matches the divisor. For some examples:

- LibreOffice/Excel
- Lua
- Perl
- Mathematica
- PL/I

There's also Dart, a relatively new language which defaults to
non-negative always.

This relatively long list of languages, *despite* C's heritage and
semantics being inherited in much of them, makes me question using a
function for this, and there would need to be a *lot* of FUD to get
people to use the function more than the operator.

So this is why I would prefer an operator as opposed to syntax for this.


Isiah Meadows
contact at

On Thu, Aug 15, 2019 at 3:58 PM Jordan Harband <ljharb at> wrote:
> Static functions don't have the same risk as prototype functions; `Math.mod` would make sense to add.
> One suggestion, though, would be to try to add the API method first, and look at usage for awhile before trying to add the syntax.
> On Thu, Aug 15, 2019 at 10:12 AM Andrea Giammarchi <andrea.giammarchi at> wrote:
>> To me there's no risk, as MooTools, Prototype, and Scriptacolous are both things of the past, and never implemented Math.mod ... so, with that approach, custom transpiling functions are more dangerous, as somebody might have implemented `%%` already for other purposes, and we break Babel outcome adding new syntax anyway ... the smoosh accident, is the equivalent of custom Babel utilities these days.
>> Look at TypeScript and the private class fields, if you want to compare new syntax instead
>> On Thu, Aug 15, 2019 at 4:50 PM Michael Haufe <tno at> wrote:
>>> Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote:
>>> > FWIW another disadvantage is that operators cannot be polyfilled, so it'll take forever for those not using transpilers to adopt these, while having a `Math,mod` would work right away
>>> With such an approach there is risk of another ‘smooshgate’ [1][2]. There is nothing stopping those developers from using a function anyway to bridge the gap if they can’t or won’t use a compiler. This is already the current state of affairs.
>>> [1]
>>> [2]
>>> Michael
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list