I agree with that completely.
This would also become a gotcha. I can see a lot of people down the road
thinking -x ** 2 === -x**2, only to find that's not the case. It looks like
it should, which will quickly lead to hard to find bugs. I think it's a
terrible idea, but that's just my opinion.
On Fri, Aug 28, 2015, 00:56 Brendan Eich bren...@mozilla.org wrote:
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 Jonesa...@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@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
