fail-fast object destructuring

Brendan Eich brendan at
Tue Jun 26 10:12:51 PDT 2012

Claus Reinke wrote:
> Ultimately, I'd like to have both:
> - irrefutable matching:
>    here, the two phrases above are equivalent, as in the
>    destructuring proposal
> - refutable matching:
>    here, the latter phrase would fail, ideally in a way that
>    can be recovered from efficiently, to guard against interface
>    mismatches and to implement pattern matching with fall    through, 
> as in the pattern_matching strawman "switch/match"
> One is a syntactic convenience for selection only, the other
> for selection plus structural tests (actually: behavioral interface
> tests, see below). Both have their uses.


Also don't get your hopes up for structural as in record types. We can't 
future-proof against all futures, but we have a dual form to object and 
array literals in ES6: destructuring. This means making some choices, 
now, even if in the future we *add* new forms that make other choices.

> This suggests having pattern syntax modifiers for indicating refutable 
> or irrefutable matching, and deciding which of the two is likely to be 
> more common (and thus to be the default for patterns without modifiers). 

If there's a modifier-free default, then there's not much case for an 
explicit modifier. The only future-proofing is to allow a new syntactic 
form to use a destructuring pattern to do a refutable match. That's what 
Dave's proposal:

was about, but it didn't make ES6 for want of time to fully bake. Still, 
apart from the catch clause issue, it uses new syntax to imply 
"refutable, not the default".

So I don't think we need two modifiers, and from the duality of 
object/array literals and destructuring, it seems to me that 
destructuring must be irrefutable in the sense you give: the equivalence 

let myFoo = {a:0,b:1}.foo;


let {foo: myFoo} = {a:0,b:1};


More information about the es-discuss mailing list