Proposal: anaphoric if and while syntax

Caitlin Potter caitpotter88 at gmail.com
Wed Sep 14 22:52:00 UTC 2016


Given that `let x == 10` or `let x === 10` is illegal, it doesn’t seem too bad to allow `if (let x = f(y))`, LexicalDeclaration is visually distinct from EqualityExpression because of the `let` or `const` prefix.


> On Sep 14, 2016, at 6:41 PM, Jordan Harband <ljharb at gmail.com> wrote:
> 
> While I like the idea of making it simpler to restrict the scope of variables, currently a reigning best practice is to never do assignment in conditionals, since it can be an easy typo from `==` or `===`, and because it conflates assignment with expression truthiness, harming readability.
> 
> This seems like it runs afoul of the latter, certainly, and I haven't yet convinced myself whether it creates typo hazards (I'm thinking no, but wanted to bring it up just in case).

Given that `let x == 10` or `let x === 10` is illegal, it doesn’t seem too bad to allow `if (let x = f(y))`, LexicalDeclaration is visually distinct from EqualityExpression because of the `let` or `const` prefix.

> 
> On Wed, Sep 14, 2016 at 3:14 AM, Danielle McLean <gopsychonauts at gmail.com <mailto:gopsychonauts at gmail.com>> wrote:
> On 14 September 2016 at 17:58:24, Viktor Kronvall
> (viktor.kronvall at gmail.com <mailto:viktor.kronvall at gmail.com>(mailto:viktor.kronvall at gmail.com <mailto:viktor.kronvall at gmail.com>)) wrote:
> 
> > Does this really need new semantic interpretation of the syntax? Using the `Array.prototype` methods `.forEach` and `.map` already mitigates this problem as far as I can tell by having a different bound variable (argument in this case) for each call.
> >
> > I agree that the behavior may be non-intuitive if you have a background coming from Java or C++ but the implications would be quite far-reaching and the backward compatibility with previous versions would be difficult to handle. Wouldn't this require a new 'use strict'-like mode?
> 
> No, adding anaphoric if as I have described it will require neither
> new semantic interpretation of the syntax nor a new strictness
> directive. Currently, it is a syntax error to write a variable
> declaration within an `if` or `while` condition, so there is no valid
> code which contains the proposed syntax.
> 
> Also note that under this proposal, declarations made using the `var`
> keyword would still be hoisted to function scope, *not* scoped to the
> body associated with the condition - i.e., there would be no semantic
> difference whatsoever between the following two snippets:
> 
>     if (var stuff = some.cool(expression)) doThings(stuff);
>     // equivalent to
>     var stuff;
>     if (stuff = some.cool(expression)) doThings(stuff);
> 
> Only declarations made with the newer `let` and `const` keywords,
> which are never hoisted to function scope anyway, would be narrowly
> scoped to the condition and its body.
> 
>     if (let stuff = expr) doThings(stuff);
>     // equivalent to
>     {
>       let stuff = expr;
>       if (stuff) doThings(stuff);
>     }
> 
> (An aside: as the last example demonstrates, the `if` or `while`
> statement body should not need braces to isolate the scope in this
> way. This is consistent with the current behaviour for declarations in
> loops.)
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160914/16b12ad3/attachment-0011.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160914/16b12ad3/attachment-0011.sig>


More information about the es-discuss mailing list