(Resolved) Shorthand object destructurings

[lth]

I know Jeff has said "no new syntax" but I observe that when I use object destructurings, they are often of the sort where the field name and variable name are the same, because I'm just picking fields out of a structure in a single phrase:

  function cgIfStmt(ctx, { test: test,
                           alternate: alternate,
                           consequent: consequent }) {
     ...
  }

Might it be an idea to allow destructuring shorthands for this, a la SML:

  function cgIfStmt(ctx, { test, alternate, consequent }) {
     ...
  }

Syntactically, this is not ambiguous, from what I can tell.

There would be no problem with mixing both styles in a single destructurer:

  function cgIfStmt(ctx, { test, alternate: S1, consequent: S2 }) {
     ...
  }

[lth]

Jeff says: in that case, in order to keep object constructors and destructurers compatible, perhaps one should allow the shorthand for construction as well, this might be useful for constructing subset or superset objects:

   f({x, y, z} = bigstruct)

Obviously makes no sense for type annotations, so we can't stretch the compatibility too far.

[jeffdyer]

Accepted at Yahoo! meeting. Changing to RI bug.

[brendan]

Not sure what "for construction as well" means -- the example

f({x, y, z} = bigstruct)

looks like destructuring assignment, as proposed here, and not construction via an object initialiser shorthand:

var o = {x, y, z}
assert(o.x === x)
assert(o.y === y)
assert(o.z === z)

assuming x, y, and z are bound in the scope chain.

Is this object initialiser shorthand proposed too? If so, I missed it at the Yahoo! f2f last summer. If not, then we are requiring more cover-grammar parsing followed by semantic checking, or bottom-up parsing -- something we have argued against elsewhere (e.g., any lambda syntax of the form x => x*x or (x, y) => a*x*x + b*y*y). (I'm not arguing for that lambda syntax, just asking about design rules and restrictions.)

/be

[lth]

You're right about the ambiguity. I think Jeff and I may have been misled by the desirability of shortening this object initializer:

   { x: x, y: y, z: z }

to this:

   { x, y, z }

(which is not ambiguous, I believe). Following the train of thought we get the more general pattern which now to mee looks like a combined destructure/structure, which is probably all wrong.

I would like to remove the shorthand construction proposals, to the extent they exist, from this ticket. A separate ticket could be opened for that.

This ticket is only about shorthand destructuring described in the Description, which (looking at the clutter in the ESC code) will certainly be handy.

[jeffdyer]

Agreed. Let's separate the two proposals. The destructuring shorthand covered by this ticket seems uncontroversial.

Jd

[lth]

Approved at the Jan 08 2008 meeting.

[David-Sarah Hopwood]

Proposal still relevant to ES-Harmony.