Suggestion: Destructuring object initializer.

[Naveen Chawla]

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 }
> ```
>
>
> On Fri, 9 Feb 2018 at 16:55 Bob Myers <rtm at gol.com> wrote:
>
>> Thanks for your input.
>>
>> Actually, I was not trying to beat the dead horse of my property picking
>> proposal, but rather give advice to another would-be spec proposer based on
>> my experience.
>>
>> But since you brought it up, the spec for property picking can be found
>> at https://github.com/rtm/js-pick-notation. As with any spec, one could
>> argue that it's too brief, or too verbose, or missing this or that, but
>> actually this is a very simple feature. There is a fair amount of
>> discussion on this list about this proposal, in various iterations, over
>> the last few years.
>>
>> As for an implementation, the TC39 process documents clearly state that
>> the implementation types expected for Stage 0 (strawman) is "*N/A*". I'd
>> be glad to write a Babel or sweet.js implementation, but I'm not quite sure
>> what it would prove.
>>
>> Although the TC39 documents are murky on this point, and some of them
>> appear to state that a proposal can gain Stage 0 status without a champion,
>> other information seems to say that getting a proposal to Stage 0 DOES
>> require the involvement of a TC39 member, even if they are not technically
>> considered a "champion" at that point...As for "trying to find" such a
>> champion, I thought posting to this group constituted such an effort, and
>> in addition I have reached out to a couple of members with no response.
>>
>> Here's a real quick intro to the proposal:
>>
>> ```
>> const {p1, p2} = p;
>> const [q1, q2} = q;
>> return {p1, p2, q2, q2};
>>
>> ==or==
>>
>> return {p1: p.p1, p2: p.p2, q1:q.q1, p2: q.q2};
>> ```
>>
>> becomes
>>
>> ```
>> return { {p1, p2} = p, {q1, q2} = q };
>> ```
>>
>> Yes, it's pretty much sugar--no brand new functionality here. It's about
>> brevity and expressiveness, which seems to have been a low enough bar for
>> several other features to pass. It steals no new symbols. It clearly
>> leverages existing destructuring assignment syntactical infrastructure.
>>
>> Bob
>>
>> On Fri, Feb 9, 2018 at 4:25 PM, Andy Earnshaw <andyearnshaw at gmail.com>
>> wrote:
>>
>>> Bob, I think it's an interesting idea too, but you can't strong-arm
>>> people into getting excited about what you're asking for.  If it really is
>>> that important to you then put together a solid proposal, write a Babel
>>> plugin and then try to find a champion for it.
>>>
>>> On Thu, 8 Feb 2018 at 14:05 Bob Myers <rtm at gol.com> wrote:
>>>
>>>> It does make one stop and wonder why the group will endlessly entertain
>>>> trolls debating whether or not ES6 (or ES5) portends the end of
>>>> civilization as we know it, while relentlessly ignoring literally dozens of
>>>> similar/identical proposals for property picking, a feature which easily
>>>> contributes as much to the language at as little cost as many other
>>>> features such as spread properties.
>>>>
>>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180210/3ec14702/attachment.html>