Brendan Eich 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
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
Even when we want to throw early errors for object-literal-like block, I
consider my argument still valid.
```()={ method() { }}```Should we throw an early error? Of course not, but
it might be a potential error; out task is not to warn on object-literal-like
block; instead, maybe simply we
Allen Wirfs-Brock wrote:
ObjectLiteral is already doing double duty covering ObjectAssignmentPattern.
so this would be even more complexity in this area of the grammar.
Yeah, the complexity counter-argument is strong.
Finally, I'm sort of on the side that this may not be so good for
Allen Wirfs-Brock wrote:
On Jan 6, 2015, at 5:34 PM, Gary Guo wrote:
I found that even without shorthand, the object literal can still be
ambiguous with block.
Yes, but not in the context of a ConciseBody of an ArrowFunction.
The grammar for ConciseBody
On Jan 7, 2015, at 1:23 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Jan 6, 2015, at 5:34 PM, Gary Guo wrote:
I found that even without shorthand, the object literal can still be
ambiguous with block.
Yes, but not in the context of a ConciseBody of an ArrowFunction.
The
On Jan 6, 2015, at 5:34 PM, Gary Guo wrote:
I found that even without shorthand, the object literal can still be
ambiguous with block.
Yes, but not in the context of a ConciseBody of an ArrowFunction.
The grammar for ConciseBody
returns 1.
From: a...@kocharin.ru
To: nbdd0...@hotmail.com; bren...@mozilla.org
CC: es-discuss@mozilla.org
Subject: Re: (x) = {foo: bar}
Date: Tue, 6 Jan 2015 06:59:52 +0300
06.01.2015, 06:38, Gary Guo nbdd0...@hotmail.com: Though I am strongly
negative, but there actually
a...@kocharin.ru
To: Gary Guo nbdd0...@hotmail.com, bren...@mozilla.org
bren...@mozilla.org
Cc: es-discuss@mozilla.org es-discuss@mozilla.org
Date: Tue, 06 Jan 2015 06:59:52 +0300
Subject: Re: (x) = {foo: bar}
06.01.2015, 06:38, Gary Guo nbdd0...@hotmail.com:
Though I am strongly negative
Can anyone explain what to expect as a result of the following expression?
var fn = () = ({ a, b } = { a: 0, b: 1 });
1.
var fn = function () {
var a = 0,
b = 1;
return { a: a, b: b };
};
or
2. (traceur-compiler)
var fn = function () {
var tmp;
return (tmp = {a:
That's what I thought. Didn't think I had gone crazy there.
On Jan 6, 2015 5:45 PM, Brendan Eich bren...@mozilla.org 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
Dean Landolt wrote:
On Tue, Jan 6, 2015 at 3:57 PM, Marius Gundersen gunder...@gmail.com
mailto:gunder...@gmail.com 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
var fn = () = ({ a, b } = { a: 0, b: 1 });
The expression `({ a, b } = { a: 0, b: 1 })` is a destructuring
assignment. If there are lexical bindings for `a` and `b` it will assign
to those. Otherwise, in strict mode it will fail with a ReferenceError.
In sloppy mode, it will assign to the
On Tue, Jan 6, 2015 at 3:57 PM, Marius Gundersen gunder...@gmail.com
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
On Tue Jan 06 2015 at 4:53:05 PM Isiah Meadows impinb...@gmail.com 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:
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
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.
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
I found that even without shorthand, the object literal can still be ambiguous
with block.
```js()={ method() {
}}
shall it be interpreted as()=({ method(){// method body }})
or
()={ method(); {// block statement }}```
This is certainly an ambiguity that cannot be resolved by
On Mon, Jan 5, 2015 at 6:06 PM, Brendan Eich bren...@mozilla.org 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
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
: (x) = {foo: bar}
06.01.2015, 06:38, Gary Guo nbdd0...@hotmail.com:
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
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
From: Alex Kocharin a...@kocharin.ru
To: Gary Guo nbdd0...@hotmail.com, bren...@mozilla.org
bren...@mozilla.org
Cc: es-discuss@mozilla.org es-discuss@mozilla.org
Date: Tue, 06 Jan 2015 06:59:52 +0300
Subject: Re: (x) = {foo: bar}
06.01.2015, 06:38, Gary Guo nbdd0...@hotmail.com:
Though
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
06.01.2015, 06:38, "Gary Guo" nbdd0...@hotmail.com: 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;})`
@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
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
That's good news, thanks for the strawman link. Is it correct to assume
this with that proposal?
var f = (x) = (y) = {x, y};
f(1)(2) // = {x: 1, y: 2};
On Mon, Jan 5, 2015 at 12:54 PM, Brendan Eich bren...@mozilla.org wrote:
Caitlin Potter wrote:
The strawman changes to the grammar are
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
Frankie Bagnardi wrote:
That's good news, thanks for the strawman link. Is it correct to
assume this with that proposal?
var f = (x) = (y) = {x, y};
f(1)(2) // = {x: 1, y: 2};
Good point, the strawman does not take object literal shorthand into
account and indeed parses {x, y} in an
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
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
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)
In the implementations I checked, this is actually allowed, but it's
parsed as a label instead of what you may expect at first glance (an
object).
For it to be a concise body, you need to change it to `let f = (x) =
({foo: bar});`. Otherwise, it's like a regular function body.
On Mon, Jan 5,
this seems like a footgun and has tripped people up in the wild
https://twitter.com/jankrems/status/544645776518184960
On Mon Jan 05 2015 at 2:05:52 PM Caitlin Potter caitpotte...@gmail.com
wrote:
In the implementations I checked, this is actually allowed, but it's
parsed as a label instead
] On Behalf Of Brendan
Eich
Sent: Monday, January 5, 2015 14:41
To: Calvin Metcalf
Cc: es-discuss
Subject: Re: (x) = {foo: bar}
See
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
This could be done, but not for ES6. Sorry I didn't push this harder, earlier.
/be
Calvin
Domenic Denicola wrote:
What do you think the chances of this are in ES7+? That is, how
backward-compatible is this change? The linked strawman doesn't seem to touch on
`() = { foo: bar }` as a back-compat hazard.
The strawman discusses compatibility explicitly:
-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Brendan Eich
Sent: Monday, January 5, 2015 14:41
To: Calvin Metcalf
Cc: es-discuss
Subject: Re: (x) = {foo: bar}
See
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
This could be done, but not for ES6
Caitlin Potter wrote:
The strawman changes to the grammar are still ambiguous :(
`() = {}` - noop or Object or SyntaxError? If SyntaxError, ...why?
No, the strawman addresses this: An empty pair of braces |*{}*| other
than at start of /Statement/ is an /ObjectLiteral/. The grammar is
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
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!
42 matches
Mail list logo
