Not just let-scopes, but the introduction of `async/await` also
welcomes the introduction of if-scoped variables.
if (const data = await collection.find({}).toArray(); data.length > 10)
{
console.log(data);
} else if (data.length > 0) {
console.log(data);
} else {
console.log(data);
}
And, as mentioned by @jerry, this can be extended to `switch` and
`while`. Golang has `switch(;)` initialization too afaik.
switch( const today = new Date(); today.getDay() ) {
case 0:
console.log( "Don't work on %s", today.toString() );
break;
}
`while` would be a bit unnecessary, due to the fact that it can be
replicated with `for( <assign>; <expression>; )`, but could be
available for consistency with `if` and `switch`.
El mié., 21 mar. 2018 19:47, Mike Samuel <mikesam...@gmail.com> escribió:
>
>
> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton <sebast...@malton.name>
> wrote:
>
>> Because block-level scoping is a very good way to avoid certain bugs and
>> is easier to reason about. Especially when considering project successors.
>>
>
> +1. function-scoped variables in loop bodies caused tons of bugs before
> let-scoped variables and were a main motivating case.
>
> var i;
> for (i = 0; i < arr.length; ++i) {
> f(function () { /* Do something with */ arr[i]; });
> }
>
> vs
>
> for (let i = 0; i < arr.length; ++i) {
> f(function () { /* Do something with */ arr[i]; });
> }
>
> Yes, linters got pretty good at finding uses of closed-over variables
> modified in a loop, but the workarounds were not ideal.
>
> var i;
> for (i = 0; i < arr.length; ++i) {
> f(function (i) { return function () { /* Do something with */ arr[i]; }
> }(i));
> }
>
> Block scoping is just better for code that uses loops, variables, and
> function expressions.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
