For better or worse, C# avoids this ambiguity through the use of the `new`
operator:
```
f = x => y => new { x, y };
```
Of course, C# does not support creating an object literal (nee. "anonymous
type") without `new`, but using `new` here would be generally unambiguous in
ES7+. Although its legal to write `new {}` in ES today, it currently results in
a runtime exception.
Ron
Sent from my Windows Phone
________________________________
From: Brendan Eich<mailto:bren...@mozilla.org>
Sent: 1/5/2015 1:01 PM
To: Caitlin Potter<mailto:caitpotte...@gmail.com>
Cc: es-discuss<mailto:es-discuss@mozilla.org>
Subject: Re: (x) => {foo: bar}
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
_______________________________________________
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
