Brendan Eich wrote:
Kevin Smith wrote:
I think hacking around this would not get rid of the footgun, but
would just make it more complicated to understand the footgun,
personally.
My gut reaction is to agree - the current rule, while it takes some
trivial learning, is easy to understand and communicate and is
reflected well in other parts of the language. Also, additions to
object literal syntax might make this more...weird:
x => { [abc](def = function() { huh() }) { blahblahblah } };
"But it's an object literal, obviously!"
Yes, there's always a trade-off, some futures are foreclosed by syntax
changes of this sort.
To say a bit more, your example *as written above* unambiguously shows
an object literal body, not a block expression body. It's complex, but
there's no valid parse that would interpret the stuff after => as a
block. But let's tweak it a bit:
x => { [abc](def = function() { huh() })
{ blahblahblah } };
Now ASI applies and this parses as a block or an object literal. The
arrow body is ctually valid ES1!
The future-hostility of
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
must be traded off against the complexity burden of every-more elaborate
object literal extension syntax. At some point we can stop extending
object literals. Are we there yet?
If so, then the {x, y} shorthand problem Frankie raised remains. One
brute-force way out is to ban leading comma expression statements in
UnlabeledStatement: ExpressionStatement, which could be done. I'm still
thinking about this, not super-worried.
Given ES6 arrows as drafted and implemented, and as about to be
finalized, the main problem that I foresee with adding
block_vs_object_literal in ES7 is how () = {} makes an empty-block body.
That's why I asked
"How often do you really want an empty object instead of a block with no
statements?"
a few messages back. Serious question!
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
