fail-fast object destructuring

Russell Leggett russell.leggett at
Tue Jul 10 01:17:56 PDT 2012

On Mon, Jul 9, 2012 at 4:04 PM, Brendan Eich <brendan at> wrote:

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

This makes a lot of sense. It is certainly smaller. I do worry, though,
that it might fall short for the people that would like irrefutable
destructuring. I had imagined that ?{a,b,c} could be used in a case where
all properties would be optional. I did have a question about refutability.
What would happen here?

   let {?a,?b} = null;

Even though both properties are optional, would this still fail? Does the
{} imply some structure? What if we were thinking about actual pattern
matching in the future? Would this just match anything? If we say it should
not match anything, then you would need ?{} to make it fully irrefutable.

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

Yes, I think that arrays are likely the strongest case for ? on bindings.
Something like this would be nice:
    let [first,last,?company] = contact.split(",");

And certainly, if you wanted to be able to destructure a list of arguments,
some of which being  optional, it would be very useful.

Ultimately, while I think I could personally do fine with fewer points of
prefix-?, I can see a few cases for it, especially on arrays. I worry that
without supporting these, refutable by default won't be able to reach

- Russ

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

More information about the es-discuss mailing list