fail-fast object destructuring

Russell Leggett russell.leggett at
Mon Jul 9 11:23:40 PDT 2012

> On Mon, Jul 9, 2012 at 12:36 PM, Andreas Rossberg <rossberg at>wrote:
>>> I agree with almost everything you said. But just to clarify, I think
>>> you actually meant "refutable" everywhere you said "irrefutable".
>>> /Andreas
>>> So I corrected my bonehead mistake, here it is again in case anybody
wanted to more cleanly respond to specific points.


I would love to see 2/B. A lot of that is likely because I would love to
see pattern matching, though, I'll admit. I think that the ? on refutable
portions of the pattern would work well with the new default and
existential operators, while I think ! will not have a good analog. If I
were to throw out another reason based on destructuring assignment alone,
and not pattern matching later, I would say that if parts of the
destructuring are likely to fail, it would be better to know upfront. If
there are optional fields, ? clearly expresses that. If there are wildly
unknown structures, destructured assignment is probably not the best
approach, or at least there should be some structural testing upfront
(pattern matching would of course be ideal).

As for usability testing, while it obviously is not done refutably in
spidermonkey now, I think we can at least look to other languages. Looking
over several languages, all of the ones I have seen are refutable. Some are
strongly typed languages, but not all. Python does not have complete
patterns, it can basically just destructure list, but even it requires that
the number of elements be correct. Erlang, OCaml, and F# all allow full
pattern assignments, and they will all throw errors if not correctly
matched. Obviously, it is a little different than what it would be in ES,
they have full on patterns not just destructuring, but it would clearly be
all the more consistent when patterns *hopefully* get added. I know that JS
users have come to expect a certain amount of carefree imputing, but
destructuring is new (outside of FF), and I think it is certainly an area
which has options. I haven't exactly done a formal survey of languages, but
from what I've seen JS would be the first to be so lenient. Allowing ? in
portions of a pattern, I actually think would be the perfect compromise.
People who write very loose code will either have to put ?s on their
patterns or keep working the same way they have been, but if there isn't a
reasonable amount of checking by default, I think we're going to be seeing
some more WATs in presentations. JS gets picked on for how much coercion
and silent errors it will chug along with. Best practices of always using
=== and avoiding 'with' are just a couple of examples.

Finally, I would like to take the approach of looking at the best way to
handle the different use cases.
Really simple destructuring with expected results:
    let {x,y} = getPoint();
In my opinion, this should throw if x or y are not available. It is
unlikely that the coder is checking properties here, they are just going to
call other functions passing through x or y. It would probably be better to
get the error as soon as possible. Much easier to debug that way. In many
cases, I think these types of destructuring assignments will lead to
effortless checking that would previously have been missed because of the
extra effort to add those checks in as if statements.
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.
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. However, it is also
the strongest case for pattern matching. There is nothing wrong with
wanting to accept differently shaped things, but right now there is not
really a great facility for acting on them. Pattern matching would be
ideal. I think it would be such a powerful addition to the language as it
is used right now, that it honestly pains me that we would cut out the
possibility. I would love to see patterns now, but I can understand
waiting. Making a decision which would close it off though would be
extremely disappointing.
I know that full blown patterns are out of scope (though I'm hoping maybe
this discussion might change that), but even if we can't have it now, I
think refutable destructuring would really make people see the potential.
Even if no facility was provided for it, a hypothetical match function
could be created which would take function and execute them in sequence in
a try catch until one did not fail. I think we can do better than that and
should probably try if we go with refutable destructuring, but just knowing
it would be possible for the community to take it and run with it is nice.

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

More information about the es-discuss mailing list