Thank you for your comments.

The proposed picking syntax has gone through several iterations. Way back
when, we had

```
o # {a, b}
```

for picking properties `a` and `b` from `o`, resulting in `{a: o.a, b:
o.b}`. That, however, would of course eat a precious symbol. So a later
version replaced the `#` with the dot `.`, which makes some semantic sense,
since the dot has been used for two decades to "pick" a property into a
*value*; that is the reason that in some versions this proposal was called
"extended dot notation". This looked like:

```
o.{a, b}
```

This proposal had the benefit of a narrow syntactic footprint, since the
grammar has never allowed anything other than an identifier to follow the
dot. On the other hand, it had the downside that the dot was not very
visible.

(I unfortunately then muddied the waters by trying to extend the dot in
additional ways, such as bracket-less array indices, finally solving the
`array#first` and `array#last` problems by allowing `array.0` and
`array.-1`. But I digress.)

But then I considered that we might want to pick from two or more objects
into a single new object, and I didn't see how to do that easily with this
syntax. But now we have spread properties, so we could write

```
{...p.{p1, p2}, ...q.{q1, q2}}
```

But there was another consideration, which was consistency of syntax
between picking (destructuring) into variables, versus picking into
objects. Since ES6 we have had the `{p2, p2} = p` syntax for picking into
variables. So the notion was to use precisely this destructuring assignment
syntax, complete with its features for defaults, renaming, and nesting, for
picking into objects, simply by placing it inside an object literal. That's
how I ended up with the current proposal, which is

```
{ {p1, p2} = p, {q1, q2} = q }
```

But I still think the so-called "extended dot notation" version is entirely
viable.

Looking back over some old threads, I see comments like:

> The first issue (in chronological order) with that proposal is the lack
of motivation. What is the problem that the proposal is trying to solve?

Whatever one can say about this problem or proposed solution does not
include it not being well-defined. The problem statement is that we want to
pick properties `p1`, `p2`, and `p3` from one object `p` into another
object, in a more concise, brief, less repetitive, less error-prone way
than saying `{p1: p.p1, p2: p.p2, p3: p.p3}`. I wonder if that is really
that hard to understand. Whether or not that's *important* is a different
question, of course.

The reason I started thinking about this issue, eons ago, is that I ran
into it, regularly, in my own programming work, since I'm an active
programmer who designs and codes much of the day. This question of how to
"pick" from objects into objects also comes up over and over again on Stack
Overflow. The current "best" "one-line" solution, at least by number of
upvotes (provided by me, before I went cold turkey) was

```
(({p1, p2}) => ({p1, p2}))(p)
```

This requirement/need/desire has also been raised on this forum half a
dozen times by different folks over the years.

Of all the reactions to this proposal, other than "who cares", one of the
most common is that we already have `_.pick` in popular libraries. Well,
something being in a library can just as easily be interpreted as meaning
it's a *good* candidate for being added to the language, as meaning that it
doesn't need to be. Also, implementing this in user-land also requires
quoting the property names, as in `_.pick(p, ['p1', 'p2'])`, which is
awkward at best. New features in Typescript allow you to write your own
pick-type operators in a more type-safe way than was the case previously,
but still it requires some gymnastics.

Another common reaction is "big deal, saving a few characters or lines".
But more than one recent language feature also falls into this category of
mainly or purely sugar and brevity. For instance, property spread syntax is
pretty much just sugar for `Object.assign`, yet everyone seems to think
it's the best thing since sliced bread.

Bob

On Sat, Feb 10, 2018 at 10:07 AM, Naveen Chawla <naveen.chwl at gmail.com>
wrote:

> Sorry sent by accident before my message was edited properly. My basic
> point was that since curly braces are used for both destructuring and
> object literals, there's an issue with being able to glance at the code and
> quickly discern what's happening if they are mixed together in the same
> piece of syntax. Not impossible, just a potential source of bugs and/or
> delay in understanding the data structure being declared.
>
> On Sat, 10 Feb 2018 at 10:01 Naveen Chawla <naveen.chwl at gmail.com> wrote:
>
>> I'm not a TC39 member, but I have a little readability issue with
>> destructuring inside an object:
>>
>> ```js
>> { {p1, p2} = p, {q1, q2} = q }
>> ```
>>
>> has a very different meaning than
>>
>> ```js
>> { p: {p1, p2}, {q1, q2} = q }
>> ```
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180210/fc58f653/attachment.html>

Thank you for your comments.

The proposed picking syntax has gone through several iterations. Way back
when, we had

```
o # {a, b}
```

for picking properties `a` and `b` from `o`, resulting in `{a: o.a, b:
o.b}`. That, however, would of course eat a precious symbol. So a later
version replaced the `#` with the dot `.`, which makes some semantic sense,
since the dot has been used for two decades to "pick" a property into a
*value*; that is the reason that in some versions this proposal was called
"extended dot notation". This looked like:

```
o.{a, b}
```

This proposal had the benefit of a narrow syntactic footprint, since the
grammar has never allowed anything other than an identifier to follow the
dot. On the other hand, it had the downside that the dot was not very
visible.

(I unfortunately then muddied the waters by trying to extend the dot in
additional ways, such as bracket-less array indices, finally solving the
`array#first` and `array#last` problems by allowing `array.0` and
`array.-1`. But I digress.)

But then I considered that we might want to pick from two or more objects
into a single new object, and I didn't see how to do that easily with this
syntax. But now we have spread properties, so we could write

```
{...p.{p1, p2}, ...q.{q1, q2}}
```

But there was another consideration, which was consistency of syntax
between picking (destructuring) into variables, versus picking into
objects. Since ES6 we have had the `{p2, p2} = p` syntax for picking into
variables. So the notion was to use precisely this destructuring assignment
syntax, complete with its features for defaults, renaming, and nesting, for
picking into objects, simply by placing it inside an object literal. That's
how I ended up with the current proposal, which is

```
{ {p1, p2} = p, {q1, q2} = q }
```

But I still think the so-called "extended dot notation" version is entirely
viable.

Looking back over some old threads, I see comments like:

> The first issue (in chronological order) with that proposal is the lack of motivation. What is the problem that the proposal is trying to solve?

Whatever one can say about this problem or proposed solution does not
include it not being well-defined. The problem statement is that we want to
pick properties `p1`, `p2`, and `p3` from one object `p` into another
object, in a more concise, brief, less repetitive, less error-prone way
than saying `{p1: p.p1, p2: p.p2, p3: p.p3}`. I wonder if that is really
that hard to understand. Whether or not that's *important* is a different
question, of course.

The reason I started thinking about this issue, eons ago, is that I ran
into it, regularly, in my own programming work, since I'm an active
programmer who designs and codes much of the day. This question of how to
"pick" from objects into objects also comes up over and over again on Stack
Overflow. The current "best" "one-line" solution, at least by number of
upvotes (provided by me, before I went cold turkey) was

```
(({p1, p2}) => ({p1, p2}))(p)
```

This requirement/need/desire has also been raised on this forum half a
dozen times by different folks over the years.

Of all the reactions to this proposal, other than "who cares", one of the
most common is that we already have `_.pick` in popular libraries. Well,
something being in a library can just as easily be interpreted as meaning
it's a *good* candidate for being added to the language, as meaning that it
doesn't need to be. Also, implementing this in user-land also requires
quoting the property names, as in `_.pick(p, ['p1', 'p2'])`, which is
awkward at best. New features in Typescript allow you to write your own
pick-type operators in a more type-safe way than was the case previously,
but still it requires some gymnastics.

Another common reaction is "big deal, saving a few characters or lines".
But more than one recent language feature also falls into this category of
mainly or purely sugar and brevity. For instance, property spread syntax is
pretty much just sugar for `Object.assign`, yet everyone seems to think
it's the best thing since sliced bread.

Bob