(x) => {foo: bar}

[Brendan Eich]

Caitlin Potter wrote:
> > You mean replace the footgun with a smaller one, maybe one so small 
> it doesn't matter. Saying that the proposal doesn't get rid of the 
> footgun means it still remains impossible to write x => {p: x} and not 
> get what Frankie and others want: an arrow returning an object. But 
> the proposal does fix that footgun.
> >
> > How often do you really want an empty object instead of a block with 
> no statements?
>
> Okay, good point about the (lack of) ambiguity in terms of how 
> it's interpreted, but what I'm talking about is how it looks like it 
> should work. It looks like a function body and an object literal, and 
> it doesn't matter which one is used more frequently, because it's 
> going to bite people one way or the other.

True. Can't share { as I did in JS and avoid this. Ship sailed long ago.

> Rules about what sorts of statements are allowed as the first 
> statement in a block is also going to bite people some times.

Probably not useless labels at the front. Seriously, the change to allow 
labels only at top level or else in front of any label-using statement 
(and no other) is almost perfectly backward compatible. Stray and unused 
labels are latent bugs, even if just minor left-over or misplace noise.

> Because it bites fewer people, there will be fewer people who have 
> dealt with it and are able to explain it, so it becomes one of those 
> "gotchas" of the language.

Yes, a smaller footgun -- not the same one that started this thread. I 
agree it's vexing to have a footgun left, but if it differs in quality 
and frequency of misfires, maybe it's worthwhile. Hard to assess.

I also agree KISS favors what we all agreed to do, which was (a) take 
arrows into ES6; (b) not pursue block_vs_object_literal after I wrote it 
up. But we could revisit (b) and that seems worth some es-discuss overhead.

> This is my personal opinion, but I think the "wrap object literals in 
> parentheses for concise bodies" is much simpler to explain to people 
> than more complicated rules. Simple is good :>

Your advice is good as far as it goes; it seems not to reach enough 
people to avoid a real-world speedbump, from the root message in this 
thread.

If the speedbump were caught at compile-time, no big. That it results in 
runtime behavior differing from the DWIM intent of the programmer means 
latent bugs. Perhaps JSLint, ESHint, etc., will be updated to catch the 
bad thing in the field, and that will suffice.

/be