`-x ** y` is absolutely a SyntaxError because of the disagreement between many programming languages which treat that as `(-x) ** y` and math itself which treats it as `-(x ** y)`.
To resolve the debate about "what will users expect", this early syntax error ensures that programmers get the joy of being required to be explicit about their precedence, saving countless amounts of time and money spent on linting rules and style arguments. On Wed, Jul 20, 2016 at 12:48 PM, Bradford Smith <bradfordcsm...@google.com> wrote: > Can anyone explain the reasoning behind the strange "leapfrogging" > behavior of the ExponentiationExpression > <https://tc39.github.io/ecma262/#prod-ExponentiationExpression> and > UpdateExpression <https://tc39.github.io/ecma262/#prod-UpdateExpression> > productions > in the current spec? > > Simplified relevant productions in operator precedence order are: > > ExponentiationExpression : > UnaryExpression > UpdateExpression ** ExponentiationExpression > > UnaryExpression : > UpdateExpression > { delete | void | typeof | + | - | ~ | ! } UnaryExpression > > UpdateExpression: > { ++ | -- } UnaryExpression > LeftHandSideExpression { ++ | -- } > > Things that seem weird about this are: > 1. '-x ** y' is a syntax error, because UnaryExpression isn't allowed > before ** > You must write it as '(-x) ** y' > I would expect the production right hand side to be > UnaryExpression ** ExponentiationExpression > That avoids this strange syntax error and is consistent with the > pattern followed by productions for lower-precedence operators. > > 2. Having UnaryExpression in the right hand side of UpdateExpression > confuses precedence by going 'backward' to a lower-precedence non-terminal, > and the only production of UnaryExpression that generates a valid > argument for '++'/'--' is UnaryExpression => UpdateExpression => > LeftHandSideExpression anyway. > > I've just finished implementing these rules in the closure-compiler, where > I had to implement logic to deal with this strange behavior. Is it at all > possible that these are simply typos in the spec? > > Thanks, > Bradford > > _______________________________________________ > 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
