fail-fast object destructuring (don't add more slop to sloppy mode)

Brendan Eich brendan at mozilla.com
Sun Jan 6 15:10:24 PST 2013


Kevin Smith wrote:
>
>     I raised this problem-case, so I want to point out that we could
>     take other courses:
>
>     * Reckon that labels are rare and this won't bite, so let it
>     stand, just as
>
>     a = b
>     (c)
>
>     is a hazard today -- and one that bites much more.
>
>     * Don't allow suffix-? to be followed by a newline.
>
>
> Leaving aside ASI for a moment, there are other issues:
>
>     let v = obj?+(0+1+2+3+4+5+6+7+8+9+...+n):null;
>
> We don't know whether this is a conditional expression or not until we 
> get to the ":" an arbitrary distance away from the "?".

Yes, this is a good point if obj? could be an expression on the left of 
binary +. The same problem arises with - / [ and ( of course -- just as 
with lack-of-ASI.

> We might be able to use another cover grammar approach here, but is it 
> worth it?

We'd rather use a lookahead restriction forbidding the token after ? 
from being in {+,-,/,[,(} -- and possibly from being a LineTerminator, 
although that seems silly to me on reflection.

>
>     Apart from deviating from the cowpath (CoffeeScript), prefix-? is
>     equivalent to suffix-? as I argued in reply to Herby. We'd want to
>     support
>
>       let ?{p: v} = o;
>       let v = ?o.p;
>
>     to handle the case of undefined or null 'o', of course, in which
>     case v would be initialized to undefined.
>
>
> Would we?  This is something a little different than "irrefutable 
> property get".  Thinking...

The suffix-? operator works on identifier expressions too. Those happen 
to irrefutably throw just fine (throw ReferenceError) in JS, unlike 
MemberExpressions such as foo.bar where !('bar' in foo).

/be


More information about the es-discuss mailing list