domenic at domenicdenicola.com (2013-08-19T05:04:57.490Z)
I think the reasoning here should be through trying to predict the most frequent use-cases. 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. 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. It seems to me that not throwing fits better for JS nature. 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.
On Friday, August 16, 2013, Allen Wirfs-Brock wrote: > > On Aug 15, 2013, at 9:27 PM, David Herman wrote: > > > This is *not* what I remember of the conversation, at all. > > > > 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. > > > > IOW, we don't have consensus about this issue. > > > > 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. > > 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. > > The decisions that need to be made are simply: > > 1. Regarding a value that is being destructured: Implicit conversion to > object or no implicit conversion, for example the following all throw: > > let {a } = undefined; //throw or interpreted as { } > let [x,...y] = "abc"; // ToObject("abc")? > (({x})=>x)(0); // ToObject(0)? > let {a: {x}} = {a: false}; // ToObject(false) ? > > The July meeting notes explicit report consensus that ToObject should not > be applied in the above cases. > > 2. Do unmatched property selectors in patterns bind to undefined or throw > o: > > let {a} = {b:5}; // is a initialized to undefined or does this throws > let [a,b,c] = [0,1]; // is c initialized to undefined or does this throws > > Note that for #2 a default value expression over-rides either alternative > > let {a=undefined} = {b:5}; //variable a initialized to undefined > let [a,b,c=2] = [0,1]; // a initialized to 0, b to 1, c to 2 > > > So, the answer to #2 is the only open one. > > 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. > > Dave, is throwing on a missing property if it lacks a default value the > thing that you consider to be a mistake? > > 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. > > I think the reasoning here should be through trying to predict the most frequent use-cases. 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. 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. It seems to me that not throwing fits better for JS nature. 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. Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130816/b52da6f5/attachment-0001.html>