barrett ✨ · Dec 15

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

genderless lego overalls person · Dec 16

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

Steven ⬢ · Dec 16

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?

Mastro.{js,ts} · Dec 15

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

Philipp Dunkel · Dec 15

I think there are 2 issues: 1. The way to use the value. It should be a simple generic “expression declaration so `if ((const result=/…/.exec(x))?.valid) {`

Gil Tayar · Dec 19

I think most developers would be _surprised_ to know that it's scoped to the else too. Yes, thinking about it a bit more, they would agree that it _has its uses_, but they'd still be surprised and lean toward it not being scoped to the else. The majority of the answers here be like that.

Amos Manneschmidt · Dec 15

I don't know that it shouldn't be available in the else block. In that specific example I can't imagine one would often be using `resource` in the else block but what if it went into a few `else if()` blocks first? I could imagine a need for `resource` to still be around in an `else if()` block.

Tom Hicks · Dec 15

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.

@varg-k.bsky.social · Dec 16

It should not be available in the else block.

finxol · Dec 15

I’d initially say it should be scoped to the else block too, because if the custom truthy-ness is false, the rest of the object might contain an error message which could be useful. But then I suppose for that use case, sticking to the current syntax makes more sense.

Patrick O'Brien · Dec 15

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.

Ashley Claymore · Dec 15

Great explanation! The other choice is: if it isn't available in the else, can you still refer to that identifier from a parent scope? My opinion: not available in the else, and referring to the identifier is a syntax error so there can be no ambiguity for the reader.

Tab Atkins-Bittner · Dec 16

Oh I missed the last meeting so I didn't realize it had been discussed! Goddam I need to get back on the pattern matching proposal, it would be a real shame to have this advance with a totally different syntax.

romainmenke · Dec 15

Is there a text version or link?

Sámal Rasmussen · Dec 16

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

Tobias Wittwer · Dec 16

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.

Slime · Dec 16

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