Declarations in conditionals: scoping

[LeaVerou]

If declarations in conditionals were possible (@tc39 proposal being discussed right now!) what would you expect this to log?

let foo = 1;
if (let foo = 0) { console.log(foo) }
else { console.log(foo) }

[rektide]

explaining my vote

I voted: 0.

• Preliminary: shadowing let's is already a thing, so I feel like 0 or 1 are the only valid options:

(function ok(){ let foo = 1 ; if (true) { let foo = 0; console.log(foo) } })() //=> 0

• So it comes down to whether the declaration is available in one or both branches of the conditional.
• Honestly I had a bit of a hard time voting 0.
  • The else "feels" very far away.
  • It feels a little non-obvious, is not something I would feel confident assuming at first glance (if I ran into this for the first time in the wild and didn't know).
• But logically: the conditional sits "above" both branches. Not just one of them.
• And it's a far better outcome to have access to a declaration-in-conditional in both branches of the conditional.
  • Not being able to access the variable set up by the branch in half of the directions for the branch would be... most unfortunate.
  • Setting up a database connection or something in the conditional then not being able to access it in the else would be so sad.
• I'm still worried 1 is going to win this, as it just feels like the else is visually so far away from the conditional. But 🤞. Let's go 0.

[alexanderson1993]

I can see it going either D (the conditional declaration is in the same scope as the original declaration) or B (the conditional declaration is in a new scope shared with the conditional body)

Based on the behavior of for loops, I'd expect it to be B.

let a = 0;
for (let a of list) {
  console.log(a)
}

[LeaVerou]

Links:

• Bluesky post
• Twitter poll
• Mastodon poll
• Proposal

[hax]

I may not be the right person to poll on this, since as a TC39 delegate, I've been involved in discussions about this proposal for a long time. But this survey might just prove my concern—the semantics of if (let x = expr) are unclear, whereas if (let x = expr; cond) is actually easier to reason about (based on experience with for (let x = expr; cond;)).

[ziadkh0]

While if (let x = expr; cond) could be more useful, I found it intuitive that if (let x = expr) behaves like if (x = expr) with an extra scope.

And looking at the results so far (here and on Mastodon), the unclear part seams related to the new scope's boundary, not the implied condition.

[ziadkh0]

Seeing this comment on Bluesky:

B) 0

The result of a declaration should be true if successful

Made me start to understand what could be unclear about if (let x = expr) with respect to the implied condition (event though I see no point in it always returning true).

[hax]

If u have experience on Swift/Rust you might expect if (let x = expr) have slight different semantic. Another cases are if (using x = expr) and if (let Extract(x) = expr) if u familiar with explicit resource management proposal and extractor proposal. In both cases, people might expecting something more like matching semantic instead of checking truthy semantic.

[ziadkh0]

explaining my vote

I voted 1 as I see it as the only reasonable way this would be useful (but I could still be convinced otherwise).

As others mentioned, if (let foo = 0) {...} looks like for (let foo = 0; ...) {...} which instinctively implied a new scope with two possibilities for its boundary:

1. The if branch only
2. The whole if ... else statement

While there's currently no easy way to do 1. without declarations in conditionals, 2. can easily (and I would argue more clearly) be achieved with an explicit scope:

let foo = 1;
{
  let foo = 0;
  if (foo) { console.log(foo) }
  else { console.log(foo) }
}

So I intuitively expected it to match 1. (i.e., printing the outer foo).

[kirk-loretz-fsn]

I think the question needs further refinement. From the comments, some people think it would log 0 in the if branch because let foo = 0 is truthy, rather than 0 in the else branch because let foo = 0 is also scoped to the else branch. I did not expect that truthy interpretation at all.

I voted for 1: let foo = 0 is scoped only to the if branch and falsy, so we execute the else branch. (Though I had watched this video discussing it.)

[atdiar]

should throw.
Anything else is a source of bugs.
Don't do that.

Also no shadowing. (but the example doesn't make clear that this is the only issue)

[olaf-k]

voted 0 based on these assumptions:

if (let foo = 0)

is shorthand for

let foo = 0
if (foo)

making the value of a declaration is the same as an assignment's.

in the example: 0 is falsy → else block runs.

2. the scope of an if covers all branches. obviously debatable and I can understand people preferring a block approach. such an approach would, however, mean that the value of the variable used to determine which branch to run might not be the value of said variable in the chosen branch.

in the example: foo exists in the else branch and was assigned 0 so we log that.

[romainmenke]

Coming from Go I would expect 0.

See: https://go.dev/play/p/rm29RcLiD3X

[atdiar]

In go, the corresponding js code does not exist, it can't compile.

if requires an expression, the js code has a statement not an expression.

Go does allow for variable shadowing but this is a common regret of people including the initial designers because error prone.

[romainmenke]

Sure.

But I am explaining where my mental model comes from.
Not implying that JS and Go are the same or should be the same.

By my mental model the if condition is false while the foo is available in the else block with the value assigned in the if condition.

[atdiar]

Oh yeah I got you, don't worry. It was more for other people to not think that these were the same. Even the javascript code is unclear. One could also think that it is invalid syntax or that if it takes the else branch it should return 1.

[chriskirknielsen]

I expect the if (let foo) value to be scoped to that if, so the else would receive the value from the outer scope, hence voting for 1.

I am curious about the behaviour for else if here…

The use case I would see for this kind of feature only becomes (ever so slightly) beneficial, for me, in an else if chain. For example in a global click event handler to handle different targets. Currently, I would do let target; if (target = ...) { ... } else if (target = ...) { ... } and so on, with this proposal I would imagine it like this:

document.addEventListener('click', function(event) {
	if (const target = event.target.closest('a')) {
		console.log(target.href)
	} else if (const target = event.target.closest('button')) {
		console.log(target.type);
	} else if (const target = event.target.closest('input, textarea, select')) {
		console.log(target.tagName.toLowerCase());
	} else {
		console.warn('Non-interactive element:', event.target);
	}
})

Or let's say we start with a basic bit of code expecting a number, but then another developer adds an else if that returns null:

if (const linkData = document.querySelectorAll('a').length) { /* Returns a number */ }
// Another developer adds this line below
else if (const linkData = document.head.querySelector('meta[property="twitter:image"]')) { /* Returns a DOM element or null */ }
// ^^^^^^^^^^^^^^
else { showLinkCount(linkData.toString()); }
// (0).toString() was the expected thing, but now null.toString() is possible and throws

I know it's up to developers to write correct code (and this example, well, stinks), but this feels like an easy way to get confused when expecting a value in the else block.

And then, what happens with different variable names in each if/else if? Are they all exposed to the final else? (if{} else if{} else{} is conceptually if {} else { if{} else{} } so I could see an argument for it to "cascade" every value)

This all feels pretty confusing, and kinda magic as it's jumping scopes. If you want that behaviour, the "old" way of let myvar; if (myvar = ...) {/*...*/} else { console.log(myvar); } seems like the best way to go. No magic, nothing unexpected.

PS: falsy values are pretty easy to handle, so in my stinky example (linkData || 0).toString() would solve it but that's not the point I'm trying to make.