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
