<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
