<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    CWG Issue 629</TITLE>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  .DEL { text-decoration:line-through; background-color: #FFD0D0 }
  @media (prefers-color-scheme: dark) {
    HTML { background-color:#202020; color:#f0f0f0; }
    A { color:#5bc0ff; }
    A:visited { color:#c6a8ff; }
    A:hover, a:focus { color:#afd7ff; }
    INS { background-color:#033a16; color:#aff5b4; }
    .INS { background-color: #033a16; }
    DEL { background-color:#67060c; color:#ffdcd7; }
    .DEL { background-color:#67060c; }
  }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<P><EM>This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21
  Core Issues List revision 118b.
  See http://www.open-std.org/jtc1/sc22/wg21/ for the official
  list.</EM></P>
<P>2025-09-28</P>
<HR>
<A NAME="629"></A><H4>629.
  
<TT>auto</TT> parsing ambiguity
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

 <B>Status: </B>CD1
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>14 March 2007<BR>


<P>[Voted into the WP at the February, 2008 meeting as paper
J16/08-0056 = WG21 N2546.]</P>



<P>We've found an interesting parsing ambiguity with the new meaning of
<TT>auto</TT>.  Consider:</P>

<PRE>
    typedef int T;
    void f() {
        auto T = 42;  // Valid or not?
    }
</PRE>

<P>The question here is whether T should be a type specifier or a
storage class?  9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto#1">dcl.spec.auto</A>] paragraph 1 says,</P>

<BLOCKQUOTE>

The <TT>auto</TT> <I>type-specifier</I> has two meanings depending on
the context of its use. In a <I>decl-specifier-seq</I> that contains
at least one <I>type-specifier</I> (in addition to <TT>auto</TT>) that
is not a <I>cv-qualifier</I>, the <TT>auto</TT> <I>type-specifier</I>
specifies that the object named in the declaration has automatic
storage duration.

</BLOCKQUOTE>

<P>In this case, <TT>T</TT> is a <I>type-specifier</I>, so the
declaration is ill-formed: there is no <I>declarator-id</I>.  Many,
however, would like to see <TT>auto</TT> work &#8220;just like
<TT>int</TT>,&#8221; i.e., forcing <TT>T</TT> to be redeclared in
the inner scope.  Concerns cited included hijacking of the name in
templates and inline function bodies over the course of time if a
program revision introduces a type with that name in the surrounding
context.  Although it was pointed out that enclosing the name in
parentheses in the inner declaration would prevent any such
problems, this was viewed as unacceptably ugly.</P>

<P><B>Notes from the April, 2007 meeting:</B></P>

<P>The CWG wanted to avoid a rule like, &#8220;if <TT>auto</TT> can
be a <I>type-specifier</I>, it is&#8221; (similar to the existing
&#8220;if it can be a declaration, it is&#8221; rule) because of the
lookahead and backtracking difficulties such an approach would pose
for certain kinds of parsing techniques.  It was noted that the
difficult lookahead cases all involve parentheses, which would not
be a problem if only the &#8220;=&#8221; form of initializer were
permitted in <TT>auto</TT> declarations; only very limited lookahead
is required in that case.  It was also pointed out that the &#8220;if
it can be a <I>type-specifier</I>, it is&#8221; approach results in a
quiet change of meaning for cases like
</P>

<PRE>
    typedef int T;
    int n = 3;
    void f() {
        auto T(n);
    }
</PRE>

<P>This currently declares <TT>n</TT> to be an <TT>int</TT> variable
in the inner scope but would, under the full lookahead approach,
declare <TT>T</TT> to be a variable, quitely changing uses
of <TT>n</TT> inside <TT>f()</TT> to refer to the outer variable.</P>

<P>The consensus of the CWG was to pursue the change to require the
&#8220;=&#8221; form of initializer for <TT>auto</TT>.</P>

<P><B>Notes from the July, 2007 meeting:</B></P>

<P>See paper J16/07-0197 = WG21 N2337.  There was no consensus
among the CWG for either of the approaches recommended in the
paper; additional input and direction is required.</P>

<BR><BR>
</BODY>
</HTML>
