<br><br>On Friday, August 16, 2013, Allen Wirfs-Brock  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Aug 15, 2013, at 9:27 PM, David Herman wrote:<br>
<br>
> This is *not* what I remember of the conversation, at all.<br>
><br>
> My understanding was that pretty much everyone in the room, at least those who participated in the conversation, felt that refutable destructuring was a mistake, but that we couldn't really come to any conclusions without Brendan and Andreas there, since the two of them had championed refutable destructuring.<br>

><br>
> IOW, we don't have consensus about this issue.<br>
><br>
<br>
Personally, I think there is all too much confusion over the words "refutable" and "irrefutable".  I don't care about that terminology at all and we shouldn't be reading implications into the use of those terms.<br>

<br>
At the meeting we agree to take ? off the table because there are too many open issues and not enough time before the end of the year to address them and still get higher priority things done.<br>
<br>
The decisions that need to be made are simply:<br>
<br>
1. Regarding a value that is being destructured: Implicit conversion to object or no implicit conversion, for example the following all throw:<br>
<br>
let {a } = undefined;     //throw or interpreted as { }<br>
let [x,...y] = "abc";          //  ToObject("abc")?<br>
(({x})=>x)(0);                 // ToObject(0)?<br>
let {a: {x}} = {a: false}; // ToObject(false) ?<br>
<br>
The July meeting notes explicit report consensus that ToObject should not be applied  in the above cases.<br>
<br>
2. Do unmatched property selectors in patterns bind to undefined or  throw o:<br>
<br>
let {a} = {b:5};      //  is a initialized to undefined or does this throws<br>
let [a,b,c] = [0,1]; //  is c initialized to undefined or does this throws<br>
<br>
Note that for #2 a default value expression over-rides either alternative<br>
<br>
let {a=undefined} = {b:5}; //variable a initialized to undefined<br>
let [a,b,c=2] = [0,1];  // a initialized to 0, b to 1, c to 2<br>
<br>
<br>
So, the answer to #2 is the only open one.<br>
<br>
I think either is a reasonable default behavior for ES.  My current draft for 2 says throw on missing property unless a default value is provided.  Prior to refutable matching discussions and proposals it said: a missing treated as having the value undefined.<br>

<br>
Dave, is throwing on a missing property if it lacks a default value the thing that you consider to be a mistake?<br>
<br>
I'm happy to revert #2 back to not throwing, but the spec. must say something for these cases and I don't want to keep changing back and forth.   There are various views on regarding which alternative for #2 is more/less future friendly.  Personally, I think we still have plenty of future flexibility either way we go.<br>
<br></blockquote><div><br></div><div> I think the reasoning here should be through trying to predict the most frequent use-cases.</div><div><br></div><div>E.g. Erlang which completely based on pattern matching code, throws in this case. But Erlang is a functional with immutable state in its core, so there pattern matching at assignment is exactly the pattern matching (even for simple vars). And destrucuring there is just a consequence of pattern matching.</div>
<div><br></div><div>JS assignment is not a matching by its nature, and here the destrucuring is the main part. Especially if to take into account that for years foo.nonExisting returns undefined here.</div><div><br></div>
It seems to me that not throwing fits better for JS nature.<div><br></div><div>And for the strict match one could introduce match(...) function which already would throw providing exactly matching procedure first, and then destructuring as a consequence.</div>
<div><br></div><div>Dmitry<span></span></div>