title: Why special rules for `for` statement scope?
body: <p>I stumbled recently in this problem</p>
  
  <pre><code>for(int i=0,n=v.size(); i&lt;n; i++) {
     ...
     P2d n = ...   &lt;&lt;&lt;--- error here
  }
  </code></pre>
  
  <p>the compiler was complaining about the fact that the <code>n</code> local variable has been already defined, despite that the open brace looks like it should start a new scope.</p>
  
  <p>Indeed the standard has a special wording for this and while the code compiled fine with g++4.6.3, it complains with more recent versions and other compilers.</p>
  
  <p>What is the rationale (if there is any) behind this special rule?</p>
  
  <p>To be more clear: the standard explains that this is not permitted and I've no questions about the <strong><em>technical</em></strong> reason for which that's an error: I was just wondering why the committee decided to use special extra rules instead of just creating another nested scope when seeing the opening brace (like it happens in other places).</p>
  
  <p>For example to make the code legal you can just wrap the body with <strong>two</strong> brace pairs instead of one...</p>
  
  <p>Please also note that braces after <code>for/while/if</code>, while considered good practice, <strong>are not mandatory</strong> and not part of the syntax, but still a scope containing the loop variables exists (therefore using function definition as another example where the scope of the locals is the body of the function is not relevant: a function body is not a statement and braces are mandatory).</p>
  
  <p>In the C++ syntax the body of a <code>for</code> is just a statement; however if this statement happens to be a braced group then it gets a special handling in <code>for/while/if</code> (that doesn't happen when you use a braced group as statement elsewhere in the language).</p>
  
  <p>What is the reason for adding this extra complication to the language? It's apparently not needed and just treating the braces as another inner scope seems (to me) simpler.</p>
  
  <p>Are there use cases in which this simpler and more regular approach doesn't work?</p>
  
  <p>Note that <strong>I'm not asking opinions</strong>. Either you know why the committee took this decision (requiring also a quite elaborate wording in the standard instead of just having the body as a regular statement with the regular handling of a brace enclosed block when used as statement) or you don't.</p>
  
  <h2>EDIT</h2>
  
  <p>The "single scope" view for the syntax is for me unnatural but technically possible for the <code>for</code> statement that can be rationalized as a single block with a backward <code>goto</code> statement, but it's hard to defend in a very similar case for the <code>if</code> statement:</p>
  
  <pre><code>if (int x = whatever()) {
      int x = 3; // Illegal
  } else {
      int x = 4; // Illegal here too
  }
  </code></pre>
  
  <p>but this is instead legal</p>
  
  <pre><code>if (int x = whatever()) {
      int z = foo();
  } else {
      int z = bar();
  }
  </code></pre>
  
  <p>So are the condition, the <code>then</code> part and the <code>else</code> part of an <code>if</code> statement the same scope? No because you can declare two <code>z</code> variables. Are they separate scopes? No because you cannot declare <code>x</code>.</p>
  
  <p>The only rationalization I can see is that the <code>then</code> and <code>else</code> part are indeed separate scopes, but with the added (strange) rule that the variable declared in the condition cannot be declared in the scope. Why this extra strange limitation rule is present is what I'm asking about.</p>