fail-fast object destructuring

Brendan Eich brendan at
Mon Jul 9 13:04:22 PDT 2012

Russell Leggett wrote:
> Options type objects:
>     let {url,callback,?errback} = options;
> This lets you very clearly decompose an object and declaratively show 
> which values are optional and which ones are not. If all of them are 
> optional, the ? would just go to the left of the brace, but really 
> this should be the minority case for most situations.

Dave and I had talked about prefix-? as applying only to property names, 
since that covers all but the top level for object patterns:

   {required, ?optional_shallow}
   {required, ?optional_deep: {foo, bar, ?baz}}

but of course it leaves out the top level.

If we make prefix-? apply to the "value" side of the ":" (which in 
object patterns is optional, but if present names the binding not the 
property), then we have

   {required, optional_shallow: ?renamed_optional_shallow}
   {required, optional_deep: ?{foo, bar, ?baz}}

and the object shorthand would still be wanted:

   {required, ?optional_shallow}

This is a strictly larger grammar, though. If we can keep prefix-? in 
the property name side, then all we lose is the top level.

Array patterns don't have explicit "0", "1", "2", etc., property names, 
though so either prefix-? doesn't work, or you have to use an object 
pattern (which works on array values), or else prefix-? goes before the 
binding name (the "value" side) as above.

> A disparate list of possible types of matches. This is common in 
> "overloaded" functions where the number and type of arguments can be 
> wildly different. This is probably the strongest case against 
> refutable matching, because it is so likely to result in mismatches 
> which should have logic performed on them instead of having an error 
> thrown.

Right, this minority case could be left out. The array pattern situation 
is stronger motivation for prefix-? applying to bindings not property names.


More information about the es-discuss mailing list