<p>What are the advantages of conditionals having their own scope? I know this can lead to some extra variables for some programs. But it can also be more memory efficient.</p>
<p>Credit to <a href="https://area51.stackexchange.com/users/223107/hg0428">Hg0428</a> for the <a href="https://area51.stackexchange.com/proposals/127456/programming-language-design-and-implementation/127555#127555">idea on A51</a></p>

<control-flow><scoping>
What are the advantages of conditional statements having their own scope?
CC BY-SA 4.0
2023-05-17T21:51:34.727Z
Which part of the conditional are your referring to? `if (part1) { part2 }`
Max Heiber
CC BY-SA 4.0
2023-05-18T12:38:48.337Z
Do you also want the disadvantages as well? [tag:pros-cons] means *both* advantages and disadvantages
SectorCorruptor
CC BY-SA 4.0
2023-05-17T13:22:30.103Z
I recommend you to request for permission first, before putting it on the main site.
justANewbie
<h1>Consistency in how scopes work</h1>
<p>There are two main ways languages handle non-global variable scoping:</p>
<ul>
<li>Function scoping</li>
<li>Local (or block) scoping</li>
</ul>
<p>In function scoping, like JavaScript's <code>var</code>, a variable declared anywhere in a function is accessible anywhere after. In block scoping, a variable can only be accessed in the block it's declared in.</p>
<p>The latter is preferable, as function scoping can easily hide bugs. For example, when multiple <code>for</code>-loops are used in the same function:</p>
<pre><code>for (var x in 0..10) {
    for (var y in 0..10) {
        tick_farmland(x, y);

        if (is_grown(x, y)) {
            print(&quot;Finished growing crop at ({}, {})&quot;, x, y);
        }
    }
}

for (var x = 0; x &lt; 100; y++) {
    print(&quot;{}% loaded...&quot;, x);
}
</code></pre>
<p>Did you catch it? Well, the (interpreter/compiler) didn't. That last loop used <code>y++</code> instead of <code>x++</code> by mistake. Since the scope of <code>x</code> and <code>y</code> from the previous loop escapes the first <code>for</code> loop, <code>y</code> is still <code>9</code> when the second loop runs, and the interpreter/compiler won't see anything wrong. Block scoping would fix this, since <code>y</code> would be undefined outside of the first loop.</p>
<p>For consistency's sake, it's best to handle all blocks the same. If <code>for</code> loops were block-scoped but <code>if</code> statements used their enclosing scope, this would create confusion, and possibly bugs if an <code>if</code> is turned into a <code>for</code> or vice versa.</p>

CC BY-SA 4.0
2023-05-18T14:43:41.643Z
2023-05-18T14:43:41.643Z
rydwolf
CC BY-SA 4.0
2023-05-18T14:45:52.857Z
On the other hand, there have been times that I _want_ to access the index variable later — for example, if the loop exited by `break` and I want to know where.
Bbrk24
CC BY-SA 4.0
2023-05-18T14:53:44.427Z
@Bbrk24 In that case, you could just declare the index variable in a higher scope. That also makes your intentions clearer, aiding readability.
rydwolf
<h1>It invites type errors</h1>
<p>Since an <code>if</code> statement may or may not run, this would mean that a variable declared in an <code>if</code> statement may or may not exist to the code following it. While in a dynamically typed language this could be acceptable, it would still be a likely place for bugs.</p>
<p>Sometimes the variable might not exist at all after the <code>if</code>:</p>
<pre><code>if (condition) {
    var timestamp = now();
}

print(timestamp);
</code></pre>
<p>Sometimes the variable may have a different type:</p>
<pre><code>if (condition) {
    var x = 1;
} else {
    var x = &quot;a&quot;;
}
</code></pre>
<p>The above would likely be rare...intentionally, at least. It would likely start as two branches that set the same variable to two different values of the same type. Until someone updates one branch and forgets about the other, creating a mismatch between what types get returned. A more foolproof way to do this would look like this:</p>
<pre><code>var x: int;

if (condition) {
    x = 1;
} else {
    x = 97;
}
</code></pre>
<p>Importantly, the variable is already outside the scope of the <code>if</code>'s block. That's what makes this safe.</p>

CC BY-SA 4.0
2023-05-18T14:50:59.640Z
2023-05-18T14:50:59.640Z
rydwolf
# What are the advantages of conditional statements having their own scope?
Posted by: username_0 on 2023-05-17
What are the advantages of conditionals having their own scope? I know this can lead to some extra variables for some programs. But it can also be more memory efficient.

Credit to [Hg0428](https://area51.stackexchange.com/users/223107/hg0428) for the [idea on A51](https://area51.stackexchange.com/proposals/127456/programming-language-design-and-implementation/127555#127555)
**Tags:** control-flow scoping
> **Comments:**
> **username_3**: I recommend you to request for permission first, before putting it on the main site.  
> **username_1**: Which part of the conditional are your referring to? `if (part1) { part2 }`  
> **username_2**: Do you also want the disadvantages as well? [tag:pros-cons] means *both* advantages and disadvantages  
---
## 2 answers
### Answer by username_4 on 2023-05-18. Score: 3
Consistency in how scopes work
There are two main ways languages handle non-global variable scoping:

Function scoping
Local (or block) scoping

In function scoping, like JavaScript's var, a variable declared anywhere in a function is accessible anywhere after. In block scoping, a variable can only be accessed in the block it's declared in.
The latter is preferable, as function scoping can easily hide bugs. For example, when multiple for-loops are used in the same function:
for (var x in 0..10) {
    for (var y in 0..10) {
        tick_farmland(x, y);

        if (is_grown(x, y)) {
            print("Finished growing crop at ({}, {})", x, y);
        }
    }
}

for (var x = 0; x < 100; y++) {
    print("{}% loaded...", x);
}

Did you catch it? Well, the (interpreter/compiler) didn't. That last loop used y++ instead of x++ by mistake. Since the scope of x and y from the previous loop escapes the first for loop, y is still 9 when the second loop runs, and the interpreter/compiler won't see anything wrong. Block scoping would fix this, since y would be undefined outside of the first loop.
For consistency's sake, it's best to handle all blocks the same. If for loops were block-scoped but if statements used their enclosing scope, this would create confusion, and possibly bugs if an if is turned into a for or vice versa.
> **Comments:**
> **username_5** (2023-05-18): On the other hand, there have been times that I _want_ to access the index variable later — for example, if the loop exited by `break` and I want to know where.  
> **username_4** (2023-05-18): @Bbrk24 In that case, you could just declare the index variable in a higher scope. That also makes your intentions clearer, aiding readability.  
---
### Answer by username_4 on 2023-05-18. Score: 2
It invites type errors
Since an if statement may or may not run, this would mean that a variable declared in an if statement may or may not exist to the code following it. While in a dynamically typed language this could be acceptable, it would still be a likely place for bugs.
Sometimes the variable might not exist at all after the if:
if (condition) {
    var timestamp = now();
}

print(timestamp);

Sometimes the variable may have a different type:
if (condition) {
    var x = 1;
} else {
    var x = "a";
}

The above would likely be rare...intentionally, at least. It would likely start as two branches that set the same variable to two different values of the same type. Until someone updates one branch and forgets about the other, creating a mismatch between what types get returned. A more foolproof way to do this would look like this:
var x: int;

if (condition) {
    x = 1;
} else {
    x = 97;
}

Importantly, the variable is already outside the scope of the if's block. That's what makes this safe.
---
