<div dir="ltr"><div>Is there any interest from a TC39 member with regards to a possible pick notation or `Object.pick` method? It's been something proposed a few times over, typically using similar syntax, and seems to have broad support.</div><div><br></div><div>At the very least, couldn't this become a stage 0 proposal? Bob has already created a [repository], and the [process document] specifies no entrance criteria for stage 0. If a champion were identified, stage 1 doesn't seem far off.<br></div><div><br></div><div>[repository]: <a href="https://github.com/rtm/js-pick-notation">https://github.com/rtm/js-pick-notation</a></div><div>[process document]: <a href="https://tc39.es/process-document/">https://tc39.es/process-document/</a></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Jacob Pratt<br></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 5, 2019 at 5:59 AM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nit: 2A will reject thanks to TDZ semantics with `name` in the RHS<br>
where it's defined in the LHS of the same statement. (Think of the<br>
function body's lexical context as being in a block where parameters<br>
are in a parent block context. The block variable shadows the parent<br>
variable for the whole block and just initially starts as unset.) So<br>
that error *will* get caught fairly quickly.<br>
<br>
But aside from that:<br>
<br>
I agree 1A is a bit too noisy, especially in the parameter side.<br>
<br>
1B could be simplified a bit. Have you considered leveraging the<br>
existing object rest+spread and just standard property accesses? This<br>
is technically shorter than your suggestion and is much less<br>
cluttered. (I do see a frequent pattern of premature destructuring<br>
when it's shorter, easier, and simpler *not* to.)<br>
<br>
```<br>
return {...state.user.{firstName, lastName}, url: state.common.currentPageURL}<br>
```<br>
<br>
2A could be fixed to work like this, which is technically shorter than<br>
your example:<br>
<br>
```<br>
const resp = await sendToServer({name})<br>
return {ok: true, payload: {name: <a href="http://resp.name" rel="noreferrer" target="_blank">resp.name</a>}}<br>
```<br>
<br>
And likewise, you could simplify 2B to this:<br>
<br>
```<br>
const resp = await sendToServer({name})<br>
return {ok: true, payload: resp.{name}}<br>
```<br>
<br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
On Tue, May 28, 2019 at 3:13 PM Григорий Карелин <<a href="mailto:grundiss@gmail.com" target="_blank">grundiss@gmail.com</a>> wrote:<br>
><br>
> Here are another examples, where "destructuring picking" I suggest whould be helpful.<br>
> ==1A Now (redux related)<br>
> ```<br>
> function mapStateToProps({user: {firstName, lastName}, common: {currentPageURL: url}}) {<br>
>   return {firstName, lastName, url};<br>
> }<br>
> ```<br>
> ==1B Proposal<br>
> ```<br>
> function mapStateToProps(state) {<br>
>   return {{firstName, lastName from state.user}, {currentPageURL as url from state.common}};<br>
> }<br>
> ```<br>
><br>
> Shorter!<br>
><br>
> ==2A Now<br>
> ```<br>
> async function saveNewUserName(name) {<br>
>   const {name} = await sendToServer({name});<br>
><br>
>   return {ok: true, payload: {name}}; // oh wait, which name is it again? Argument or response?<br>
> }<br>
> ```<br>
> == 2B Proposal<br>
> ```<br>
> async function saveNewUserName(name) {<br>
>   const resp = await sendToServer({name});<br>
><br>
>   return {ok: true, {name from response}};<br>
> }<br>
> ```<br>
> No accidental shadowing.<br>
><br>
> I know, I know, you can achieve all that without new syntax, via naming your variables properly and using long explicit expressions. But I think some sugar won't hurt.<br>
> After all, remember destructuring? There's no reason to use it other than it's cool and short and expressive.<br>
><br>
><br>
> вт, 28 мая 2019 г. в 21:49, guest271314 <<a href="mailto:guest271314@gmail.com" target="_blank">guest271314@gmail.com</a>>:<br>
>>>><br>
>>>> ```<br>
>>>> let obj = {otherData: "other data"};<br>
>>>> ({firstName:obj.firstName, lastName:obj.lastName} = user.profile);<br>
>>>> ```<br>
>>>><br>
>>>> I don't understand this.<br>
>><br>
>><br>
>> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Assigning_to_new_variable_names" rel="noreferrer" target="_blank">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Assigning_to_new_variable_names</a><br>
>><br>
>>> He's looking for a terser<br>
>><br>
>><br>
>> Is the proposal to golf destructuring assignment?<br>
>><br>
>> The proposed destructuring assignment syntax example is 25 characters less than the non-destructing assignment example, which is terser.<br>
>><br>
>> One observation about the proposed syntax is that the values set at the target object would be set from the identifier on the left side of ```from``` which is similar to<br>
>><br>
>> ```<br>
>> var o = {x:1};<br>
>> console.log(o.x = 2); // 2<br>
>> ```<br>
>><br>
>> though how will the property name be set at the object at target object instead of `{"2":2}`? How does the engine know when the expected result is ```{"x":2}``` and not ```{"2":2}```? Certainly such functionality can be designed, for example, using the proposed key word ```from```.<br>
>><br>
>> If more terse code is one of the features that would be achieved, why are the wrapping `{}` around ```from`` necessary?<br>
>><br>
>> > moire elegant way to do it,<br>
>><br>
>> "elegant" is subjective<br>
>><br>
>> > which hopefully would be moire semantic, less bug-prone, more type-checkable (for typed variants of the language), more reminiscent of existing syntax such as deconstruction, and potentially more optimizable by engines.<br>
>><br>
>> What is bug prone about the code examples at OP?<br>
>><br>
>> This proposal would resolve the issue of currently, in general, having to write the property name twice.<br>
>><br>
>><br>
>><br>
>> On Tue, May 28, 2019 at 2:47 PM Bob Myers <<a href="mailto:rtm@gol.com" target="_blank">rtm@gol.com</a>> wrote:<br>
>>>><br>
>>>> ```<br>
>>>> let obj = {otherData: "other data"};<br>
>>>> ({firstName:obj.firstName, lastName:obj.lastName} = user.profile);<br>
>>>> ```<br>
>>><br>
>>><br>
>>> I don't understand this.<br>
>>><br>
>>>><br>
>>>> Alternatively there are various approaches which can be used to get only specific properties from an abject and set those properties and values at a new object without using destructing assignment.<br>
>>>><br>
>>>> Using object rest and ```reduce()```<br>
>>>><br>
>>>> ```let obj = {otherData: "other data", ...["firstName", "lastName"].reduce((o, prop) => (o[prop] = user.profile[prop], o), {})};```<br>
>>>><br>
>>>> `Object.assign()`, spread syntax and `map()`<br>
>>>><br>
>>>> ```let obj = Object.assign({otherData: "other data"}, ...["firstName", "lastName"].map(prop => ({[prop]:user.profile[prop]})));```<br>
>>><br>
>>><br>
>>> As the words "syntactic sugar" in the subject of the thread make clear, the OP is not merely looking for ways to assign one object's property into another--there are many ways to do that. He's looking for a terser, moire elegant way to do it, which hopefully would be moire semantic, less bug-prone, more type-checkable (for typed variants of the language), more reminiscent of existing syntax such as deconstruction, and potentially more optimizable by engines.<br>
>>><br>
>>> Bob<br>
>>> _______________________________________________<br>
>>> es-discuss mailing list<br>
>>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
>><br>
>> _______________________________________________<br>
>> es-discuss mailing list<br>
>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
><br>
><br>
><br>
> --<br>
> С уважением,<br>
> Карелин Григорий<br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>