Proposal: anaphoric if and while syntax

Kris Siegel krissiegel at gmail.com
Thu Sep 15 18:26:04 UTC 2016


I agree but at the same time those examples simply look like bad coding
practices to me and we can't completely hide from those. Since it's new
semantics we shouldn't have to worry about it breaking something existing
and it would be really easy to do a transpile back into ES5 or ES6 should
people want to use it ahead of time.

Just my 2 cents. You certainly have valid points. The only awkward thing,
in my opinion, is if we're using let and const we're going to have to allow
var as well (it would be odd that, in a single place, you can use let and
const but not var). Not sure how var should be really handled here;
probably allow it but make it a bad practice to use var in this type of
declaration. In my opinion anyway.

On Thu, Sep 15, 2016 at 11:15 AM, Andy Earnshaw <andyearnshaw at gmail.com>
wrote:

> The main barrier that I can see is that this requires new semantics.  At
> the moment, variable declarations don't have any kind of usable result.  If
> you consider
>
>     let a = eval('let b = 1');
>     console.log(a);
>     //-> undefined
>
> This sounds like an easy thing to solve, but how about this:
>
>     if (let a = foo(), b = bar()) {
>     }
>
> Does the block execute if `a` and `b` are both truthy, or just `b`?  My
> gut instinct says "if bar() is truthy", but it still seems awkward.  Any
> option might be confusing depending on your level of experience.   What
> about this:
>
>     if (let { a, b } = foo) {
>     }
>
> Does the block execute if `a` and `b` are both truthy, just `b`, or if
> `foo` is truthy?  I'd lean towards `foo` in this case, but I think it looks
> pretty bad and I'd hate to see it in code.  It might make more sense to
> throw for destructuring or if there's more than one assignment.
>
> On Tue, 13 Sep 2016 at 01:32 Danielle McLean <gopsychonauts at gmail.com>
> wrote:
>
>> In current ECMAScript, it is legal to place a variable declaration inside
>> the
>> initialiser of a `for` loop, as well as to declare the variable used by a
>> `for...in` or `for...of` loop within the declaring expression:
>>
>>     for (let i = 0; i < 5; ++i) console.log(i);
>>     for (let item of collection) process(item);
>>
>> When this syntax is used with `let` or `const`, the resulting variable is
>> scoped to the loop and is not visible to the rest of the surrounding
>> block.
>>
>> I propose that this syntax be extended, making it legal to place a
>> variable
>> declaration within the condition of an `if` or `while` statement. Any
>> truthy
>> value will cause the `if` block to run or `while` loop to repeat, as
>> usual -
>> the advantage is that the particular truthy value is bound to a variable
>> and
>> can be used inside the conditional block. For example, here is the
>> situation
>> that prompted my writing this proposal:
>>
>>     if (const oldValue = _.get(object, 'some.long.path')) {
>>       object.some.long.path = transform(oldValue);
>>     }
>>
>> As with the existing behaviour of declarations inside `for`, variables
>> declared
>> using `let` or `const` would be scoped to the individual `if` or `while`
>> statement, rather than the containing block. In other words, the above
>> syntax
>> would be equivalent to the following currently-valid form I ended up
>> writing:
>>
>>     {
>>       const oldValue = _.get(object, 'some.long.path');
>>       if (oldValue) object.some.long.path = transform(oldValue);
>>     }
>>
>> Another use case which C aficianados might recognise:
>>
>>     while (const c = getchar()) {
>>         process(c);
>>     }
>>
>> This syntax is already legal in C++, although not in C - in general this
>> support is known as "anaphoric if", as it allows the body of the
>> statement to
>> refer back to the condition value. It's especially helpful in languages
>> with
>> truthiness, which ECMAScript has, as it allows access to the *specific*
>> truthy
>> value without further finagling.
>>
>> Thoughts?
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> 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/20160915/ecda601a/attachment-0004.html>


More information about the es-discuss mailing list