(x) => {foo: bar}

[Brendan Eich]

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