Clarify the destructuring syntax

[Егор Николаев]

On the one hand, the is a bug in current spec that allows the
```javascript
let {length} = "qwe";
```
but disallow
```javascript
let {text: {length}} = {text: "qwe"};
```

On the other hand, this restriction can lead to hard-reproducibly errors.
When I write a function such as:
```javascript
function returnLength( {length} ) {
    return length;
}
```
I can't be sure that foreign user will not use it as:
```javascript
var obj = { toString(){ return "test" } };
returnLength( obj + "" );
```
In this case, I have no other chose, but to rewrite function without
destructuring in function parameter:
```javascript
function returnLength( text ) {
    text = new String(text);// do not remove it, without this line following
destructuring pattern will throw a error
    let {length} = text;
    return length;
}
```
Of course, in real app this function would be more complex.




On Fri, Apr 11, 2014 at 7:26 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Apr 11, 2014, at 5:22 AM, André Bargull wrote:
>
> > On 4/11/2014 2:02 PM, Егор Николаев wrote:
> >> @André Bargull
> >> Are there any reasons for these restrictions? It confuses me. If I can
> >> for-of over string, so why can't I destructuring it?
> >
> > I'd say it's mostly a language designer decision and it may still change
> before the final specification is published. I'd encourage you to file bug
> reports at https://bugs.ecmascript.org/ and/or post to this mailing list
> if you find any issues with the current specification draft. That way Allen
> (the spec editor, cc-ed) and other TC-39 members are notified and can take
> appropriate actions.
>
> This was discusses fairly extensively in TC39 meetings and on this list.
>  The final consensus was that non objects should not be destructurable (ie,
> ToObject is not applied).  One argument against allowing non-objects is
> that it might be future-hostile to anticipated future proposal to  turn
> destructuring into  more general pattern patching,
>
> This is the decision that is reflected in the ES6 draft starting with
> rev17. As it stand right now, there is no advocacy within TC39 for
> reopening this decision.
>
> Allen
>
>
>
>
>
>
> >
> >
> > - André
> >
> >
> >>
> >>
> >> On Fri, Apr 11, 2014 at 3:10 PM, André Bargull <andre.bargull at udo.edu
> >> <mailto:andre.bargull at udo.edu>> wrote:
> >>
> >>>    Hi Erop,
> >>>
> >>>
> >>>    On Fri, Apr 11, 2014 at 12:35 PM, Егор Николаев <termi1uc1 at
> gmail.com  <https://mail.mozilla.org/listinfo/es-discuss>> wrote:
> >>>
> >>>    >/  1. Should the AssignmentExpression of DestructuringAssignment
> always to be
> >>>    /
> >>>    >/the Object type? />/```javascript />/let {length} = "123";
> >>>    />/assert(length, 3); />/``` />/Is this valid? />// Yes.
> >>
> >>    No.
> >>
> >>    13.2.1.4 Runtime Semantics: Evaluation,
> >>    LexicalBinding : BindingPattern Initializer, step 4
> >>
> >>
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-let-and-const-declarations-runtime-semantics-evaluation
> >>
> >>
> >>
> >>>    >/
> >>>    />/  If it is:
> >>>    />/  2. Should the result of Get(obj, name) always be the Object
> type if
> >>>    />/  DestructuringAssignmentTarget is an ObjectLiteral or an
> ArrayLiteral?
> >>>    />/  According the spec 12.14.5.4 step 4.b this expression is
> invalid:
> >>>    />/  ```javascript
> >>>    />/  let {text: {length}} = {text: "123"};
> >>>    />/  assert(length, 3);
> >>>    />/  ```
> >>>    />/
> >>>    /
> >>>    Yes.
> >>
> >>    No.
> >>
> >>    13.2.3.7 Runtime Semantics: KeyedBindingInitialization
> >>    BindingElement : BindingPattern Initializer_opt, step 4
> >>
> >>
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-keyedbindinginitialization
> >>
> >>
> >>>    You can test this in the web console in a Nightly or Aurora build of
> >>>    Firefox.
> >>
> >>    You can test this in traceur or my test implementation
> >>    [https://github.com/anba/es6draft].  ;-)
> >>
> >>    Maybe the final draft will revert this restriction, it was
> >>    originally introduced in rev17. It is somewhat annoying, especially
> >>    for the string type, because the restriction also applies to spread
> >>    array elements and spread calls. For example `[..."abc"]` must now
> >>    be written as `[...new String("abc")]` to get the array of code
> points.
> >>
> >>    - André
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140411/28554820/attachment-0001.html>