Andreas Rossberg wrote:
Honestly, my
feeling is that strictly sticking to that principle will overly
constrain pattern syntax anyway, if not for 'as' then for the next
nice feature. I dimly remember that we had it coming up before.
Dave and I were talking about making fail-soft or "irrefutable match"
opt-in:
js> let {x} = {};
js> x
(SpiderMonkey shell.)
IOW, destructuring has been conceived of as pretty thin sugar for
getting a property, and if no such property, you get undefined. Of
course, this makes a deeper pattern fail hard:
js> let {y:{z}} = {};
typein:4: TypeError: (void 0) is undefined
(Atrocious SpiderMonkey failure to pretty-print the blamed expression
instead of its portable (void 0) value there -- my fault I think.)
Dave suggested making the first case, let {x} = {}, throw, and requiring
? as a pattern modifier (I suggested prefix):
let {?x} = {}; // x is undefined, no throw
let {y} = {}; // throws
So there's another place the pattern language wants to diverge from
object literal notation.
One alternative of course would be to restrict what can occur in an
assignment pattern, compared to bindings. The two are quite different
semantically, so it could perhaps be argued. But it's not the most
pleasant idea either.
Turns out Allen has already done this in ES6 drafts. 11.13.1 is for
destructuring assignment. 12.2.4 is destructuring binding patterns. So
we can diverge patterns further.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
