Maybe this analogue to the `for (const ... of ...)`:
```js
function keyList(map) {
const list = new Array(map.size)
const iter = map.keys()
while (const {done, value} = iter.next(); !done) {
list.push(value)
}
return list
}
```
But in general, the more I've thought about it, the more I've noticed
it doesn't generalize well past the C-style `for` loop and I find
myself getting ready to reinvent an awkward minor variant of it
repeatedly. And without anything to the tune of pattern matching
(which Rust has) or a `loop`/`recur`-like `while`-ish loop (which is
what Clojure uses instead), it just seems pointless.
-----
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 Mon, Mar 26, 2018 at 2:33 AM, Naveen Chawla <[email protected]> wrote:
> I don't get it. Please give an example of the per-iteration initialization
> in the while loop... (the for-loop version before `;` does it before
> iteration, not per-iteration)
>
> On Mon, 26 Mar 2018 at 07:20 Isiah Meadows <[email protected]> wrote:
>>
>> As a counterpoint, Rust and Swift are the opposite: it's only defined
>> in the consequent branch, not the alternate. So it could go both ways.
>>
>> But if a value is useful in both branches, I'd prefer to just define
>> the variable in a separate statement, to clarify that it's useful in
>> both branches (explicit > implicit). To take your example, I'd prefer
>> instead to do this:
>>
>> ```js
>> let foo = getFoo()
>>
>> if (foo.isReady()) {
>> foo.start()
>> } else {
>> foo.wait()
>> }
>> ```
>> -----
>>
>> 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 Sun, Mar 25, 2018 at 5:42 AM, Maël Nison <[email protected]> wrote:
>> > C++ defines it as being available in both branches, I think we try to
>> > share
>> > the same behavior. Keep in mind that it will useful when the check is on
>> > something different than existence :
>> >
>> > if (let foo = getFoo() ; foo.isReady())
>> > foo.start();
>> > else
>> > foo.wait();
>> >
>> > On Wed, Mar 21, 2018, 10:27 PM Isiah Meadows <[email protected]>
>> > wrote:
>> >>
>> >> My implication was that it'd only be available in the `if` (if
>> >> declared with `let`/`const`).
>> >> -----
>> >>
>> >> 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 Wed, Mar 21, 2018 at 6:25 PM, Sebastian Malton
>> >> <[email protected]>
>> >> wrote:
>> >> > Sorry if I missed a message but would such an initialization be only
>> >> > available in the first `if` block or also in the subsequent `else if`
>> >> > and
>> >> > `else` blocks?
>> >> >
>> >> > Sebastian Malton
>> >> >
>> >> >
>> >> > Original Message
>> >> > From: [email protected]
>> >> > Sent: March 21, 2018 6:18 PM
>> >> > To: [email protected]
>> >> > Cc: [email protected]; [email protected]
>> >> > Subject: Re: Proposal: if variable initialization
>> >> >
>> >> > I'm personally very much *for* this `if (var ...; cond) { ... }`
>> >> > syntax. I couldn't tell you how many times I would've liked something
>> >> > to that effect, since that's probably one of my biggest areas of
>> >> > boilerplate.
>> >> >
>> >> > I would also be in favor of `if (var ...) { ... }` as a shorthand
>> >> > that
>> >> > guards `!= null` the expression result (pre-match), since that's
>> >> > about
>> >> > 90% of my use cases for it. There *is* a potential area of ambiguity
>> >> > in sloppy for `if ( let [ x ] = y )`, since that would be currently
>> >> > parsed as `var tmp = y; let[x] = tmp; if (tmp) { ... }`, but I doubt
>> >> > breaking that would be of much web compat risk. (A similar ambiguity
>> >> > existed with `for (let [`, but that break didn't cause many issues.)
>> >> > -----
>> >> >
>> >> > 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 Wed, Mar 21, 2018 at 2:47 PM, Mike Samuel <[email protected]>
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
