Post

I don't think it should be exposed in the `else` block. That setup creates opportunities to misuse the `null` value, which is what we're trying to avoid! 😅 I think JS should stabilize features that accentuate correctness instead of comfort -- there are already too many ways to mess this up lol

as always lisp solved this problem 60 years ago with let blocks

Seems like the variable should be scoped to the if only, not the else. Devs that want to use the variable in the else statement can hoist the variable up, right?

If C and Go do it one way, and Rust and Swift the other.... I'd say that's a strong signal :P

But that’s just my personal weakly held opinion strongly expressed.

oh this is cursed I like it

Also, there is _no way_ to have a variable that is scoped to only the `if`, whereas there is a way to have a variable that is scoped to both if and else. So I would go with scoping only to the if also because of this - it's the only way to do it!

That said, I think if had to guess the behavior without looking at documentation I would guess that it's still available in the `else` so that's slightly more natural seeming to me...but I wouldn't be frustrated to learn it wasn't and the rust way would bias towards less resource usage.

If we go with "visible in else" it's actually pretty hard to get disposal to happen before the else! Try rewriting this without relying on "dispose before else": if (using resource = getResource(); resource.needsUpdate) { resource.update(); } else { await postMessage('no updates required'); }

It shouldn’t be in the else block be cause “else if” exists (I know it’s just an inline else followed by a blocky if). No one would expect it to be available in the else if I don’t think. Therefore it shouldn’t be in the else.

It should not be available in the else block.

I’m not 100% sold on my opinion here. Without the custom check, I’d immediately say scope to `if` block only because you most likely wouldn’t do anything with a falsy value. So yeah, sticking to the new rust behaviour of else being out of scope is probably what i’d say is better

My original thought was this was scope-blocked to the if until you stated the question. This feels more consistent with scope blocking elsewhere, so my two cents is it should not be made available. If you need the var accessible elsewhere (pun not intended), the current syntax today is clear.

You're right that there isn't AFAIK an early syntax error for a bad reference, only invalid declarations. This came up in yesterday's TC39 meeting, it will need more research to see if this could even be implemented efficiently

If you’re interested in help on that from someone who doesn’t work on a browser or JS runtime, 👋 I’d love to help!

The proposal is at github.com/tc39/proposa.... We plan to do text equivalents for these videos in future, but need to plan some stuff first.

What's the point of even adding this if it's available in the else block? The existing pattern already does that.

Based on the current scoping of variables I would prefer to make it only in the if available. If it's needed in the else the variable should be defined outside the if like currently. The stated problem with the resource reinforces my opinion in this regard.

I really don’t like shoving multiple expressions into the if like that… there has to be a better way right?