On Thu, Mar 22, 2018 at 3:50 AM, Isiah Meadows <[email protected]>
wrote:
>
> I do have one other related thing I'd like to see: add a `let foo =
> expr() else { ... }` variant, with a line terminator restriction
> before the `else` so it can't be confused with an `else` within an
> `if`.
>
Making it a restricted production would solve the grammatical ambiguity
for existing code, but maybe in an errorprone way for future code:
if (c) let foo = expr() else { ... } // else attaches to let
if (c) let foo = expr(); else { ... } // else attaches to if
Would the semantics differ from
let foo = expr() || ({} => { ... })()
?
>
> -----
>
> Isiah Meadows
> [email protected]
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Thu, Mar 22, 2018 at 3:21 AM, Rodrigo <[email protected]> wrote:
> > 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 <[email protected]>
> escribió:
> >>
> >>
> >>
> >> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton <
> [email protected]>
> >> 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
> >> [email protected]
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [email protected]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
