<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>
<div style="font-family:Calibri,sans-serif; font-size:11pt">For better or worse, C# avoids this ambiguity through the use of the `new` operator:<br>
<br>
```<br>
f = x => y => new { x, y };<br>
```<br>
<br>
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.<br>
<br>
Ron<br>
<br>
Sent from my Windows Phone</div>
</div>
<div dir="ltr">
<hr>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">From:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:brendan@mozilla.org">Brendan Eich</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Sent:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt">1/5/2015 1:01 PM</span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">To:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:caitpotter88@gmail.com">Caitlin Potter</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Cc:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:es-discuss@mozilla.org">es-discuss</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Subject:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt">Re: (x) => {foo: bar}</span><br>
<br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Caitlin Potter wrote:<br>
> > You mean replace the footgun with a smaller one, maybe one so small <br>
> it doesn't matter. Saying that the proposal doesn't get rid of the <br>
> footgun means it still remains impossible to write x => {p: x} and not <br>
> get what Frankie and others want: an arrow returning an object. But <br>
> the proposal does fix that footgun.<br>
> ><br>
> > How often do you really want an empty object instead of a block with <br>
> no statements?<br>
><br>
> Okay, good point about the (lack of) ambiguity in terms of how <br>
> it's interpreted, but what I'm talking about is how it looks like it <br>
> should work. It looks like a function body and an object literal, and <br>
> it doesn't matter which one is used more frequently, because it's <br>
> going to bite people one way or the other.<br>
<br>
True. Can't share { as I did in JS and avoid this. Ship sailed long ago.<br>
<br>
> Rules about what sorts of statements are allowed as the first <br>
> statement in a block is also going to bite people some times.<br>
<br>
Probably not useless labels at the front. Seriously, the change to allow <br>
labels only at top level or else in front of any label-using statement <br>
(and no other) is almost perfectly backward compatible. Stray and unused <br>
labels are latent bugs, even if just minor left-over or misplace noise.<br>
<br>
> Because it bites fewer people, there will be fewer people who have <br>
> dealt with it and are able to explain it, so it becomes one of those <br>
> "gotchas" of the language.<br>
<br>
Yes, a smaller footgun -- not the same one that started this thread. I <br>
agree it's vexing to have a footgun left, but if it differs in quality <br>
and frequency of misfires, maybe it's worthwhile. Hard to assess.<br>
<br>
I also agree KISS favors what we all agreed to do, which was (a) take <br>
arrows into ES6; (b) not pursue block_vs_object_literal after I wrote it <br>
up. But we could revisit (b) and that seems worth some es-discuss overhead.<br>
<br>
> This is my personal opinion, but I think the "wrap object literals in <br>
> parentheses for concise bodies" is much simpler to explain to people <br>
> than more complicated rules. Simple is good :><br>
<br>
Your advice is good as far as it goes; it seems not to reach enough <br>
people to avoid a real-world speedbump, from the root message in this <br>
thread.<br>
<br>
If the speedbump were caught at compile-time, no big. That it results in <br>
runtime behavior differing from the DWIM intent of the programmer means <br>
latent bugs. Perhaps JSLint, ESHint, etc., will be updated to catch the <br>
bad thing in the field, and that will suffice.<br>
<br>
/be<br>
_______________________________________________<br>
es-discuss mailing list<br>
es-discuss@mozilla.org<br>
<a href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div>
</span></font>
</body>
</html>