Please allow CoverInitializedNames in non-Pattern ObjectLiterals

[caitp]

It's a lot of effort to track where the CoverInitializedName occurs, and then later determine if it's allowed to be present there.

Why not just allow it everywhere? property name = LHS, value = evaluation of RHS.

var x;
var foo = { x = 10 }; // equivalent of `var foo = { x: x = 10 }`
console.log(x) // 10
console.log(foo) // { x: 10 }

It would at simplify implementation a bit.

Maybe, if it was really necessary, it could have consistency with the behaviour of destructuring, such that

var x;
var foo = { x = 10 }; // equivalent of `var foo = { x: x === void 0 ? 10 : x }`
console.log(x) // undefined
console.log(foo) // { x: 10 }

[bterlson]

Making new syntax for { x: x = 10 } doesn't seem good - it does an assignment to x (or is an error in strict mode if an x binding doesn't exist). The destructuring-like version is interesting but questionably useful as well. Not sure it's worth adding these forms for helping parsers.

[bterlson]

Making new syntax for { x: x = 10 } doesn't seem good - it does an assignment to x (or is an error in strict mode if an x binding doesn't exist). The destructuring-like version is interesting but questionably useful as well. Not sure it's worth adding these forms for helping parsers.

[allenwb]

If we'd wanted to extend object literals with that syntax we would have specified it.

In practice, you don't need to defer the check. That's why they are explicitly called out as early errors. The covered initializer syntax is only valid within patterns and patterns are only valid in a few specific syntactic contexts. An implementation is perfectly free to internally use different grammars for pattern context and for object literal contexts.

[allenwb]

If we'd wanted to extend object literals with that syntax we would have specified it.

In practice, you don't need to defer the check. That's why they are explicitly called out as early errors. The covered initializer syntax is only valid within patterns and patterns are only valid in a few specific syntactic contexts. An implementation is perfectly free to internally use different grammars for pattern context and for object literal contexts.

[caitp]

the problems can be worked around, but it just doesn't seem particularly worth it

[caitp]

the problems can be worked around, but it just doesn't seem particularly worth it

[caitp]

You do need to defer the check, because you don't know if you're parsing a pattern or not, until after you've parsed it.

You know you're parsing a pattern if you're parsing a VariableStatement or LexicalDeclaration or CatchParameter, or if you're parsing function formals after having seen the function keyword.

You don't know if you're parsing Arrow function formals until you see the =>, or if you're parsing destructuring assignment (where it's only invalid if it occurs in an ObjectLiteral in the right-most assignment)

An implementation is perfectly free to internally use different grammars for pattern context and for object literal contexts.

There is no "context", unless your parser has the ability to go back and re-parse a chunk of text, which isn't happening any time soon

[caitp]

You do need to defer the check, because you don't know if you're parsing a pattern or not, until after you've parsed it.

You know you're parsing a pattern if you're parsing a VariableStatement or LexicalDeclaration or CatchParameter, or if you're parsing function formals after having seen the function keyword.

You don't know if you're parsing Arrow function formals until you see the =>, or if you're parsing destructuring assignment (where it's only invalid if it occurs in an ObjectLiteral in the right-most assignment)

An implementation is perfectly free to internally use different grammars for pattern context and for object literal contexts.

There is no "context", unless your parser has the ability to go back and re-parse a chunk of text, which isn't happening any time soon

[allenwb]

True for LHS contexts, but not true for declaration contexts. And that are various ways you can approach implementing this that dopes not have too high an overhead.

TC39 was well aware of these issues when we decided to add syntax that requires a cover grammar and we decided that implementors could deal with them (it's not like nobody on TC39 had ever written a compiler before...).

We certainly don't ignore implementor convenience, but it is secondary concern.

[allenwb]

True for LHS contexts, but not true for declaration contexts. And that are various ways you can approach implementing this that dopes not have too high an overhead.

TC39 was well aware of these issues when we decided to add syntax that requires a cover grammar and we decided that implementors could deal with them (it's not like nobody on TC39 had ever written a compiler before...).

We certainly don't ignore implementor convenience, but it is secondary concern.

[caitp]

I know you're aware of all this, which is why it's curious what the point is in making the grammars so different for no particularly useful reason? The difference between the cover grammar and the ObjectLiteral grammar doesn't serve any compelling purpose.

Anyways, the ambiguity can be handled, but there isn't really any point to the difference in the first place

[caitp]

I know you're aware of all this, which is why it's curious what the point is in making the grammars so different for no particularly useful reason? The difference between the cover grammar and the ObjectLiteral grammar doesn't serve any compelling purpose.

Anyways, the ambiguity can be handled, but there isn't really any point to the difference in the first place

[bterlson]

I believe that throwing errors for easy mistakes like let point = { x = 1, y = 2 }; serves a compelling purpose.

[bterlson]

I believe that throwing errors for easy mistakes like let point = { x = 1, y = 2 }; serves a compelling purpose.

[allenwb]

and we've have had to invent a meaning for such assignments within actual object literals, which would have precluded a possible future extension point,

[allenwb]

and we've have had to invent a meaning for such assignments within actual object literals, which would have precluded a possible future extension point,