title: Why is C++ "typename" required even in cases where there is no parsing ambiguity?
body: <blockquote>
    <p><strong>Possible Duplicate:</strong><br>
    <a href="https://stackoverflow.com/questions/4347730/use-of-typename-keyword-with-template-function-parameters">Use of typename keyword with template function parameters</a><br>
    <a href="https://stackoverflow.com/questions/4421306/use-of-typename-keyword-with-typedef-and-new">Use of typename keyword with typedef and new</a>  </p>
  </blockquote>
  
  
  
  <p>I understand why C++ has the <code>typename</code> keyword.  The parsing of certain token sequences, such as</p>
  
  <pre><code>qwert * yuiop;
  asdfg(*hjkl)(zxcvb);
  </code></pre>
  
  <p>depends on whether certain identifiers (in this case, <code>qwert</code>, <code>asdfg</code> and <code>zxcvb</code>) refer to types or to values.  So in templates, sometimes it needs to be told so that it can parse the template definition.</p>
  
  <pre><code>template&lt;class Qwert&gt; void yuiop() {
      typename Qwert::asdfg * zxcvb;  // declare a pointer of type Qwert::asdfg
      Qwert::asdfg * hjkl;            // multiply Qwert::asdfg by hjkl
  }
  </code></pre>
  
  <p>However, there are cases where the syntax can only accept a type, yet typename is still required.</p>
  
  <pre><code>template&lt;class Qwert&gt; void yuiop(Qwert::asdfg) {
      Qwert::asdfg hjkl;
  }
  </code></pre>
  
  <p>This doesn't compile.  It seems that typical compilers assume Qwert::asdfg is a variable or constant and so throw a syntax error.  But why?</p>
  
  <ul>
  <li>On the first line, the parsing context guarantees that we are dealing with a function signature, not a function call, and C++ (unlike C) doesn't allow a parameter to be declared in a function signature without a type, and so what follows the open bracket <em>must</em> be a type.</li>
  <li>Where two identifiers are juxtaposed as on the second line, the first identifier must always denote a type.</li>
  </ul>
  
  <p>The essence of my question is: Why doesn't the C++ standard allow type/value ambiguities to be resolved from the parsing context in cases like these?</p>
  
  <p>(Note: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf" rel="nofollow noreferrer">the nearest thing I've found online to a standard</a> states something to this effect near the bottom of page 301.  I don't know whether any actual standards are different in this respect.)</p>