fail-fast object destructuring

[Brendan Eich]

Andreas Rossberg wrote:
> On 25 June 2012 19:23, Allen Wirfs-Brock<allen at wirfs-brock.com>  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).

> 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.

/be

>   The potential
> inconsistency lurking there will likely be much bigger and more
> confusing than the rather smallish issue we are discussing here.
>
> (And that is leaving aside all usability considerations for a moment.)
>
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>