I agree, the `switch` statement was not on my radar and I don't see that need, it's the scoped `if` constructs that would make code cleaner.
On Thu, Mar 22, 2018 at 8:50 AM, Isiah Meadows <[email protected]> wrote: > <concern> > I get the nagging feeling someone is eventually going to complain that > this feature is unnecessary and smells too much like `let` blocks: > > - Relevant thread: https://esdiscuss.org/topic/revive-let-blocks > - How it ended: > https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks > </concern> > > It seems odd to extend it to `switch`, especially with an added > condition like that. It seems odd to do something that's already > easily accomplished with just an extra newline, with hardly any more > typing: > > ```js > const today = new Date() > switch (today.getDay()) { > // ... > } > ``` > > (The `if` examples don't have this same issue, BTW.) > > One statement I'd *like* to see this extended to is `while`, but it's > partially duplicative of the C-style `for` (so it kind of feels wrong > to add in a way). Also, it doesn't make sense to add for `do { ... } > while (...)`, since the condition is after the block. So it seems this > only really makes sense for `if`. > > 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`. > > > ----- > > 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
