Is the binding visible in the `else`?

[bakkot]

Moving from #2.

Consider

if (const a = Math.random() < .5) {
  console.log(a); // definitely works
  console.log(b); // definitely throws
} else if (const b = Math.random() < .5) {
  console.log(a); // works?
  console.log(b); // definitely works
} else {
  console.log(a); // works?
  console.log(b); // works?
}

What should the three works? lines do?

---

For background, in C++,

#include <iostream>
using namespace std;

int main() {
	if (bool a = false) {
		cout << a << endl;
	} else if (bool b = false) {
		cout << a << endl;
		cout << b << endl;
	} else {
		cout << a << endl;
		cout << b << endl;
	}
	return 0;
}

is a legal program.

[dcrousso]

From the last line of the Overview:

... and the variable would only be visible inside the if/while block.

if (const a = Math.random() < 0.5) {
    console.log(a); // works
    console.log(b); // throws
} else if (const b = Math.random() < 0.5) {
    console.log(a); // throws
    console.log(b); // works
} else {
    console.log(a); // throws
    console.log(b); // throws
}

As mentioned in #2, this is what makes sense to me, but I could be convinced otherwise. I don't feel particularly strongly either way, other than that it seems weird to have a variable be visible across multiple { ... }.

[bakkot]

other than that it seems weird to have a variable be visible across multiple { ... }

That's the normal behavior of variables: a variable declared in some outer scope is visible to all nested scopes, not just the immediately following one.

[ljharb]

I don’t believe almost anybody considers an else or an else if as a nested scope.

[dcrousso]

Although this isn't "technically" correct, when I see something like:

if (let data = foo.data) {
    ...
}

I think that data is actually "part" of the { ... }, not outside it. If I declared data outside of the if ( ... ), then yes, it would be visible in both { ... }, but declaring it inside the if ( ... ) makes my mind see it differently.

I don't consider the else (or else if) to be nested inside the if. I see it as a completely different scope that's only related because it's easier to write else than another if with an inverse condition.

I realize that others may see that differently, however, which is why I'm open to alternative ideas, but I'd like a good reason for making it visible inside the else other than "that's how C++ does it".

To be clear, this is not meant as a criticism of you or your ideas, but just how I'm approaching this particular idea.

[hax]

I think that data is actually "part" of the { ... }

if without {} :

if (let data = foo.data) process(data)
else console.log(`data is falsy: ${data}`)

And as future work

if (let x = 1, y = 2; x || y) {
    /* ... */
}

it's likely there will be cases programmers want to access x or y in else clause.

But If we really make x visible in else,

let x = ...
if (let x = foo.data) {
  ...
} else if (let x = bar.data) {
  ...
} else {
  console.log(x) // a little bit confusion, I guess some will expect outer x
}

Another point is we'd better coordinate with try (let x = ...) {} catch {} finally {} which currently seems do not allow x be visible in catch/finally clauses.

[waldemarhorwat]

Not extending the scope to the else clause would be highly problematic for a couple reasons:

• Incompability with desirable future extensions such as if (let x = foo(); bar(x)) { ... } else {console.log(x)}
• Gratuituous subtle divergence from C++, making it hard to remember which one is which

Note that C++17 includes both forms if (Foo x = ...) and if (Foo x = ...; condition) and extends the scope to both the then and else clauses.

[hax]

@waldemarhorwat I think python has issues of for...else feature (https://mail.python.org/pipermail/python-ideas/2009-October/006155.html) and I very doubt it could be success in JS. And I don't think C++ consistency should have very high priority.

But if I'm forced to choose one side, i will support extending the scope!

[michaelficarra]

There's no way this feature pays for itself if the scope includes both consequent and alternate.

if (let a = b()) {
  // ...
} else {
  // ...
}

as sugar for

{
  let a = b();
  if (a) {
    // ...
  } else {
    // ...
  }
}

is not a big win for the added language complexity. And limiting the scope to just the consequent brings with it other problems, including the divergence from C++ and confusion with "through" references (references that would have been shadowed if the scope included the alternate). I'd like to stress that I consider myself to be squarely in the target demographic for this proposal, as I am always trying to minimise the scope of my variables, my try/catch statements, etc when writing JavaScript.

[ljharb]

Adherence to C++ is irrelevant unless you're a C++ programmer; if there's good reasons to diverge, we should do so.

[michaelficarra]

@ljharb Of course, that is good general practice, but we should not ignore that the proposal was presented as essentially "I am a C++ programmer and I found it surprising that JS does not have this feature". Implied in that is that the feature should be familiar for C++ programmers. It's not fatal if it fails that requirement.

[rkirsling]

Moreover, alignment with C++ here equates to divergence from Rust, Swift, etc.

I write C++ for my job and make use of this construct, but I'm shocked to learn that it does diverge from modern languages on this point. 😳 (A coworker pointed out that it could be useful when dealing with C-style return codes; this makes sense for C++, but I don't think this applies much elsewhere...)

I strongly agree with @michaelficarra that this feature doesn't pay for itself if it's just if-in-a-block.

[dcrousso]

From @michaelficarra's comment:

@ljharb Of course, that is good general practice, but we should not ignore that the proposal was presented as essentially "I am a C++ programmer and I found it surprising that JS does not have this feature". Implied in that is that the feature should be familiar for C++ programmers. It's not fatal if it fails that requirement.

I apologize if that was how I portrayed it. It's not my intention to make this identical to C++. In fact, I didn't realize that C++ makes the variable visible in the else until recently, and I personally have yet to find that useful at all. That is one of the reasons why I initially proposed not doing this for JavaScript (variable is only visible inside if).

[Mouvedia]

What should the three works? lines do?

1. throws
2. throws
3. throws