(x) => {foo: bar}

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Jasper St. Pierre
Unless

    x => {foo: bar}

and

    x => {}

both parse as object literals, I'm against your proposal. Either un-paren'd braces are consistently a block, or they're consistently an object literal. Python has had major pains with "i before e except after c" rules to make the language nicer to use, and it's easier to tell people "always add the parens".

A third option is to make x => {foo: bar} a syntax error to steer people away from an accidental footgun, while still making {} a block, and keeping the consistency of "parens around object literals".

On Mon, Jan 5, 2015 at 1:40 PM, Brendan Eich <[hidden email]> wrote:
Mark Volkmann wrote:
My apologies. I meant to say that Traceur doesn't support returning a literal object from an arrow function with syntax like this:

let f = x => ({foo: bar});

However, I just tested it again and it works fine. I could swear this didn't work a few months ago. Maybe it was fixed recently. I'm happy!

Cool -- you are supporting Caitlin's thesis that we can pedagogue around the footgun. I hope so.

Still leaves http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal as an option for ES7. Comments welcome.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
  Jasper

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Brendan Eich-2
Jasper St. Pierre wrote:

> Unless
>
>     x => {foo: bar}
>
> and
>
>     x => {}
>
> both parse as object literals, I'm against your proposal. Either
> un-paren'd braces are consistently a block, or they're consistently an
> object literal. Python has had major pains with "i before e except
> after c" rules to make the language nicer to use, and it's easier to
> tell people "always add the parens".

Fair.

> A third option is to make x => {foo: bar} a syntax error to steer
> people away from an accidental footgun, while still making {} a block,
> and keeping the consistency of "parens around object literals".

Just about too late for ES6, though. Eep!

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: (x) => {foo: bar}

Gary Guo
Strongly negative against the proposal. I believe that charisma of a language comes from its simplicity. The proposal seems to add too many syntax rules to ES.

btw it is not easy to implement such a syntax into practice. I'm afraid there will be more syntax refinement, which actually make the parser to scan source code twice (or adjust the AST afterward, but currently traceur reparse the code when refine the destructuring assignment). I don't feel it worthwhile.

Though I am strongly negative, but there actually is such an implementation. The REPL of node will parse {a:1} as object literal while {a:1;} as block.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Alex Kocharin
 
06.01.2015, 06:38, "Gary Guo" <[hidden email]>:
 
Though I am strongly negative, but there actually is such an implementation. The REPL of node will parse {a:1} as object literal while {a:1;} as block.
 
Node.js REPL wraps all the statements in parentheses. Therefore `{a:1;}` becomes `({a:1;})` which is a syntax error.
 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: (x) => {foo: bar}

Ron Buckton-2
In reply to this post by Brendan Eich-2
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: [hidden email]
Sent: ‎1/‎5/‎2015 1:01 PM
To: [hidden email]
Cc: [hidden email]
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Isiah Meadows
In reply to this post by Frankie Bagnardi
Once again...forgot to change the subject. (I get the digest...can't
you tell?) *sigh*

On Mon, Jan 5, 2015 at 11:48 PM, Isiah Meadows <[hidden email]> wrote:

>> From: Marius Gundersen <[hidden email]>
>> To: Kevin Smith <[hidden email]>, es-discuss <[hidden email]>
>> Cc:
>> Date: Mon, 5 Jan 2015 21:58:54 +0100
>> Subject: Re: (x) => {foo: bar}
>>
>> One scenario where arrow functions are likely to return objects is in the map function of arrays and the pipe function for streams. For example:
>>
>> [1,2,3]
>> .map(x => {value: x,  double:2*x})
>> .filter(x => x.double < 5)
>
> I guess, get ready to practice your Lispy parentheses-balancing skills? ;)
>
> ```js
> [1,2,3]
> .map(x => ({value: x,  double:2*x}))
> .filter(x => x.double < 5)
> ```
>
> ```clojurescript
> (filter
>     #(< (get % :double) 5)
>     (map (fn [x] {:value :x, :double :(* 2 x)})) [1, 2, 3])
> ```
>
> In all reality, it's easier to tell people to simply put parentheses
> around an object literal than to tell people to avoid very specific
> nits. The one ambiguity that would cause the most problems in parsing
> would be the property shorthand syntax: `{foo}`. This is technically
> both a valid block and object, so, given the right circumstances, that
> could rub against the halting problem, and would theoretically require
> up to the entire object to decide whether it is an object or block.
> So, something like this would require up to the function call to see
> it's an object and not a block (and not exactly obvious), and the
> result is never seen until runtime:
>
> ```js
> x => {x, y, z, f() {}}
> ```
>
> I'm skeptical on whether this will work on the implementation side.
>
>>
>> Marius Gundersen
>>
>> On 5 Jan 2015 21:16, "Kevin Smith" <[hidden email]> wrote:
>>>
>>> Also, I did some analysis on this issue way back when.  In the codebases that I looked at the percentage of "bound this functions" which simply returned an object literal were quite low.
>>>
>>> (See the "%Object Literals" column)
>>>
>>> https://docs.google.com/spreadsheet/ccc?key=0Aro5yQ2fa01xdENxUzBuNXczb21vUWVUX0tyVmNKTUE#gid=0
>>> https://docs.google.com/spreadsheet/ccc?key=0Aro5yQ2fa01xdEJySWxhZ1VoZ0VaWTdldXp4NUtJd3c#gid=0
>>>
>>> (from https://esdiscuss.org/topic/btf-measurements)
>>>
>>> Of course, actually having arrow functions will change the situation to some degree, but the current tradeoff made sense in light of that evidence.
>>>
>>>
>>> On Mon, Jan 5, 2015 at 3:06 PM, Brendan Eich <[hidden email]> 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.
>>>>
>>>> Is it worth it? Hard to say, crystal ball service not answering the phone ;-). Still, the motivation for that strawman I wrote in 2011 lives on.
>>>>
>>>> /be
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>
> --
> Isiah Meadows



--
Isiah Meadows
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Isiah Meadows
In reply to this post by Frankie Bagnardi
> From: Alex Kocharin <[hidden email]>
> To: Gary Guo <[hidden email]>, "[hidden email]" <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>
> Date: Tue, 06 Jan 2015 06:59:52 +0300
> Subject: Re: (x) => {foo: bar}
>
> 06.01.2015, 06:38, "Gary Guo" <[hidden email]>:
>
>
> Though I am strongly negative, but there actually is such an implementation. The REPL of node will parse {a:1} as object literal while {a:1;} as block.
>
>
> Node.js REPL wraps all the statements in parentheses. Therefore `{a:1;}` becomes `({a:1;})` which is a syntax error.
>

Not in my REPL (node 0.10.33).

```
$ node
> {a:1;}
1
> {a:1}
{ a: 1 }
```

What the Node.js REPL effectively appears to do, AFAICT, is some sort
of evented try-catch. Though, @Gary, I agree 100% with what you said
about being very against it. It would require a lot more context to
figure out if something returns an object, as `{a, b, c}` is
technically both a valid block and object (using shorthand
properties). The problems would then become non-obvious and difficult
to diagnose in practice.

--
Isiah Meadows
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: (x) => {foo: bar}

Gary Guo
In reply to this post by Alex Kocharin
Nope. {a:1;} will work in REPL of Node.js. In source code of repl.js, it will wrap input with parentheses first, and if there is a syntax error, it then evaluate the code without parentheses. You can test {a:1} and {a:1;}, both of them works; the former one returns {a:1} while the latter one returns 1.


From: [hidden email]
To: [hidden email]; [hidden email]
CC: [hidden email]
Subject: Re: (x) => {foo: bar}
Date: Tue, 6 Jan 2015 06:59:52 +0300

 
06.01.2015, 06:38, "Gary Guo" <[hidden email]>:
 
Though I am strongly negative, but there actually is such an implementation. The REPL of node will parse {a:1} as object literal while {a:1;} as block.
 
Node.js REPL wraps all the statements in parentheses. Therefore `{a:1;}` becomes `({a:1;})` which is a syntax error.
 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Dean Landolt
In reply to this post by Brendan Eich-2
On Mon, Jan 5, 2015 at 6:06 PM, Brendan Eich <[hidden email]> wrote:
Jasper St. Pierre wrote:
Unless

    x => {foo: bar}

and

    x => {}

both parse as object literals, I'm against your proposal. Either un-paren'd braces are consistently a block, or they're consistently an object literal. Python has had major pains with "i before e except after c" rules to make the language nicer to use, and it's easier to tell people "always add the parens".

Fair.

A third option is to make x => {foo: bar} a syntax error to steer people away from an accidental footgun, while still making {} a block, and keeping the consistency of "parens around object literals".

Just about too late for ES6, though. Eep!

Is it though? ISTM there's consensus that this is a footgun -- isn't that a kind of spec bug? If it's too late to properly vet a change which narrowly excludes from arrow bodies any `LabeledStatement` that isn't a `WellLabeledStatement`, would it be feasible to simply exclude any `LabeledStatement` for now? I doubt there's much code in the wild that would be affected by this change -- certainly not yet. That'd buy plenty of time to add back proper support for `WellLabeledStatement` arrow bodies in es7.

Implicitly returning object literals would still require paren wrapping, of course -- and in light of the empty object / empty block ambiguity this seems inevitable. And we'll get a fail-fast compile error for the common case (non-empty objects) to would help educate and remind us all of the distinction.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Rick Waldron
In reply to this post by Isiah Meadows


On Tue Jan 06 2015 at 2:18:47 AM Isiah Meadows <[hidden email]> wrote:
> From: Alex Kocharin <[hidden email]>
> To: Gary Guo <[hidden email]>, "[hidden email]" <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>
> Date: Tue, 06 Jan 2015 06:59:52 +0300
> Subject: Re: (x) => {foo: bar}
>
> 06.01.2015, 06:38, "Gary Guo" <[hidden email]>:
>
>
> Though I am strongly negative, but there actually is such an implementation. The REPL of node will parse {a:1} as object literal while {a:1;} as block.
>
>
> Node.js REPL wraps all the statements in parentheses. Therefore `{a:1;}` becomes `({a:1;})` which is a syntax error.
>

Not in my REPL (node 0.10.33).

```
$ node
> {a:1;}
1
> {a:1}
{ a: 1 }
```

What the Node.js REPL effectively appears to do, AFAICT, is some sort
of evented try-catch.

No, that's not what it does. Alex was close, but not exactly right. The REPL will test input and wrap if necessary: https://github.com/joyent/node/blob/master/lib/repl.js#L266-L271

Rick

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Brendan Eich-2
In reply to this post by Dean Landolt
Dean Landolt wrote:
> ISTM there's consensus that this is a footgun -- isn't that a kind of
> spec bug?

No, it's a trade-off, and recent comments in this thread argue against
complicating the grammar and real-world parsers, and in favor of
teaching people to parenthesize. Nowhere near consensus on what to do
about the trade-off. Lots of footguns, more than feet, out there in
design space.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Brendan Eich-2
In reply to this post by Dean Landolt
Sorry, sent too soon.

Dean Landolt wrote:
> If it's too late to properly vet a change which narrowly excludes from
> arrow bodies any `LabeledStatement` that isn't a
> `WellLabeledStatement`, would it be feasible to simply exclude any
> `LabeledStatement` for now? I doubt there's much code in the wild that
> would be affected by this change -- certainly not yet. That'd buy
> plenty of time to add back proper support for `WellLabeledStatement`
> arrow bodies in es7.

The ES6 grammar has not been refactored per my old strawman. It has no
WellLabeledStatement non-terminal.

For ES6, we would need another production parameter to FunctionBody,
FunctionStatementList, and StatementList (at least) by which to restrict
a ConciseBody : { FunctionBody } such that the FunctionBody :
FunctionStatementList (via FunctionStatementList : StatementList[opt],
StatementList StatementListItem, etc.) doesn't start with a
LabelledStatement.

Cc'ing Allen and Waldemar for their thoughts.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Marius Gundersen

I don't see how wellLabeledStatement will protect against object literals with shorthand properties, like (x, y, z) => {x, y, z}.

The solution to the block vs object problem today is to wrap the object in parenthesis, but not the block. The only alternative that is easy for humans to understand and not ambiguous for machines is to wrap or prefix the block, but not the object, for example with do:

x => do {
  let a = 5;
  return a*x;
}

AFAIK do expressions are not in ES6, but might be in ES7.

Marius Gundersen

On 6 Jan 2015 19:42, "Brendan Eich" <[hidden email]> wrote:
Sorry, sent too soon.

Dean Landolt wrote:
If it's too late to properly vet a change which narrowly excludes from arrow bodies any `LabeledStatement` that isn't a `WellLabeledStatement`, would it be feasible to simply exclude any `LabeledStatement` for now? I doubt there's much code in the wild that would be affected by this change -- certainly not yet. That'd buy plenty of time to add back proper support for `WellLabeledStatement` arrow bodies in es7.

The ES6 grammar has not been refactored per my old strawman. It has no WellLabeledStatement non-terminal.

For ES6, we would need another production parameter to FunctionBody, FunctionStatementList, and StatementList (at least) by which to restrict a ConciseBody : { FunctionBody } such that the FunctionBody : FunctionStatementList (via FunctionStatementList : StatementList[opt], StatementList StatementListItem, etc.) doesn't start with a LabelledStatement.

Cc'ing Allen and Waldemar for their thoughts.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Isiah Meadows
In reply to this post by Rick Waldron

Okay: is this a valid statement/expression? I didn't think so, but I may be wrong.

```js
({ foo(); bar(); })
```

On Jan 6, 2015 11:16 AM, "Rick Waldron" <[hidden email]> wrote:


On Tue Jan 06 2015 at 2:18:47 AM Isiah Meadows <[hidden email]> wrote:
> From: Alex Kocharin <[hidden email]>
> To: Gary Guo <[hidden email]>, "[hidden email]" <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>
> Date: Tue, 06 Jan 2015 06:59:52 +0300
> Subject: Re: (x) => {foo: bar}
>
> 06.01.2015, 06:38, "Gary Guo" <[hidden email]>:
>
>
> Though I am strongly negative, but there actually is such an implementation. The REPL of node will parse {a:1} as object literal while {a:1;} as block.
>
>
> Node.js REPL wraps all the statements in parentheses. Therefore `{a:1;}` becomes `({a:1;})` which is a syntax error.
>

Not in my REPL (node 0.10.33).

```
$ node
> {a:1;}
1
> {a:1}
{ a: 1 }
```

What the Node.js REPL effectively appears to do, AFAICT, is some sort
of evented try-catch.

No, that's not what it does. Alex was close, but not exactly right. The REPL will test input and wrap if necessary: https://github.com/joyent/node/blob/master/lib/repl.js#L266-L271

Rick

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Brendan Eich-2
In reply to this post by Marius Gundersen
Marius Gundersen wrote:

>
> I don't see how wellLabeledStatement will protect against object
> literals with shorthand properties, like (x, y, z) => {x, y, z}.
>
> The solution to the block vs object problem today is to wrap the
> object in parenthesis, but not the block. The only alternative that is
> easy for humans to understand and not ambiguous for machines is to
> wrap or prefix the block, but not the object, for example with do:
>
> x => do {
>   let a = 5;
>   return a*x;
> }
>
> AFAIK do expressions are not in ES6, but might be in ES7.
>

do-expressions are in good shape for ES7, stage 2 or better IIRC. I
can't find a record of this at the moment, but perhaps arossberg has a link.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: {Spam?} Re: (x) => {foo: bar}

Brendan Eich-2
In reply to this post by Isiah Meadows
Isiah Meadows wrote:
>
> Okay: is this a valid statement/expression? I didn't think so, but I
> may be wrong.
>
> ```js
> ({ foo(); bar(); })
> ```
>

It's a syntax error, in any JS repl or standard.

The Node repl only removes parens if it tries adding them first around
braced input and that fails.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Dean Landolt
In reply to this post by Marius Gundersen


On Tue, Jan 6, 2015 at 3:57 PM, Marius Gundersen <[hidden email]> wrote:

I don't see how wellLabeledStatement will protect against object literals with shorthand properties, like (x, y, z) => {x, y, z}.


It would "protect" against them by disallowing them without the paren wrapping. A fail-fast SyntaxError beats the hell out of trying to diagnose an almost imperceptible runtime bug.
 

The solution to the block vs object problem today is to wrap the object in parenthesis, but not the block. The only alternative that is easy for humans to understand and not ambiguous for machines is to wrap or prefix the block, but not the object, for example with do:

x => do {
  let a = 5;
  return a*x;
}

AFAIK do expressions are not in ES6, but might be in ES7.


I don't follow -- this isn't a labeled statement. How would it be any different from this?

x => {
  let a = 5;
  return a*x;
}


AFAIK nobody's proposed forbidding this form. How would do-expressions help here? Sure, IIUC do-expressions would be a good solution for labeled blocks, when they're available. But by es7 there's also plenty of time to refactor the spec to allow some variant of /be's proposed `WellLabeledStatement` grammar, which would allow well-formed labeled statements w/o the do prefix.

Just to reiterate, I'm arguing that paren-wrapping should still be required around object literal arrow bodies, now and forever. Anything else would be impossibly confusing. But I can't see a reason to allow an (accidentally) unwrapped object literal to parse. If it's not a "well-labeled statement", it's surely a mistake.

Marius Gundersen

On 6 Jan 2015 19:42, "Brendan Eich" <[hidden email]> wrote:
Sorry, sent too soon.

Dean Landolt wrote:
If it's too late to properly vet a change which narrowly excludes from arrow bodies any `LabeledStatement` that isn't a `WellLabeledStatement`, would it be feasible to simply exclude any `LabeledStatement` for now? I doubt there's much code in the wild that would be affected by this change -- certainly not yet. That'd buy plenty of time to add back proper support for `WellLabeledStatement` arrow bodies in es7.

The ES6 grammar has not been refactored per my old strawman. It has no WellLabeledStatement non-terminal.

For ES6, we would need another production parameter to FunctionBody, FunctionStatementList, and StatementList (at least) by which to restrict a ConciseBody : { FunctionBody } such that the FunctionBody : FunctionStatementList (via FunctionStatementList : StatementList[opt], StatementList StatementListItem, etc.) doesn't start with a LabelledStatement.

Cc'ing Allen and Waldemar for their thoughts.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: {Spam?} Re: (x) => {foo: bar}

Isiah Meadows
In reply to this post by Brendan Eich-2

That's what I thought. Didn't think I had gone crazy there.

On Jan 6, 2015 5:45 PM, "Brendan Eich" <[hidden email]> wrote:
Isiah Meadows wrote:

Okay: is this a valid statement/expression? I didn't think so, but I may be wrong.

```js
({ foo(); bar(); })
```


It's a syntax error, in any JS repl or standard.

The Node repl only removes parens if it tries adding them first around braced input and that fails.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Brendan Eich-2
In reply to this post by Dean Landolt
Dean Landolt wrote:

> On Tue, Jan 6, 2015 at 3:57 PM, Marius Gundersen <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I don't see how wellLabeledStatement will protect against object
>     literals with shorthand properties, like (x, y, z) => {x, y, z}.
>
>
> It would "protect" against them by disallowing them without the paren
> wrapping. A fail-fast SyntaxError beats the hell out of trying to
> diagnose an almost imperceptible runtime bug.

No, Marius has a point here: there's no LABEL: before anything in {x, y, z}.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: (x) => {foo: bar}

Rick Waldron
In reply to this post by Isiah Meadows


On Tue Jan 06 2015 at 4:53:05 PM Isiah Meadows <[hidden email]> wrote:

Okay: is this a valid statement/expression? I didn't think so, but I may be wrong.

```js
({ foo(); bar(); })
```

That's not valid for any grammar in up to and including ES6. 

To make it valid, pick one, but not both: 

- Remove the parens and it's valid block syntax.
- Remove everything inside the curlies, except for the word `foo` and it's valid object literal syntax, containing an identifier reference for some binding named `foo` (property short hand). 

Rick

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123