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
