Exponentiation operator precedence
brendan at mozilla.org
Fri Aug 28 04:56:02 UTC 2015
Not to worry, the significant whitespace prospect was (I trust) a
warding-off spell. Good of Waldemar to mention Fortress, too.
JS, which as source is and will always be minified, indeed requires
full-parsing minifiers, so one might naively still entertain the stated
prospect. But it's a bad idea, since people minify (or just tidy by
removing spaces) by hand. Keep warding off significant space!
Joe Gibbs Politz wrote:
> On Thu, Aug 27, 2015 at 2:58 PM, Alexander Jones<alex at weej.com> wrote:
>> Ethan is making my point far better than I did, and I agree completely about
>> the issue of unary operators visually appearing more tightly bound than
>> binary operators.
>> At this point it seems fair to at least acknowledge the prospect of
>> significant whitespace.
>> -x**2 === -(x ** 2)
>> -x ** 2 === (-x) ** 2
> One kind of cost that I haven't seen mentioned (and is relevant
> re:whitespace) is the impact on minifiers and other tools that use JS
> as output, which have to deal with operator precedence/whitespace
> rules in quite complicated ways. There's a nice recent piece about
> precedence bugs in a minifier:
> Making the creation and maintenance of systems like minifiers harder
> is a real cost worth bearing in mind when updating already-subtle
> existing rules.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss