Exponentiation operator precedence

[Brendan Eich]

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!

/be

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:
>
> https://zyan.scripts.mit.edu/blog/backdooring-js/
>
> 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
> https://mail.mozilla.org/listinfo/es-discuss
>