Code that uses % is often surprisingly buggy. For example even a simple function such as this is broken if n is negative:
function isOdd(n) { return n % 2 === 1; } isOdd(-3) // false The same is not true in other programming languages. The same in Python works just fine: def isOdd(n): return n % 2 == 1 isOdd(-3) // true The advantage of an operator over a function is that it allows us to say to people who are new to JS: "Always use %% instead of % unless you have a good reason". Just the same as we say "Always use === instead of == unless you have a good reason". On Thu, Aug 15, 2019 at 10:01 PM Isiah Meadows <isiahmead...@gmail.com> wrote: > BTW, I just wrote up a more precise, formalized proposal over here: > https://github.com/isiahmeadows/proposal-divisor-dependent-modulo/, > 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 > it. > > 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 https://en.wikipedia.org/wiki/Modulo_operation, > 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 > examples: > > - 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: > > - APL > - LibreOffice/Excel > - Lua > - Perl > - Mathematica > - PL/I > - TCL > > 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 > cont...@isiahmeadows.com > www.isiahmeadows.com > > On Thu, Aug 15, 2019 at 3:58 PM Jordan Harband <ljh...@gmail.com> 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.giammar...@gmail.com> 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 <t...@thenewobjective.com> > 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] https://developers.google.com/web/updates/2018/03/smooshgate > >>> > >>> [2] > https://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/ > >>> > >>> > >>> > >>> Michael > >> > >> _______________________________________________ > >> es-discuss mailing list > >> es-discuss@mozilla.org > >> https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss