fail-fast object destructuring

Andreas Rossberg rossberg at
Mon Jul 2 07:51:50 PDT 2012

On 26 June 2012 19:43, Brendan Eich <brendan at> wrote:

> Andreas Rossberg wrote:
>> On 25 June 2012 19:23, Allen Wirfs-Brock<allen at wirfs-brock.**com<allen at>>
>>  wrote:
>>> 3) Again we have a internal consistency issue:
>>>    let myFoo = {a:0,b:1}.foo;
>>> vs
>>>    let {foo: myFoo} = {a:0,b:1};
>>> why should one work and the other fail?  The general rule of JS is that
>>> accessing a missing property returns undefined. Whether or not you think it
>>> is a good rule, it's the way the core or the language works and it can't
>>> change.  It's also an easy rule for anybody to learn.  Making exceptions to
>>> that rule just makes the language less internally consistent,  harder to
>>> learn, and more complex. I don't think we should do it.
>> I agree that consistency is an important consideration, but it can cut
>> many ways.
>> In particular, if there is at least some consensus that we might want
>> to have pattern matching at a later point, then we might want to
>> ensure reasonable consistency between destructuring and pattern
>> matching as well.
> What consistency do you mean by "reasonable"? If the difference between
> destructuring and pattern matching is exactly the irrefutable vs. refutable
> one, then there's no issue with leaving destructuring as proposed and
> implemented in SpiderMonkey, Rhino, and Opera (draft ES6 spec bugs not
> included).

[Sorry for the late reply, I somehow overlooked this.]

Well, I'm pretty sure that destructuring and pattern matching would _both_
end up having refutable as well as irrefutable cases, at least for some
corners. For example, array patterns with rest will probably be refutable
no matter what, because they need 'length'. Moreover, we are already
discussing operators for turning one into the other, e.g. ? or default

If you have all that, using the same syntax for patterns in both
constructs, but then different default behaviour for some of the patterns
(and an opposite set of operators for inverting the default?), I think that
would be very confusing.

More abstractly, destructuring _is_ just one-case pattern matching. I'm not
aware of any language that has both and defines it otherwise. It would just
create unnecessary complexity.

Frankly, I cannot see how that can be achieved with
>> destructuring that is irrefutable by default (except for some corner
>> cases where it isn't, a minor inconsistency on its own).
> Here you use irrefutable to mean something other than what Claus meant.
> Can you define it afresh? Thanks.

Hm, I don't think I used it differently. Or did I misunderstand what Claus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list