Refutable destructuring

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Aug 16 08:59:41 PDT 2013


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.

Allen

 


More information about the es-discuss mailing list