declarations.tex

%!TEX root = std.tex
\rSec0[dcl.dcl]{Declarations}%
\indextext{declaration|(}

\gramSec[gram.dcl]{Declarations}

\indextext{linkage specification|see{specification, linkage}}

\pnum
Declarations generally specify how names are to be interpreted. Declarations have
the form

\begin{bnf}
\nontermdef{declaration-seq}\br
    declaration\br
    declaration-seq declaration
\end{bnf}

\begin{bnf}
\nontermdef{declaration}\br
    block-declaration\br
    nodeclspec-function-declaration\br
    function-definition\br
    template-declaration\br
    deduction-guide\br
    explicit-instantiation\br
    explicit-specialization\br
    linkage-specification\br
    namespace-definition\br
    empty-declaration\br
    attribute-declaration
\end{bnf}

\begin{bnf}
\nontermdef{block-declaration}\br
    simple-declaration\br
    asm-definition\br
    namespace-alias-definition\br
    using-declaration\br
    using-directive\br
    static_assert-declaration\br
    alias-declaration\br
    opaque-enum-declaration
\end{bnf}

\begin{bnf}
\nontermdef{nodeclspec-function-declaration}\br
    \opt{attribute-specifier-seq} declarator \terminal{;}
\end{bnf}

\begin{bnf}
\nontermdef{alias-declaration}\br
    \terminal{using} identifier \opt{attribute-specifier-seq} \terminal{=} defining-type-id \terminal{;}
\end{bnf}

\begin{bnf}
\nontermdef{simple-declaration}\br
    decl-specifier-seq \opt{init-declarator-list} \terminal{;}\br
    attribute-specifier-seq decl-specifier-seq init-declarator-list \terminal{;}\br
    \opt{attribute-specifier-seq} decl-specifier-seq \opt{ref-qualifier} \terminal{[} identifier-list \terminal{]} initializer \terminal{;}
\end{bnf}

\begin{bnf}
\nontermdef{static_assert-declaration}\br
  \terminal{static_assert} \terminal{(} constant-expression \terminal{)} \terminal{;}\br
  \terminal{static_assert} \terminal{(} constant-expression \terminal{,} string-literal \terminal{)} \terminal{;}
\end{bnf}

\begin{bnf}
\nontermdef{empty-declaration}\br
    \terminal{;}
\end{bnf}

\begin{bnf}
\nontermdef{attribute-declaration}\br
    attribute-specifier-seq \terminal{;}
\end{bnf}

\begin{note}
\grammarterm{asm-definition}{s} are described in~\ref{dcl.asm}, and
\grammarterm{linkage-specification}{s} are described in~\ref{dcl.link};
\grammarterm{function-definition}{s} are described in~\ref{dcl.fct.def} and
\grammarterm{template-declaration}{s} and
\grammarterm{deduction-guide}{s} are described in \ref{temp};
\grammarterm{namespace-definition}{s} are described in~\ref{namespace.def},
\grammarterm{using-declaration}{s} are described in~\ref{namespace.udecl} and
\grammarterm{using-directive}{s} are described in~\ref{namespace.udir}.
\end{note}

\pnum
A
\grammarterm{simple-declaration} or
\grammarterm{nodeclspec-function-declaration} of the form
\begin{ncsimplebnf}
\opt{attribute-specifier-seq} \opt{decl-specifier-seq} \opt{init-declarator-list} \terminal{;}
\end{ncsimplebnf}
is divided into three parts.
Attributes are described in~\ref{dcl.attr}.
\grammarterm{decl-specifier}{s}, the principal components of
a \grammarterm{decl-specifier-seq}, are described in~\ref{dcl.spec}.
\grammarterm{declarator}{s}, the components of an
\grammarterm{init-declarator-list}, are described in \ref{dcl.decl}.
The \grammarterm{attribute-specifier-seq}
appertains to each of the entities declared by
the \grammarterm{declarator}{s}
of the \grammarterm{init-declarator-list}.
\begin{note} In the declaration for an entity, attributes appertaining to that
entity may appear at the start of the declaration and after the
\grammarterm{declarator-id} for that declaration.
\end{note} \begin{example}
\begin{codeblock}
[[noreturn]] void f [[noreturn]] ();    // OK
\end{codeblock}
\end{example}

\pnum
Except where otherwise specified, the meaning of an \grammarterm{attribute-declaration}
is \impldef{meaning of attribute declaration}.

\pnum
\indextext{declaration}%
\indextext{scope}%
A declaration occurs in a \deflink{scope}{\ref{basic.scope}}; the scope rules are
summarized in~\ref{basic.lookup}. A declaration that declares a function
or defines a class, namespace, template, or function also has one or
more scopes nested within it. These nested scopes, in turn, can have
declarations nested within them. Unless otherwise stated, utterances in
\ref{dcl.dcl} about components in, of, or contained by a
declaration or subcomponent thereof refer only to those components of
the declaration that are \emph{not} nested within scopes nested within
the declaration.

\pnum
\indextext{identifier}%
\indextext{declarator}%
In a \grammarterm{simple-declaration}, the optional
\grammarterm{init-declarator-list} can be omitted only when declaring a
\link{class}{\ref{class}} or \link{enumeration}{\ref{dcl.enum}}, that is,
when the \grammarterm{decl-specifier-seq} contains either a
\grammarterm{class-specifier}, an \grammarterm{elaborated-type-specifier} with
a \grammarterm{class-key}\iref{class.name}, or an
\grammarterm{enum-specifier}. In these cases and whenever a
\grammarterm{class-specifier} or \grammarterm{enum-specifier} is present in
the \grammarterm{decl-specifier-seq}, the identifiers in these specifiers
are among the names being declared by the declaration (as
\grammarterm{class-name}{s}, \grammarterm{enum-name}{s}, or
\grammarterm{enumerator}{s}, depending on the syntax). In such cases,
the \grammarterm{decl-specifier-seq} shall introduce one or more names into
the program, or shall redeclare a name introduced by a previous
declaration.
\begin{example}
\begin{codeblock}
enum { };           // ill-formed
typedef class { };  // ill-formed
\end{codeblock}
\end{example}

\pnum
\indextext{\idxgram{static_assert}}%
In a \grammarterm{static_assert-declaration}, the
\grammarterm{constant-expression} shall be
a \deflinkx{contextually converted constant expression
of type \tcode{bool}}{contextually converted constant expression of type bool}{\ref{expr.const}}.
If the value of the expression when
so converted is \tcode{true}, the declaration has no
effect. Otherwise, the program is ill-formed, and the resulting
diagnostic message\iref{intro.compliance} shall include the text of
the \grammarterm{string-literal}, if one is supplied,
except that characters not in the \deflinkx{basic
source character set}{character set!basic source}{\ref{lex.charset}} are not required to appear in
the diagnostic message.
\begin{example}

\begin{codeblock}
static_assert(sizeof(int) == sizeof(void*), "wrong pointer size");
\end{codeblock}\end{example}

\pnum
An \grammarterm{empty-declaration} has no effect.

\pnum
A \grammarterm{simple-declaration} with an \grammarterm{identifier-list} is called
a \defn{structured binding declaration}\iref{dcl.struct.bind}.
The \grammarterm{decl-specifier-seq} shall
contain only the \grammarterm{type-specifier} \link{\tcode{auto}}{\ref{dcl.spec.auto}}
and \grammarterm{cv-qualifier}{s}.
The \grammarterm{initializer} shall be
of the form ``\tcode{=} \grammarterm{assignment-expression}'',
of the form ``\tcode{\{} \grammarterm{assignment-expression} \tcode{\}}'',
or
of the form ``\tcode{(} \grammarterm{assignment-expression} \tcode{)}'',
where the
\grammarterm{assignment-expression} is of array or non-union class type.

\pnum
Each \grammarterm{init-declarator} in the \grammarterm{init-declarator-list}
contains exactly one \grammarterm{declarator-id}, which is the name
declared by that \grammarterm{init-declarator} and hence one of the names
declared by the declaration. The
\grammarterm{defining-type-specifier}{s}\iref{dcl.type} in the
\grammarterm{decl-specifier-seq} and the recursive \grammarterm{declarator}
structure of the \grammarterm{init-declarator} describe a
type\iref{dcl.meaning}, which is then associated with the name being
declared by the \grammarterm{init-declarator}.

\pnum
If the \grammarterm{decl-specifier-seq} contains the \tcode{typedef}
specifier, the declaration is called a \defnx{typedef declaration}{declaration!typedef} and the name
of each \grammarterm{init-declarator}
is declared to be a \grammarterm{typedef-name}, synonymous with its
associated type\iref{dcl.typedef}. If the
\grammarterm{decl-specifier-seq} contains no \tcode{typedef} specifier, the
declaration is called a \defnx{function declaration}{declaration!function} if
the type associated with the name is a function type\iref{dcl.fct} and
an \defnx{object declaration}{declaration!object} otherwise.

\pnum
\indextext{definition!declaration as}%
Syntactic components beyond those found in the general form of
declaration are added to a function declaration to make a
\grammarterm{function-definition}. An object declaration, however, is also
a definition unless it contains the \tcode{extern} specifier and has no
initializer\iref{basic.def}.
\indextext{initialization!definition and}%
A
definition causes the appropriate amount of storage to be reserved and
any appropriate initialization\iref{dcl.init} to be done.

\pnum
A \grammarterm{nodeclspec-function-declaration} shall declare a
constructor, destructor, or conversion function.\footnote{The
``implicit int'' rule of C is no longer supported.}
\begin{note}
A \grammarterm{nodeclspec-function-declaration} can only be used in a
\grammarterm{template-declaration}\iref{temp},
\grammarterm{explicit-instantiation}\iref{temp.explicit}, or
\grammarterm{explicit-specialization}\iref{temp.expl.spec}.
\end{note}

\rSec1[dcl.spec]{Specifiers}%
\indextext{specifier|(}

\pnum
\indextext{specifier!declaration}%
The specifiers that can be used in a declaration are

\begin{bnf}
\nontermdef{decl-specifier}\br
    storage-class-specifier\br
    defining-type-specifier\br
    function-specifier\br
    \terminal{friend}\br
    \terminal{typedef}\br
    \terminal{constexpr}\br
    \terminal{inline}
\end{bnf}

\begin{bnf}
\nontermdef{decl-specifier-seq}\br
    decl-specifier \opt{attribute-specifier-seq}\br
    decl-specifier decl-specifier-seq
\end{bnf}

The optional \grammarterm{attribute-specifier-seq} in a \grammarterm{decl-specifier-seq}
appertains to the type determined by the preceding
\grammarterm{decl-specifier}{s}\iref{dcl.meaning}. The \grammarterm{attribute-specifier-seq}
affects the type only for the declaration it appears in, not other declarations involving the
same type.

\pnum
Each \grammarterm{decl-specifier} shall appear at most once in a complete
\grammarterm{decl-specifier-seq}, except that
\tcode{long} may appear twice.

\pnum
\indextext{ambiguity!declaration type}%
If a \grammarterm{type-name} is encountered while parsing a \grammarterm{decl-specifier-seq},
it is interpreted as part of the \grammarterm{decl-specifier-seq} if and only if there is no
previous \grammarterm{defining-type-specifier} other than a \grammarterm{cv-qualifier} in the
\grammarterm{decl-specifier-seq}.
The sequence shall be self-consistent as
described below.
\begin{example}
\begin{codeblock}
typedef char* Pc;
static Pc;                      // error: name missing
\end{codeblock}
Here, the declaration \tcode{static} \tcode{Pc} is ill-formed because no
name was specified for the static variable of type \tcode{Pc}. To get a
variable called \tcode{Pc}, a \grammarterm{type-specifier} (other than
\tcode{const} or \tcode{volatile}) has to be present to indicate that
the \grammarterm{typedef-name} \tcode{Pc} is the name being (re)declared,
rather than being part of the \grammarterm{decl-specifier} sequence. For
another example,
\begin{codeblock}
void f(const Pc);               // \tcode{void f(char* const)} (not \tcode{const char*})
void g(const int Pc);           // \tcode{void g(const int)}
\end{codeblock}
\end{example}

\pnum
\indextext{\idxcode{signed}!typedef@\tcode{typedef} and}%
\indextext{\idxcode{unsigned}!typedef@\tcode{typedef} and}%
\indextext{\idxcode{long}!typedef@\tcode{typedef} and}%
\indextext{\idxcode{short}!typedef@\tcode{typedef} and}%
\begin{note}
Since \tcode{signed}, \tcode{unsigned}, \tcode{long}, and \tcode{short}
by default imply \tcode{int}, a \grammarterm{type-name} appearing after one
of those specifiers is treated as the name being (re)declared.
\begin{example}
\begin{codeblock}
void h(unsigned Pc);            // \tcode{void h(unsigned int)}
void k(unsigned int Pc);        // \tcode{void k(unsigned int)}
\end{codeblock}
\end{example}
\end{note}

\rSec2[dcl.stc]{Storage class specifiers}%
\indextext{specifier!storage class}%
\indextext{declaration!storage class}%

\pnum
The storage class specifiers are
\begin{bnf}
\nontermdef{storage-class-specifier}\br
    \indexedspan{\terminal{static}}{\indextext{\idxcode{static}}}\br
    \indexedspan{\terminal{thread_local}}{\indextext{\idxcode{thread_local}}}\br
    \indexedspan{\terminal{extern}}{\indextext{\idxcode{extern}}}\br
    \indexedspan{\terminal{mutable}}{\indextext{\idxcode{mutable}}}
\end{bnf}

At most one \grammarterm{storage-class-specifier} shall appear in a given
\grammarterm{decl-specifier-seq}, except that \tcode{thread_local} may appear with \tcode{static} or
\tcode{extern}. If \tcode{thread_local} appears in any declaration of
a variable it shall be present in all declarations of that entity. If a
\grammarterm{storage-class-specifier}
appears in a \grammarterm{decl-specifier-seq}, there can be no
\tcode{typedef} specifier in the same \grammarterm{decl-specifier-seq} and
the \grammarterm{init-declarator-list} or \grammarterm{member-declarator-list}
of the declaration shall not be
empty (except for an anonymous union declared in a named namespace or in the
global namespace, which shall be declared
\indextext{specifier!\idxcode{static}}%
\tcode{static}\iref{class.union.anon}). The
\grammarterm{storage-class-specifier} applies to the name declared by each
\grammarterm{init-declarator} in the list and not to any names declared by
other specifiers. A \grammarterm{storage-class-specifier}
other than \tcode{thread_local}
shall not be
specified in an \link{explicit specialization}{\ref{temp.expl.spec}} or an
\link{explicit instantiation}{\ref{temp.explicit}} directive.

\pnum
\begin{note}
A variable declared without a \grammarterm{storage-class-specifier}
at block scope or declared as a function parameter
has \deflink{automatic storage duration}{\ref{basic.stc.auto}} by default.
\end{note}

\pnum
The \tcode{thread_local} specifier
indicates that the named entity has \deflink{thread storage duration}{\ref{basic.stc.thread}}.
It shall be applied only to the names of variables of namespace
or block scope and to the names of static data members.
When \tcode{thread_local} is applied to a variable of block scope the
\grammarterm{storage-class-specifier} \tcode{static} is implied if no other
\grammarterm{storage-class-specifier} appears in the
\grammarterm{decl-specifier-seq}.

\pnum
\indextext{restriction!\idxcode{static}}%
The \tcode{static} specifier can be applied only to names of variables and
functions and to \link{anonymous unions}{\ref{class.union.anon}}. There can be no
\tcode{static} function declarations within a block, nor any
\tcode{static} function parameters. A \tcode{static} specifier used in
the declaration of a variable declares the variable to have
\deflink{static storage duration}{\ref{basic.stc.static}}, unless accompanied by the
\tcode{thread_local} specifier, which declares the variable to have
\deflink{thread storage duration}{\ref{basic.stc.thread}}. A \tcode{static} specifier can be
used in declarations of class members;~\ref{class.static} describes its
effect.
\indextext{\idxcode{static}!linkage of}%
For the linkage of a name declared with a \tcode{static} specifier,
see~\ref{basic.link}.

\pnum
\indextext{restriction!\idxcode{extern}}%
The \tcode{extern} specifier can be applied only to the names of variables
and functions. The \tcode{extern} specifier cannot be used in the
declaration of class members or function parameters.
\indextext{\idxcode{extern}!linkage of}%
\indextext{consistency!linkage}%
For the linkage of a name declared with an \tcode{extern} specifier,
see~\ref{basic.link}.
\begin{note}
The \tcode{extern} keyword can also be used in
\grammarterm{explicit-instantiation}{s} and
\grammarterm{linkage-specification}{s}, but it is not a
\grammarterm{storage-class-specifier} in such contexts.
\end{note}

\pnum
The linkages implied by successive declarations for a given entity shall
agree. That is, within a given scope, each declaration declaring the
same variable name or the same overloading of a function name shall imply
the same linkage. Each function in a given set of overloaded functions
can have a different linkage, however.
\begin{example}
\begin{codeblock}
static char* f();               // \tcode{f()} has internal linkage
char* f()                       // \tcode{f()} still has internal linkage
  { @\commentellip@ }

char* g();                      // \tcode{g()} has external linkage
static char* g()                // error: inconsistent linkage
  { @\commentellip@ }

void h();
inline void h();                // external linkage

inline void l();
void l();                       // external linkage

inline void m();
extern void m();                // external linkage

static void n();
inline void n();                // internal linkage

static int a;                   // \tcode{a} has internal linkage
int a;                          // error: two definitions

static int b;                   // \tcode{b} has internal linkage
extern int b;                   // \tcode{b} still has internal linkage

int c;                          // \tcode{c} has external linkage
static int c;                   // error: inconsistent linkage

extern int d;                   // \tcode{d} has external linkage
static int d;                   // error: inconsistent linkage
\end{codeblock}
\end{example}

\pnum
\indextext{declaration!forward}%
The name of a declared but undefined class can be used in an
\tcode{extern} declaration. Such a declaration can only be used in ways
that do not require a complete class type.
\begin{example}
\begin{codeblock}
struct S;
extern S a;
extern S f();
extern void g(S);

void h() {
  g(a);                         // error: \tcode{S} is incomplete
  f();                          // error: \tcode{S} is incomplete
}
\end{codeblock}
\end{example}

\pnum
The \tcode{mutable} specifier shall appear only in the declaration of
a \deflink{non-static data member}{\ref{class.mem}}
whose type is neither const-qualified nor a reference type.
\begin{example}
\begin{codeblock}
class X {
  mutable const int* p;         // OK
  mutable int* const q;         // ill-formed
};
\end{codeblock}
\end{example}

\pnum
The \tcode{mutable} specifier on a class data member nullifies a
\tcode{const} specifier applied to the containing class object and
permits modification of the mutable class member even though the rest of
the object is const\iref{dcl.type.cv}.

\rSec2[dcl.fct.spec]{Function specifiers}%
\indextext{specifier!function}%
\indextext{function|seealso{friend function; member function; inline function; virtual function}}

\pnum
A
\grammarterm{function-specifier}
can be used only in a function declaration.

\begin{bnf}
\nontermdef{function-specifier}\br
    \terminal{virtual}\br
    \terminal{explicit}
\end{bnf}

\pnum
\indextext{specifier!\idxcode{virtual}}%
The \tcode{virtual} specifier shall be used only in the initial
declaration of a non-static class member function;
see~\ref{class.virtual}.

\pnum
\indextext{specifier!\idxcode{explicit}}%
The \tcode{explicit} specifier shall be used only in the declaration of
a constructor or conversion function within its class definition;
see~\ref{class.conv.ctor} and~\ref{class.conv.fct}.

\rSec2[dcl.typedef]{The \tcode{typedef} specifier}%
\indextext{specifier!\idxcode{typedef}}

\pnum
Declarations containing the \grammarterm{decl-specifier} \tcode{typedef}
declare identifiers that can be used later for naming
\link{fundamental}{\ref{basic.fundamental}} or \link{compound}{\ref{basic.compound}}
types. The \tcode{typedef} specifier shall not be
combined in a \grammarterm{decl-specifier-seq} with any other kind of
specifier except a \grammarterm{defining-type-specifier}, and it shall not be used in the
\grammarterm{decl-specifier-seq} of a
\grammarterm{parameter-declaration}\iref{dcl.fct} nor in the
\grammarterm{decl-specifier-seq} of a
\grammarterm{function-definition}\iref{dcl.fct.def}.
If a \tcode{typedef} specifier appears in a declaration without a \grammarterm{declarator},
the program is ill-formed.

\begin{bnf}
\nontermdef{typedef-name}\br
    identifier
\end{bnf}

A name declared with the \tcode{typedef} specifier becomes a
\grammarterm{typedef-name}. Within the scope of its declaration, a
\grammarterm{typedef-name} is syntactically equivalent to a keyword and
names the type associated with the identifier in the way described in
\ref{dcl.decl}.
\indextext{declaration!typedef@\tcode{typedef} as type}%
\indextext{equivalence!type}%
\indextext{synonym!type name as}%
A \grammarterm{typedef-name} is thus a synonym for another type. A
\grammarterm{typedef-name} does not introduce a new type the way a class
declaration\iref{class.name} or enum declaration does.
\begin{example}
After
\begin{codeblock}
typedef int MILES, *KLICKSP;
\end{codeblock}
the constructions
\begin{codeblock}
MILES distance;
extern KLICKSP metricp;
\end{codeblock}
are all correct declarations; the type of \tcode{distance} is
\tcode{int} and that of \tcode{metricp} is ``pointer to \tcode{int}''.
\end{example}

\pnum
A \grammarterm{typedef-name} can also be introduced by an
\grammarterm{alias-declaration}. The \grammarterm{identifier} following the
\tcode{using} keyword becomes a \grammarterm{typedef-name}
and the optional \grammarterm{attribute-specifier-seq} following the
\grammarterm{identifier} appertains to that \grammarterm{typedef-name}.
Such a \grammarterm{typedef-name} has the same
semantics as if it were introduced by the \tcode{typedef} specifier. In
particular, it does not define a new type.
\begin{example}
\begin{codeblock}
using handler_t = void (*)(int);
extern handler_t ignore;
extern void (*ignore)(int);         // redeclare \tcode{ignore}
using cell = pair<void*, cell*>;    // ill-formed
\end{codeblock}
\end{example}
The \grammarterm{defining-type-specifier-seq}
of the \grammarterm{defining-type-id} shall not define
a class or enumeration if the \grammarterm{alias-declaration}
is the \grammarterm{declaration} of a \grammarterm{template-declaration}.

\pnum
\indextext{redefinition!\idxcode{typedef}}%
In a given non-class scope, a \tcode{typedef} specifier can be used to
redefine the name of any type declared in that scope to refer to the
type to which it already refers.
\begin{example}
\begin{codeblock}
typedef struct s { @\commentellip@ } s;
typedef int I;
typedef int I;
typedef I I;
\end{codeblock}
\end{example}

\pnum
In a given class scope, a \tcode{typedef} specifier can be used to
redefine any \grammarterm{class-name} declared in that scope that is not
also a \grammarterm{typedef-name} to refer to the type to which it already
refers.
\begin{example}
\begin{codeblock}
struct S {
  typedef struct A { } A;       // OK
  typedef struct B B;           // OK
  typedef A A;                  // error
};
\end{codeblock}
\end{example}

\pnum
If a \tcode{typedef} specifier is used to redefine in a given scope an
entity that can be referenced using an \grammarterm{elaborated-type-specifier},
the entity can continue to be referenced by an
\grammarterm{elaborated-type-specifier} or as an enumeration or class name
in an enumeration or class definition respectively. \begin{example}
\begin{codeblock}
struct S;
typedef struct S S;
int main() {
  struct S* p;                  // OK
}
struct S { };                   // OK
\end{codeblock}
\end{example}

\pnum
In a given scope, a \tcode{typedef} specifier shall not be used to
redefine the name of any type declared in that scope to refer to a
different type.
\begin{example}
\begin{codeblock}
class complex { @\commentellip@ };
typedef int complex;            // error: redefinition
\end{codeblock}
\end{example}

\pnum
Similarly, in a given scope, a class or enumeration shall not be
declared with the same name as a \grammarterm{typedef-name} that is
declared in that scope and refers to a type other than the class or
enumeration itself.
\begin{example}
\begin{codeblock}
typedef int complex;
class complex { @\commentellip@ };    // error: redefinition
\end{codeblock}
\end{example}

\pnum
\begin{note}
\indextext{class name!\idxcode{typedef}}%
A \grammarterm{typedef-name} that names a class type, or a cv-qualified
version thereof, is also a \grammarterm{class-name}\iref{class.name}. If
a \grammarterm{typedef-name} is used to identify the subject of
an \grammarterm{elaborated-type-specifier}\iref{dcl.type.elab},
a \link{class}{\ref{class}} definition,
a \link{constructor}{\ref{class.ctor}} declaration,
or a \link{destructor}{\ref{class.dtor}} declaration,
the program is ill-formed.
\end{note}
\begin{example}
\begin{codeblock}
struct S {
  S();
  ~S();
};

typedef struct S T;

S a = T();                      // OK
struct T * p;                   // error
\end{codeblock}
\end{example}

\pnum
\indextext{class name!\idxcode{typedef}}%
\indextext{enum name!\idxcode{typedef}}%
\indextext{class!unnamed}%
If the typedef declaration defines an unnamed class (or enum), the first
\grammarterm{typedef-name} declared by the declaration to be that class
type (or enum type) is used to denote the class type (or enum type) for
linkage purposes only\iref{basic.link}.
\begin{note}
A typedef declaration involving a \grammarterm{lambda-expression}
does not itself define the associated closure type,
and so the closure type is not given a name for linkage purposes.
\end{note}
\begin{example}
\begin{codeblock}
typedef struct { } *ps, S;      // \tcode{S} is the class name for linkage purposes
typedef decltype([]{}) C;       // the closure type has no name for linkage purposes
\end{codeblock}
\end{example}

\rSec2[dcl.friend]{The \tcode{friend} specifier}%
\indextext{specifier!\idxcode{friend}}

\pnum
The \tcode{friend} specifier is used to specify access to class members;
see~\ref{class.friend}.

\rSec2[dcl.constexpr]{The \tcode{constexpr} specifier}%
\indextext{specifier!\idxcode{constexpr}}

\pnum
The \tcode{constexpr} specifier shall be applied only to the definition of
a variable or variable template or
the declaration of a
function or function template.
A function or static data member declared with the \tcode{constexpr}
specifier is implicitly an inline function or variable\iref{dcl.inline}.
If any declaration of a function or function template has
a \tcode{constexpr} specifier,
then all its declarations shall contain the \tcode{constexpr} specifier. \begin{note} An
explicit specialization can differ from the template declaration with respect to the
\tcode{constexpr} specifier. \end{note}
\begin{note}
Function parameters cannot be declared \tcode{constexpr}.\end{note}
\begin{example}
\begin{codeblock}
constexpr void square(int &x);  // OK: declaration
constexpr int bufsz = 1024;     // OK: definition
constexpr struct pixel {        // error: \tcode{pixel} is a type
  int x;
  int y;
  constexpr pixel(int);         // OK: declaration
};
constexpr pixel::pixel(int a)
  : x(a), y(x)                  // OK: definition
  { square(x); }
constexpr pixel small(2);       // error: \tcode{square} not defined, so \tcode{small(2)}
                                // not constant\iref{expr.const} so \tcode{constexpr} not satisfied

constexpr void square(int &x) { // OK: definition
  x *= x;
}
constexpr pixel large(4);       // OK: \tcode{square} defined
int next(constexpr int x) {     // error: not for parameters
     return x + 1;
}
extern constexpr int memsz;     // error: not a definition
\end{codeblock}
\end{example}

\pnum
A \tcode{constexpr} specifier used in the declaration of a function that is not a
constructor declares that
function to be a \defnx{constexpr function}{specifier!\idxcode{constexpr}!function}. Similarly, a
\tcode{constexpr} specifier used in
a constructor declaration declares that constructor to be a
\defnx{constexpr constructor}{specifier!\idxcode{constexpr}!constructor}.

\pnum
\indextext{specifier!\idxcode{constexpr}!function}
\indextext{constexpr function}
The definition of a constexpr function shall satisfy the following
requirements:
\begin{itemize}
\item
it shall not be \link{virtual}{\ref{class.virtual}};

\item
its return type shall be a literal type;

\item
each of its parameter types shall be a literal type;

\item
its \grammarterm{function-body} shall be
\tcode{= delete}, \tcode{= default}, or
a \grammarterm{compound-statement}
that does not contain
\begin{itemize}
\item an \grammarterm{asm-definition},
\item a \tcode{goto} statement,
\item an \deflink{identifier label}{\ref{stmt.label}},
\item a \grammarterm{try-block}, or
\item a definition of a variable
of non-literal type or
of static or thread storage duration or
for which no initialization is performed.
\end{itemize}
\end{itemize}

\begin{example}
\begin{codeblock}
constexpr int square(int x)
  { return x * x; }             // OK
constexpr long long_max()
  { return 2147483647; }        // OK
constexpr int abs(int x) {
  if (x < 0)
    x = -x;
  return x;                     // OK
}
constexpr int first(int n) {
  static int value = n;         // error: variable has static storage duration
  return value;
}
constexpr int uninit() {
  int a;                        // error: variable is uninitialized
  return a;
}
constexpr int prev(int x)
  { return --x; }               // OK
constexpr int g(int x, int n) { // OK
  int r = 1;
  while (--n > 0) r *= x;
  return r;
}
\end{codeblock}
\end{example}

\pnum
\indextext{specifier!\idxcode{constexpr}!constructor}%
The definition of a constexpr constructor shall satisfy the
following requirements:
\begin{itemize}
\item
the class shall not have any virtual base classes;

\item
each of the parameter types shall be a literal type;

\item
its \grammarterm{function-body} shall not be a \grammarterm{function-try-block}.
\end{itemize}

In addition, either its \grammarterm{function-body} shall be
\tcode{= delete}, or it shall satisfy the following requirements:
\begin{itemize}
\item
either its \grammarterm{function-body} shall be \tcode{= default}, or the \grammarterm{compound-statement} of its \grammarterm{function-body}
shall satisfy the requirements for a \grammarterm{function-body} of a
constexpr function;

\item
every non-variant non-static data member and base class subobject
shall be initialized\iref{class.base.init};

\item
if the class is a union having variant members\iref{class.union}, exactly one of them
shall be initialized;

\item
if the class is a union-like class, but is not a union, for each of its anonymous union
members having variant members, exactly one of them shall be initialized;

\item
for a non-delegating constructor, every constructor selected to initialize non-static
data members and base class subobjects shall be a constexpr constructor;

\item
for a delegating constructor, the target constructor shall be a constexpr
constructor.
\end{itemize}

\begin{example}
\begin{codeblock}
struct Length {
  constexpr explicit Length(int i = 0) : val(i) { }
private:
  int val;
};
\end{codeblock}
\end{example}

\pnum
For a constexpr function or constexpr constructor
that is neither defaulted nor a template,
if no argument values exist such that
an invocation of the function or constructor could be an evaluated subexpression of a
\deflinkx{core constant expression}{expression!core constant}{\ref{expr.const}}, or,
for a constructor, a constant initializer for some object\iref{basic.start.static},
the program is ill-formed, no diagnostic required.
\begin{example}
\begin{codeblock}
constexpr int f(bool b)
  { return b ? throw 0 : 0; }           // OK
constexpr int f() { return f(true); }   // ill-formed, no diagnostic required

struct B {
  constexpr B(int x) : i(0) { }         // \tcode{x} is unused
  int i;
};

int global;

struct D : B {
  constexpr D() : B(global) { }         // ill-formed, no diagnostic required
                                        // lvalue-to-rvalue conversion on non-constant \tcode{global}
};
\end{codeblock}
\end{example}

\pnum
If the instantiated template specialization of a constexpr function
template
or member function of a class template
would fail to satisfy the requirements for a constexpr
function or constexpr constructor,
that specialization is still a constexpr function or constexpr
constructor, even though a call to such a function cannot appear in a constant
expression. If no specialization of the template would satisfy the
requirements for a constexpr function or constexpr constructor
when considered as a non-template function or constructor, the template is
ill-formed, no diagnostic required.

\pnum
A call to a constexpr function produces the same result as a call to an equivalent
non-constexpr function in all respects except that
\begin{itemize}
\item
a call to a constexpr
function can appear in a \deflink{constant expression}{\ref{expr.const}} and
\item
copy elision is mandatory in a constant expression\iref{class.copy}.
\end{itemize}

\pnum
The \tcode{constexpr} specifier has no
effect on the type of a constexpr function or a constexpr constructor.  \begin{example}
\begin{codeblock}
constexpr int bar(int x, int y)         // OK
    { return x + y + x*y; }
// ...
int bar(int x, int y)                   // error: redefinition of \tcode{bar}
    { return x * 2 + 3 * y; }
\end{codeblock}
\end{example}

\pnum
A \tcode{constexpr} specifier used in an object declaration
declares the object as const.
Such an object
shall have literal type and
shall be initialized.
In any \tcode{constexpr} variable declaration,
the full-expression of the initialization
shall be a \link{constant expression}{\ref{expr.const}}.
\begin{example}
\begin{codeblock}
struct pixel {
  int x, y;
};
constexpr pixel ur = { 1294, 1024 };    // OK
constexpr pixel origin;                 // error: initializer missing
\end{codeblock}
\end{example}

\rSec2[dcl.inline]{The \tcode{inline} specifier}%
\indextext{specifier!\idxcode{inline}}

\pnum
The \tcode{inline} specifier can be applied only to the declaration
or definition of a variable or function.

\pnum
\indextext{specifier!\idxcode{inline}}%
\indextext{inline function}%
A function declaration~(\ref{dcl.fct}, \ref{class.mfct},
\ref{class.friend}) with an \tcode{inline} specifier declares an
\defnx{inline function}{function!inline}. The inline specifier indicates to
the implementation that inline substitution of the function body at the
point of call is to be preferred to the usual function call mechanism.
An implementation is not required to perform this inline substitution at
the point of call; however, even if this inline substitution is omitted,
the other rules for inline functions specified in this subclause shall
still be respected.

\pnum
A variable declaration with an \tcode{inline} specifier declares an
\defnx{inline variable}{variable!inline}.

\pnum
A function defined within a class definition is an inline function.

\pnum
The \tcode{inline} specifier shall not appear on a block scope
declaration.\footnote{The \tcode{inline} keyword has no effect on the linkage of a function.}
If the \tcode{inline} specifier is used in a friend function declaration, that
declaration shall be a definition or the function shall have previously
been declared inline.

\pnum
An inline function or variable shall be defined in every translation unit in which
it is odr-used and shall have exactly the same definition in every
case\iref{basic.def.odr}.
\begin{note}
A call to the inline function or a use of the inline variable may be encountered before its definition
appears in the translation unit.
\end{note}
If the definition of a function or variable appears in a translation unit before its
first declaration as inline, the program is ill-formed. If a function or variable
with external linkage is declared inline in one translation unit, it
shall be declared inline in all translation units in which it appears;
no diagnostic is required. An inline function or variable with external
linkage shall have the same address in all translation units.
\begin{note}
A \tcode{static} local variable in an inline
function with external linkage always refers to the same object.
A type defined within the body of an inline
function with external linkage is the
same type in every translation unit.
\end{note}

\rSec2[dcl.type]{Type specifiers}%
\indextext{specifier!type|see{type specifier}}

\pnum
The type-specifiers are

\indextext{type!\idxcode{const}}%
\indextext{type!\idxcode{volatile}}%
%
\begin{bnf}
\nontermdef{type-specifier}\br
  simple-type-specifier\br
  elaborated-type-specifier\br
  typename-specifier\br
  cv-qualifier
\end{bnf}

\begin{bnf}
\nontermdef{type-specifier-seq}\br
    type-specifier \opt{attribute-specifier-seq}\br
    type-specifier type-specifier-seq
\end{bnf}

\begin{bnf}
\nontermdef{defining-type-specifier}\br
    type-specifier\br
    class-specifier\br
    enum-specifier
\end{bnf}

\begin{bnf}
\nontermdef{defining-type-specifier-seq}\br
  defining-type-specifier \opt{attribute-specifier-seq}\br
  defining-type-specifier defining-type-specifier-seq
\end{bnf}

The optional \grammarterm{attribute-specifier-seq} in a \grammarterm{type-specifier-seq}
or a \grammarterm{defining-type-specifier-seq}
appertains
to the type denoted by the preceding \grammarterm{type-specifier}{s}
or \grammarterm{defining-type-specifier}{s}\iref{dcl.meaning}. The
\grammarterm{attribute-specifier-seq} affects the type only for the declaration it appears in,
not other declarations involving the same type.

\pnum
As a general rule, at most one
\grammarterm{defining-type-specifier}
is allowed in the complete
\grammarterm{decl-specifier-seq} of a \grammarterm{declaration} or in a
\grammarterm{defining-type-specifier-seq},
and at most one
\grammarterm{type-specifier}
is allowed in a
\grammarterm{type-specifier-seq}.
The only exceptions to this rule are the following:
\begin{itemize}
\item \tcode{const} can be combined with any type specifier except itself.

\item \tcode{volatile} can be combined with any type specifier except itself.

\item \tcode{signed} or \tcode{unsigned} can be combined with
\tcode{char}, \tcode{long}, \tcode{short}, or \tcode{int}.

\item \tcode{short} or \tcode{long} can be combined with \tcode{int}.

\item \tcode{long} can be combined with \tcode{double}.

\item \tcode{long} can be combined with \tcode{long}.
\end{itemize}

\pnum
Except in a declaration of a constructor, destructor, or conversion
function, at least one \grammarterm{defining-type-specifier} that is not a
\grammarterm{cv-qualifier} shall appear in a complete
\grammarterm{type-specifier-seq} or a complete
\grammarterm{decl-specifier-seq}.\footnote{There is no special
provision for a \grammarterm{decl-specifier-seq} that
lacks a \grammarterm{type-specifier} or that has a
\grammarterm{type-specifier} that only specifies \grammarterm{cv-qualifier}{s}.
The ``implicit int'' rule of C is no longer supported.}

\pnum
\begin{note}
\grammarterm{enum-specifier}{s},
\grammarterm{class-specifier}{s},
and
\grammarterm{typename-specifier}{s}
are discussed
in
\ref{dcl.enum},
\ref{class},
and
\ref{temp.res}, respectively. The remaining
\grammarterm{type-specifier}{s} are discussed in the rest of this subclause.
\end{note}

\rSec3[dcl.type.cv]{The \fakegrammarterm{cv-qualifier}{s}}%
\indextext{specifier!cv-qualifier}%
\indextext{initialization!\idxcode{const}}%
\indextext{type specifier!\idxcode{const}}%
\indextext{type specifier!\idxcode{volatile}}

\pnum
There are two \grammarterm{cv-qualifier}{s}, \tcode{const} and
\tcode{volatile}. Each \grammarterm{cv-qualifier} shall appear at most once in
a \grammarterm{cv-qualifier-seq}. If a \grammarterm{cv-qualifier} appears in a
\grammarterm{decl-specifier-seq}, the \grammarterm{init-declarator-list}
or \grammarterm{member-declarator-list} of
the declaration shall not be empty.
\begin{note}
\ref{basic.type.qualifier} and \ref{dcl.fct} describe how cv-qualifiers affect object and
function types.
\end{note}
Redundant cv-qualifications are ignored. \begin{note} For example,
these could be introduced by typedefs.\end{note}

\pnum
\begin{note}
Declaring a variable \tcode{const} can affect its linkage\iref{dcl.stc}
and its usability in \link{constant expressions}{\ref{expr.const}}. As
described in~\ref{dcl.init}, the definition of an object or subobject
of const-qualified type must specify an initializer or be subject to
default-initialization.
\end{note}

\pnum
A pointer or reference to a cv-qualified type need not actually point or
refer to a cv-qualified object, but it is treated as if it does; a
const-qualified access path cannot be used to modify an object even if
the object referenced is a non-const object and can be modified through
some other access path.
\begin{note}
Cv-qualifiers are supported by the type system so that they cannot be
subverted without \link{casting}{\ref{expr.const.cast}}.
\end{note}

\pnum
\indextext{const object!undefined change to}%
Except that any class member declared \linkx{\tcode{mutable}}{\idxcode{mutable}}{\ref{dcl.stc}}
can be modified, any attempt to modify a const object during its
\deflink{lifetime}{\ref{basic.life}} results in undefined behavior.
\begin{example}
\begin{codeblock}
const int ci = 3;                       // cv-qualified (initialized as required)
ci = 4;                                 // ill-formed: attempt to modify \tcode{const}

int i = 2;                              // not cv-qualified
const int* cip;                         // pointer to \tcode{const int}
cip = &i;                               // OK: cv-qualified access path to unqualified
*cip = 4;                               // ill-formed: attempt to modify through ptr to \tcode{const}

int* ip;
ip = const_cast<int*>(cip);             // cast needed to convert \tcode{const int*} to \tcode{int*}
*ip = 4;                                // defined: \tcode{*ip} points to \tcode{i}, a non-const object

const int* ciq = new const int (3);     // initialized as required
int* iq = const_cast<int*>(ciq);        // cast required
*iq = 4;                                // undefined: modifies a const object
\end{codeblock}
For another example,
\begin{codeblock}
struct X {
  mutable int i;
  int j;
};
struct Y {
  X x;
  Y();
};

const Y y;
y.x.i++;                                // well-formed: \tcode{mutable} member can be modified
y.x.j++;                                // ill-formed: const-qualified member modified
Y* p = const_cast<Y*>(&y);              // cast away const-ness of \tcode{y}
p->x.i = 99;                            // well-formed: \tcode{mutable} member can be modified
p->x.j = 99;                            // undefined: modifies a const subobject
\end{codeblock}
\end{example}

\pnum
The semantics of an access through a volatile glvalue are
\impldef{semantics of an access through a volatile glvalue}.
If an attempt is made to access an object defined with a
volatile-qualified type through the use of a non-volatile glvalue,
the behavior is undefined.

\pnum
\indextext{type specifier!\idxcode{volatile}}%
\indextext{\idxcode{volatile}!implementation-defined}%
\begin{note}
\tcode{volatile} is a hint to the implementation to avoid aggressive
optimization involving the object because the value of the object might
be changed by means undetectable by an implementation.
Furthermore, for some implementations, \tcode{volatile} might indicate that
special hardware instructions are required to access the object.
See~\ref{intro.execution} for detailed semantics. In general, the
semantics of \tcode{volatile} are intended to be the same in \Cpp{} as
they are in C.
\end{note}

\rSec3[dcl.type.simple]{Simple type specifiers}%
\indextext{type specifier!simple}

\pnum
The simple type specifiers are
\begin{bnf}
\nontermdef{simple-type-specifier}\br
    \opt{nested-name-specifier} type-name\br
    nested-name-specifier \terminal{template} simple-template-id\br
    \opt{nested-name-specifier} template-name\br
    \terminal{char}\br
    \terminal{char16_t}\br
    \terminal{char32_t}\br
    \terminal{wchar_t}\br
    \terminal{bool}\br
    \terminal{short}\br
    \terminal{int}\br
    \terminal{long}\br
    \terminal{signed}\br
    \terminal{unsigned}\br
    \terminal{float}\br
    \terminal{double}\br
    \terminal{void}\br
    \terminal{auto}\br
    decltype-specifier
\end{bnf}

\begin{bnf}
\nontermdef{type-name}\br
    class-name\br
    enum-name\br
    typedef-name\br
    simple-template-id
\end{bnf}

\begin{bnf}
\nontermdef{decltype-specifier}\br
  \terminal{decltype} \terminal{(} expression \terminal{)}\br
  \terminal{decltype} \terminal{(} \terminal{auto} \terminal{)}
\end{bnf}

\pnum
\indextext{type specifier!\idxcode{char}}%
\indextext{type specifier!\idxcode{char16_t}}%
\indextext{type specifier!\idxcode{char32_t}}%
\indextext{type specifier!\idxcode{wchar_t}}%
\indextext{type specifier!\idxcode{bool}}%
\indextext{type specifier!\idxcode{short}}%
\indextext{type specifier!\idxcode{int}}%
\indextext{type specifier!\idxcode{long}}%
\indextext{type specifier!\idxcode{signed}}%
\indextext{type specifier!\idxcode{unsigned}}%
\indextext{type specifier!\idxcode{float}}%
\indextext{type specifier!\idxcode{double}}%
\indextext{type specifier!\idxcode{void}}%
\indextext{type specifier!\idxcode{auto}}%
\indextext{type specifier!\idxcode{decltype}}%
\indextext{\idxgram{type-name}}%
\indextext{\idxgram{lambda-introducer}}%
The \grammarterm{simple-type-specifier} \tcode{auto}
is a placeholder for
a type to be deduced\iref{dcl.spec.auto}.
\indextext{deduction!class template arguments}%
A \grammarterm{type-specifier} of the form
\opt{\tcode{typename}} \opt{\grammarterm{nested-name-specifier}} \grammarterm{template-name}
is a placeholder for
a deduced class type\iref{dcl.type.class.deduct}.
The \grammarterm{template-name} shall name a class template
that is not an injected-class-name.
The other
\grammarterm{simple-type-specifier}{s}
specify either a previously-declared type, a type determined from an
expression, or one of the
fundamental types\iref{basic.fundamental}.
\tref{simple.type.specifiers}
 summarizes the valid combinations of
\grammarterm{simple-type-specifier}{s}
and the types they specify.

\begin{simpletypetable}
{\grammarterm{simple-type-specifier}{s} and the types they specify}
{tab:simple.type.specifiers}
{ll}
\topline
\hdstyle{Specifier(s)}            &   \hdstyle{Type}                  \\ \capsep
\grammarterm{type-name}           & the type named                    \\
\grammarterm{simple-template-id}  & the type as defined in~\ref{temp.names}\\
\grammarterm{template-name}       & placeholder for a type to be deduced\\
\tcode{char}                      & ``\tcode{char}''                  \\
\tcode{unsigned char}             & ``\tcode{unsigned char}''         \\
\tcode{signed char}               & ``\tcode{signed char}''           \\
\tcode{char16_t}                  & ``\tcode{char16_t}''              \\
\tcode{char32_t}                  & ``\tcode{char32_t}''              \\
\tcode{bool}                      & ``\tcode{bool}''                  \\
\tcode{unsigned}                  & ``\tcode{unsigned int}''          \\
\tcode{unsigned int}              & ``\tcode{unsigned int}''          \\
\tcode{signed}                    & ``\tcode{int}''                   \\
\tcode{signed int}                & ``\tcode{int}''                   \\
\tcode{int}                       & ``\tcode{int}''                   \\
\tcode{unsigned short int}        & ``\tcode{unsigned short int}''    \\
\tcode{unsigned short}            & ``\tcode{unsigned short int}''    \\
\tcode{unsigned long int}         & ``\tcode{unsigned long int}''     \\
\tcode{unsigned long}             & ``\tcode{unsigned long int}''     \\
\tcode{unsigned long long int}    & ``\tcode{unsigned long long int}''\\
\tcode{unsigned long long}        & ``\tcode{unsigned long long int}''\\
\tcode{signed long int}           & ``\tcode{long int}''              \\
\tcode{signed long}               & ``\tcode{long int}''              \\
\tcode{signed long long int}      & ``\tcode{long long int}''         \\
\tcode{signed long long}          & ``\tcode{long long int}''         \\
\tcode{long long int}             & ``\tcode{long long int}''         \\
\tcode{long long}                 & ``\tcode{long long int}''         \\
\tcode{long int}                  & ``\tcode{long int}''              \\
\tcode{long}                      & ``\tcode{long int}''              \\
\tcode{signed short int}          & ``\tcode{short int}''             \\
\tcode{signed short}              & ``\tcode{short int}''             \\
\tcode{short int}                 & ``\tcode{short int}''             \\
\tcode{short}                     & ``\tcode{short int}''             \\
\tcode{wchar_t}                   & ``\tcode{wchar_t}''               \\
\tcode{float}                     & ``\tcode{float}''                 \\
\tcode{double}                    & ``\tcode{double}''                \\
\tcode{long double}               & ``\tcode{long double}''           \\
\tcode{void}                      & ``\tcode{void}''                  \\
\tcode{auto}                      & placeholder for a type to be deduced\\
\tcode{decltype(auto)}            & placeholder for a type to be deduced\\
\tcode{decltype(}\grammartermnc{expression}\tcode{)}
                                  & the type as defined below\\
\end{simpletypetable}

\pnum
When multiple \grammarterm{simple-type-specifier}{s} are allowed, they can be
freely intermixed with other \grammarterm{decl-specifier}{s} in any order.
\begin{note}
It is \impldef{signedness of \tcode{char}} whether objects of \tcode{char} type are
represented as signed or unsigned quantities. The \tcode{signed} specifier
forces \tcode{char} objects to be signed; it is redundant in other contexts.
\end{note}

\pnum
\indextext{type specifier!\idxcode{decltype}}%
For an expression \tcode{e}, the type denoted by \tcode{decltype(e)} is defined as follows:

\begin{itemize}
\item if \tcode{e} is an unparenthesized \grammarterm{id-expression}
naming a structured binding\iref{dcl.struct.bind},
\tcode{decltype(e)} is the referenced type as given in
the specification of the structured binding declaration;

\item otherwise, if \tcode{e} is an unparenthesized \grammarterm{id-expression} or
an unparenthesized
\link{class member access}{\ref{expr.ref}}, \tcode{decltype(e)} is the
type of the entity named by \tcode{e}. If there is no such entity, or
if \tcode{e} names a set of overloaded functions, the program is
ill-formed;

\item otherwise, if \tcode{e} is
an xvalue, \tcode{decltype(e)} is \tcode{T\&\&}, where \tcode{T} is the type
of \tcode{e};

\item otherwise, if \tcode{e} is an lvalue, \tcode{decltype(e)}
is \tcode{T\&}, where \tcode{T} is the type of \tcode{e};

\item otherwise, \tcode{decltype(e)} is the type of \tcode{e}.
\end{itemize}

The operand of the \tcode{decltype} specifier is an
\deflink{unevaluated operand}{\ref{expr.prop}}.

\begin{example}
\begin{codeblock}
const int&& foo();
int i;
struct A { double x; };
const A* a = new A();
decltype(foo()) x1 = 17;        // type is \tcode{const int\&\&}
decltype(i) x2;                 // type is \tcode{int}
decltype(a->x) x3;              // type is \tcode{double}
decltype((a->x)) x4 = x3;       // type is \tcode{const double\&}
\end{codeblock}
\end{example}
\begin{note}
The rules for determining types involving \tcode{decltype(auto)} are specified
in~\ref{dcl.spec.auto}.
\end{note}

\pnum
If the operand of a \grammarterm{decltype-specifier} is a prvalue,
the \link{temporary materialization conversion}{\ref{conv.rval}} is not applied
and no result object is provided for the prvalue.
The type of the prvalue may be incomplete.
\begin{note}
As a result, storage is not allocated for the prvalue and it is not destroyed.
Thus, a class type is not instantiated
as a result of being the type of a function call in this context.
In this context, the common purpose of
writing the expression is merely to refer to its type. In that sense, a
\grammarterm{decltype-specifier} is analogous to a use of a \grammarterm{typedef-name},
so the usual reasons for requiring a complete type do not apply. In particular,
it is not necessary to allocate storage for a temporary object or to enforce the
semantic constraints associated with invoking the type's destructor.
\end{note}
\begin{note}
Unlike the preceding rule, parentheses have no special meaning in this context.
\end{note}
\begin{example}
\begin{codeblock}
template<class T> struct A { ~A() = delete; };
template<class T> auto h()
  -> A<T>;
template<class T> auto i(T)     // identity
  -> T;
template<class T> auto f(T)     // \#1
  -> decltype(i(h<T>()));       // forces completion of \tcode{A<T>} and implicitly uses \tcode{A<T>::\~{}A()}
                                // for the temporary introduced by the use of \tcode{h()}.
                                // (A temporary is not introduced as a result of the use of \tcode{i()}.)
template<class T> auto f(T)     // \#2
  -> void;
auto g() -> void {
  f(42);                        // OK: calls \#2. (\#1 is not a viable candidate: type deduction
                                // fails\iref{temp.deduct} because \tcode{A<int>::\~{}A()} is implicitly used in its
                                // \grammarterm{decltype-specifier})
}
template<class T> auto q(T)
  -> decltype((h<T>()));        // does not force completion of \tcode{A<T>}; \tcode{A<T>::\~{}A()} is not implicitly
                                // used within the context of this \grammarterm{decltype-specifier}
void r() {
  q(42);                        // error: deduction against \tcode{q} succeeds, so overload resolution selects
                                // the specialization ``\tcode{q(T) -> decltype((h<T>()))}'' with \tcode{T}$=$\tcode{int};
                                // the return type is \tcode{A<int>}, so a temporary is introduced and its
                                // destructor is used, so the program is ill-formed
}
\end{codeblock}
\end{example}

\rSec3[dcl.type.elab]{Elaborated type specifiers}%
\indextext{type specifier!elaborated}%
\indextext{\idxcode{typename}}%
\indextext{type specifier!\idxcode{enum}}

\begin{bnf}
\nontermdef{elaborated-type-specifier}\br
    class-key \opt{attribute-specifier-seq} \opt{nested-name-specifier} identifier\br
    class-key simple-template-id\br
    class-key nested-name-specifier \opt{\terminal{template}} simple-template-id\br
    \terminal{enum} \opt{nested-name-specifier} identifier
\end{bnf}

\pnum
\indextext{class name!elaborated}%
\indextext{name!elaborated!\idxcode{enum}}%
An \grammarterm{attribute-specifier-seq} shall not appear in an \grammarterm{elaborated-type-specifier}
unless the latter is the sole constituent of a declaration.
If an \grammarterm{elaborated-type-specifier} is the sole constituent of a
declaration, the declaration is ill-formed unless it is an \link{explicit
specialization}{\ref{temp.expl.spec}}, an \link{explicit
instantiation}{\ref{temp.explicit}} or it has one of the following
forms:

\begin{ncsimplebnf}
class-key \opt{attribute-specifier-seq} identifier \terminal{;}\br
\terminal{friend} class-key \terminal{\opt{::}} identifier \terminal{;}\br
\terminal{friend} class-key \terminal{\opt{::}} simple-template-id \terminal{;}\br
\terminal{friend} class-key nested-name-specifier identifier \terminal{;}\br
\terminal{friend} class-key nested-name-specifier \terminal{\opt{template}} simple-template-id \terminal{;}
\end{ncsimplebnf}

In the first case, the \grammarterm{attribute-specifier-seq}, if any, appertains
to the class being declared; the attributes in the
\grammarterm{attribute-specifier-seq} are thereafter considered attributes of
the class whenever it is named.

\pnum
\ref{basic.lookup.elab} describes how name lookup proceeds for the
\grammarterm{identifier} in an \grammarterm{elaborated-type-specifier}. If the
\grammarterm{identifier} resolves to a \grammarterm{class-name} or
\grammarterm{enum-name}, the \grammarterm{elaborated-type-specifier}
introduces it into the declaration the same way a
\grammarterm{simple-type-specifier} introduces its \grammarterm{type-name}. If
the \grammarterm{identifier} resolves to a
\grammarterm{typedef-name} or the \grammarterm{simple-template-id} resolves to
an alias template specialization,
the
\grammarterm{elaborated-type-specifier} is ill-formed.
\begin{note}
This implies that, within a class template with a template
\grammarterm{type-parameter} \tcode{T}, the declaration
\begin{codeblock}
friend class T;
\end{codeblock}
is ill-formed. However, the similar declaration \tcode{friend T;} is allowed\iref{class.friend}.
\end{note}

\pnum
The \grammarterm{class-key} or \tcode{enum} keyword
present in the
\grammarterm{elaborated-type-specifier} shall agree in kind with the
declaration to which the name in the
\grammarterm{elaborated-type-specifier} refers. This rule also applies to
the form of \grammarterm{elaborated-type-specifier} that declares a
\grammarterm{class-name} or friend class since it can be construed
as referring to the definition of the class. Thus, in any
\grammarterm{elaborated-type-specifier}, the \tcode{enum} keyword
shall be
used to refer to an \link{enumeration}{\ref{dcl.enum}}, the \tcode{union}
\grammarterm{class-key} shall be used to refer to a \deflink{union}{\ref{class}},
and either the \tcode{class} or \tcode{struct}
\grammarterm{class-key} shall be used to refer to a \link{class}{\ref{class}}
declared using the \tcode{class} or \tcode{struct}
\grammarterm{class-key}. \begin{example}
\begin{codeblock}
enum class E { a, b };
enum E x = E::a;                // OK
\end{codeblock}
\end{example}

\rSec3[dcl.spec.auto]{The \tcode{auto} specifier}%
\indextext{type specifier!\idxcode{auto}}

\pnum
The \tcode{auto} and \tcode{decltype(auto)} \grammarterm{type-specifier}{s}
are used to
designate a placeholder type that will be replaced later by deduction
from an initializer. The \tcode{auto}
\grammarterm{type-specifier} is also used to
introduce a function type having a \grammarterm{trailing-return-type} or to
signify that a lambda is a generic lambda\iref{expr.prim.lambda}.
The \tcode{auto} \grammarterm{type-specifier} is also used to introduce a
\link{structured binding declaration}{\ref{dcl.struct.bind}}.

\pnum
The placeholder type can appear with a function declarator in the
\grammarterm{decl-specifier-seq}, \grammarterm{type-specifier-seq},
\grammarterm{conversion-function-id}, or \grammarterm{trailing-return-type},
in any context where such a declarator is valid. If the function declarator
includes a \grammarterm{trailing-return-type}\iref{dcl.fct}, that
\grammarterm{trailing-return-type} specifies
the declared return type of the function. Otherwise, the function declarator
shall declare a function. If the declared return type of the
function contains a placeholder type, the return type of the function is
deduced from non-discarded \tcode{return} statements, if any, in the body
of the function\iref{stmt.if}.

\pnum
The type of a variable declared using \tcode{auto} or \tcode{decltype(auto)} is
deduced from its initializer.
This use is allowed
in an initializing declaration\iref{dcl.init} of a variable.
\tcode{auto} or \tcode{decltype(auto)} shall appear as one of the
\grammarterm{decl-specifier}{s} in the
\grammarterm{decl-specifier-seq} and the
\grammarterm{decl-specifier-seq}
shall be followed by one or more
\grammarterm{declarator}{s},
each of which shall
be followed by a non-empty
\grammarterm{initializer}.
In an \grammarterm{initializer} of the form
\begin{codeblock}
( @\textrm{\grammarterm{expression-list}}@ )
\end{codeblock}
the \grammarterm{expression-list} shall be a single
\grammarterm{assignment-expression}.
\begin{example}
\begin{codeblock}
auto x = 5;                     // OK: \tcode{x} has type \tcode{int}
const auto *v = &x, u = 6;      // OK: \tcode{v} has type \tcode{const int*}, \tcode{u} has type \tcode{const int}
static auto y = 0.0;            // OK: \tcode{y} has type \tcode{double}
auto int r;                     // error: \tcode{auto} is not a \grammarterm{storage-class-specifier}
auto f() -> int;                // OK: \tcode{f} returns \tcode{int}
auto g() { return 0.0; }        // OK: \tcode{g} returns \tcode{double}
auto h();                       // OK: \tcode{h}'s return type will be deduced when it is defined
\end{codeblock}
\end{example}

\pnum
A placeholder type can also be used
in the \grammarterm{type-specifier-seq} in
the \grammarterm{new-type-id} or \grammarterm{type-id} of a
\grammarterm{new-expression}\iref{expr.new}
and as a \grammarterm{decl-specifier}
of the \grammarterm{parameter-declaration}{'s}
\grammarterm{decl-specifier-seq}
in a \grammarterm{template-parameter}\iref{temp.param}.

\pnum
A program that uses \tcode{auto} or \tcode{decltype(auto)} in a context not
explicitly allowed in this subclause is ill-formed.

\pnum
If the \grammarterm{init-declarator-list} contains more than one
\grammarterm{init-declarator}, they shall all form declarations of
variables. The type of each declared variable is determined
by \deflink{placeholder type deduction}{\ref{dcl.type.auto.deduct}},
and if the type that replaces the placeholder type is not the
same in each deduction, the program is ill-formed.

\begin{example}
\begin{codeblock}
auto x = 5, *y = &x;            // OK: \tcode{auto} is \tcode{int}
auto a = 5, b = { 1, 2 };       // error: different types for \tcode{auto}
\end{codeblock}
\end{example}

\pnum
If a function with a declared return type that contains a placeholder type has
multiple non-discarded \tcode{return} statements, the return type is deduced for each
such \tcode{return} statement. If the type deduced is not the same in each
deduction, the program is ill-formed.

\pnum
If a function with a declared return type that uses a placeholder type has no
non-discarded \tcode{return} statements, the return type is deduced as though from a
\tcode{return} statement with no operand at the closing brace of the function
body.
\begin{example}
\begin{codeblock}
auto  f() { }                   // OK, return type is \tcode{void}
auto* g() { }                   // error, cannot deduce \tcode{auto*} from \tcode{void()}
\end{codeblock}
\end{example}

\pnum
If the name of an entity with an undeduced placeholder type appears in an
expression, the program is ill-formed.  Once a
non-discarded \tcode{return} statement has been seen in a function, however, the return type deduced
from that statement can be used in the rest of the function, including in other
\tcode{return} statements.
\begin{example}
\begin{codeblock}
auto n = n;                     // error, \tcode{n}'s initializer refers to \tcode{n}
auto f();
void g() { &f; }                // error, \tcode{f}'s return type is unknown
auto sum(int i) {
  if (i == 1)
    return i;                   // \tcode{sum}'s return type is \tcode{int}
  else
    return sum(i-1)+i;          // OK, \tcode{sum}'s return type has been deduced
}
\end{codeblock}
\end{example}

\pnum
Return type deduction for a function template with a placeholder in its
declared type occurs when the definition is instantiated even if the function
body contains a \tcode{return} statement with a non-type-dependent operand.
\begin{note} Therefore, any use of a specialization of the function template will
cause an implicit instantiation. Any errors that arise from this instantiation
are not in the immediate context of the function type and can result in the
program being ill-formed\iref{temp.deduct}. \end{note}
\begin{example}
\begin{codeblock}
template <class T> auto f(T t) { return t; }    // return type deduced at instantiation time
typedef decltype(f(1)) fint_t;                  // instantiates \tcode{f<int>} to deduce return type
template<class T> auto f(T* t) { return *t; }
void g() { int (*p)(int*) = &f; }               // instantiates both \tcode{f}s to determine return types,
                                                // chooses second
\end{codeblock}
\end{example}

\pnum
Redeclarations or specializations of a function or function template with a
declared return type that uses a placeholder type shall also use that
placeholder, not a deduced type.
Similarly,
redeclarations or specializations of a function or function template with a
declared return type that does not use a placeholder type
shall not use a placeholder.
\begin{example}
\begin{codeblock}
auto f();
auto f() { return 42; }                         // return type is \tcode{int}
auto f();                                       // OK
int f();                                        // error, cannot be overloaded with \tcode{auto f()}
decltype(auto) f();                             // error, \tcode{auto} and \tcode{decltype(auto)} don't match

template <typename T> auto g(T t) { return t; } // \#1
template auto g(int);                           // OK, return type is \tcode{int}
template char g(char);                          // error, no matching template
template<> auto g(double);                      // OK, forward declaration with unknown return type

template <class T> T g(T t) { return t; }       // OK, not functionally equivalent to \#1
template char g(char);                          // OK, now there is a matching template
template auto g(float);                         // still matches \#1

void h() { return g(42); }                      // error, ambiguous

template <typename T> struct A {
  friend T frf(T);
};
auto frf(int i) { return i; }                   // not a friend of \tcode{A<int>}
\end{codeblock}
\end{example}

\pnum
A function declared with a return type that uses a placeholder type shall not
be \link{\tcode{virtual}}{\ref{class.virtual}}.

\pnum
An \link{explicit instantiation declaration}{\ref{temp.explicit}} does not cause the
instantiation of an entity declared using a placeholder type, but it also does
not prevent that entity from being instantiated as needed to determine its
type.
\begin{example}
\begin{codeblock}
template <typename T> auto f(T t) { return t; }
extern template auto f(int);    // does not instantiate \tcode{f<int>}
int (*p)(int) = f;              // instantiates \tcode{f<int>} to determine its return type, but an explicit
                                // instantiation definition is still required somewhere in the program
\end{codeblock}
\end{example}

\rSec4[dcl.type.auto.deduct]{Placeholder type deduction}
\indextext{deduction!placeholder type}%

\pnum
\defnx{Placeholder type deduction}{placeholder type deduction}
is the process by which
a type containing a placeholder type
is replaced by a deduced type.

\pnum
A type \tcode{T} containing a placeholder type,
and a corresponding initializer \tcode{e},
are determined as follows:

\begin{itemize}
\item
for a non-discarded \tcode{return} statement that occurs
in a function declared with a return type
that contains a placeholder type,
\tcode{T} is the declared return type
and \tcode{e} is the operand of the \tcode{return} statement.
If the \tcode{return} statement
has no operand,
then \tcode{e} is \tcode{void()};
\item
for a variable declared with a type
that contains a placeholder type,
\tcode{T} is the declared type of the variable
and \tcode{e} is the initializer.
If the initialization is direct-list-initialization,
the initializer shall be a \grammarterm{braced-init-list}
containing only a single \grammarterm{assignment-expression}
and \tcode{e} is the \grammarterm{assignment-expression};
\item
for a non-type template parameter declared with a type
that contains a placeholder type,
\tcode{T} is the declared type of the non-type template parameter
and \tcode{e} is the corresponding template argument.
\end{itemize}

In the case of a \tcode{return} statement with no operand
or with an operand of type \tcode{void},
\tcode{T} shall be either
\tcode{decltype(auto)} or \cv{}~\tcode{auto}.

\pnum
If the deduction is for a \tcode{return} statement
and \tcode{e} is a \grammarterm{braced-init-list}\iref{dcl.init.list},
the program is ill-formed.

\pnum
If the placeholder is the \tcode{auto} \grammarterm{type-specifier}, the
deduced type
$\mathtt{T}'$ replacing \tcode{T}
is determined using the rules for template argument deduction.
Obtain \tcode{P} from
\tcode{T} by replacing the occurrences of \tcode{auto} with either a new
invented type template parameter \tcode{U} or,
if the initialization is copy-list-initialization, with
\tcode{std::initializer_list<U>}. Deduce a value for \tcode{U} using the rules
of \link{template argument deduction from a function call}{\ref{temp.deduct.call}},
where \tcode{P} is a
function template parameter type and
the corresponding argument is \tcode{e}.
If the deduction fails, the declaration is ill-formed.
Otherwise, $\mathtt{T}'$ is obtained by
substituting the deduced \tcode{U} into \tcode{P}.
\begin{example}
\begin{codeblock}
auto x1 = { 1, 2 };             // \tcode{decltype(x1)} is \tcode{std::initializer_list<int>}
auto x2 = { 1, 2.0 };           // error: cannot deduce element type
auto x3{ 1, 2 };                // error: not a single element
auto x4 = { 3 };                // \tcode{decltype(x4)} is \tcode{std::initializer_list<int>}
auto x5{ 3 };                   // \tcode{decltype(x5)} is \tcode{int}
\end{codeblock}
\end{example}

\begin{example}
\begin{codeblock}
const auto &i = expr;
\end{codeblock}
The type of \tcode{i} is the deduced type of the parameter \tcode{u} in
the call \tcode{f(expr)} of the following invented function template:
\begin{codeblock}
template <class U> void f(const U& u);
\end{codeblock}
\end{example}

\pnum
If the placeholder is the \tcode{decltype(auto)} \grammarterm{type-specifier},
\tcode{T} shall be the
placeholder alone. The type deduced for \tcode{T} is
determined as described in~\ref{dcl.type.simple}, as though
\tcode{e} had
been the operand of the \tcode{decltype}. \begin{example}
\begin{codeblock}
int i;
int&& f();
auto           x2a(i);          // \tcode{decltype(x2a)} is \tcode{int}
decltype(auto) x2d(i);          // \tcode{decltype(x2d)} is \tcode{int}
auto           x3a = i;         // \tcode{decltype(x3a)} is \tcode{int}
decltype(auto) x3d = i;         // \tcode{decltype(x3d)} is \tcode{int}
auto           x4a = (i);       // \tcode{decltype(x4a)} is \tcode{int}
decltype(auto) x4d = (i);       // \tcode{decltype(x4d)} is \tcode{int\&}
auto           x5a = f();       // \tcode{decltype(x5a)} is \tcode{int}
decltype(auto) x5d = f();       // \tcode{decltype(x5d)} is \tcode{int\&\&}
auto           x6a = { 1, 2 };  // \tcode{decltype(x6a)} is \tcode{std::initializer_list<int>}
decltype(auto) x6d = { 1, 2 };  // error, \tcode{\{ 1, 2 \}} is not an expression
auto          *x7a = &i;        // \tcode{decltype(x7a)} is \tcode{int*}
decltype(auto)*x7d = &i;        // error, declared type is not plain \tcode{decltype(auto)}
\end{codeblock}
\end{example}

\rSec3[dcl.type.class.deduct]{Deduced class template specialization types}
\indextext{deduction!class template arguments}%

\pnum
If a placeholder for a deduced class type
appears as a \grammarterm{decl-specifier}
in the \grammarterm{decl-specifier-seq}
of an initializing declaration\iref{dcl.init} of a variable,
the placeholder is replaced by the return type
of the function selected by overload resolution
for class template deduction\iref{over.match.class.deduct}.
If the \grammarterm{decl-specifier-seq}
is followed by an \grammarterm{init-declarator-list}
or \grammarterm{member-declarator-list}
containing more than one \grammarterm{declarator},
the type that replaces the placeholder shall be the same in each deduction.

\pnum
A placeholder for a deduced class type
can also be used
in the \grammarterm{type-specifier-seq}
in the \grammarterm{new-type-id} or \grammarterm{type-id}
of a \grammarterm{new-expression}\iref{expr.new},
or
as the \grammarterm{simple-type-specifier}
in an \link{explicit type conversion (functional notation)}{\ref{expr.type.conv}}.
A placeholder for a deduced class type
shall not appear in any other context.

\pnum
\begin{example}
\begin{codeblock}
template<class T> struct container {
    container(T t) {}
    template<class Iter> container(Iter beg, Iter end);
};
template<class Iter>
container(Iter b, Iter e) -> container<typename std::iterator_traits<Iter>::value_type>;
std::vector<double> v = { @\commentellip@ };

container c(7);                         // OK, deduces \tcode{int} for \tcode{T}
auto d = container(v.begin(), v.end()); // OK, deduces \tcode{double} for \tcode{T}
container e{5, 6};                      // error, \tcode{int} is not an iterator
\end{codeblock}
\end{example}
\indextext{specifier|)}%

\rSec1[dcl.enum]{Enumeration declarations}%
\indextext{enumeration}%
\indextext{\idxcode{\{\}}!enum declaration@\tcode{enum} declaration}%
\indextext{\idxcode{enum}!type of}

\pnum
An enumeration is a distinct type\iref{basic.compound} with named
constants. Its name becomes an \grammarterm{enum-name} within its scope.

\begin{bnf}
\nontermdef{enum-name}\br
    identifier
\end{bnf}

\begin{bnf}
\nontermdef{enum-specifier}\br
    enum-head \terminal{\{} \opt{enumerator-list} \terminal{\}}\br
    enum-head \terminal{\{} enumerator-list \terminal{, \}}
\end{bnf}

\begin{bnf}
\nontermdef{enum-head}\br
    enum-key \opt{attribute-specifier-seq} \opt{enum-head-name} \opt{enum-base}
\end{bnf}

\begin{bnf}
\nontermdef{enum-head-name}\br
    \opt{nested-name-specifier} identifier
\end{bnf}

\begin{bnf}
\nontermdef{opaque-enum-declaration}\br
    enum-key \opt{attribute-specifier-seq} \opt{nested-name-specifier} identifier \opt{enum-base} \terminal{;}
\end{bnf}

\begin{bnf}
\nontermdef{enum-key}\br
    \terminal{enum}\br
    \terminal{enum class}\br
    \terminal{enum struct}
\end{bnf}

\begin{bnf}
\nontermdef{enum-base}\br
    \terminal{:} type-specifier-seq
\end{bnf}

\begin{bnf}
\nontermdef{enumerator-list}\br
    enumerator-definition\br
    enumerator-list \terminal{,} enumerator-definition
\end{bnf}

\begin{bnf}
\nontermdef{enumerator-definition}\br
    enumerator\br
    enumerator \terminal{=} constant-expression
\end{bnf}

\begin{bnf}
\nontermdef{enumerator}\br
    identifier \opt{attribute-specifier-seq}
\end{bnf}

The optional \grammarterm{attribute-specifier-seq} in the \grammarterm{enum-head} and
the \grammarterm{opaque-enum-declaration} appertains to the enumeration; the attributes
in that \grammarterm{attribute-specifier-seq} are thereafter considered attributes of the
enumeration whenever it is named.
A \tcode{:} following
``\tcode{enum} \opt{\grammarterm{nested-name-specifier}} \grammarterm{identifier}''
within the \grammarterm{decl-specifier-seq} of a \grammarterm{member-declaration}
is parsed as part of an \grammarterm{enum-base}.
\begin{note} This resolves a potential ambiguity between the declaration of an enumeration
with an \grammarterm{enum-base} and the declaration of an unnamed bit-field of enumeration
type. \begin{example}

\begin{codeblock}
   struct S {
     enum E : int {};
     enum E : int {};           // error: redeclaration of enumeration
   };
\end{codeblock}

\end{example}
\end{note}
If an \grammarterm{opaque-enum-declaration} contains
a \grammarterm{nested-name-specifier},
the declaration shall be an \link{explicit specialization}{\ref{temp.expl.spec}}.

\pnum
\indextext{constant!enumeration}%
\indextext{enumeration}%
The enumeration type declared with an \grammarterm{enum-key}
of only \tcode{enum} is an \defnx{unscoped enumeration}{enumeration!unscoped},
and its \grammarterm{enumerator}{s} are \defnx{unscoped enumerators}{enumerator!unscoped}.
The \grammarterm{enum-key}{s} \tcode{enum class} and
\tcode{enum struct} are semantically equivalent; an enumeration
type declared with one of these is a \defnx{scoped enumeration}{enumeration!scoped},
and its \grammarterm{enumerator}{s} are \defnx{scoped enumerators}{enumerator!scoped}.
The optional \grammarterm{identifier} shall not be omitted in the declaration of a scoped enumeration.
The \grammarterm{type-specifier-seq} of an \grammarterm{enum-base}
shall name an integral type; any cv-qualification is ignored.
An \grammarterm{opaque-enum-declaration} declaring an unscoped enumeration shall
not omit the \grammarterm{enum-base}.
The identifiers in an \grammarterm{enumerator-list} are declared as
constants, and can appear wherever constants are required.
\indextext{enumerator!value of}%
An \grammarterm{enumerator-definition} with \tcode{=} gives the associated
\grammarterm{enumerator} the value indicated by the
\grammarterm{constant-expression}.
If the first \grammarterm{enumerator}
has no \grammarterm{initializer}, the value of the corresponding constant
is zero. An \grammarterm{enumerator-definition} without an
\grammarterm{initializer} gives the \grammarterm{enumerator} the value
obtained by increasing the value of the previous \grammarterm{enumerator}
by one.
\begin{example}

\begin{codeblock}
enum { a, b, c=0 };
enum { d, e, f=e+2 };
\end{codeblock}

defines \tcode{a}, \tcode{c}, and \tcode{d} to be zero, \tcode{b} and
\tcode{e} to be \tcode{1}, and \tcode{f} to be \tcode{3}.
\end{example}
The optional \grammarterm{attribute-specifier-seq} in an
\grammarterm{enumerator} appertains to that enumerator.

\pnum
An \grammarterm{opaque-enum-declaration} is either a redeclaration
of an enumeration in the current scope or a declaration of a new enumeration.
\begin{note} An enumeration declared by an
\grammarterm{opaque-enum-declaration} has a fixed underlying type and is a
complete type. The list of enumerators can be provided in a later redeclaration
with an \grammarterm{enum-specifier}. \end{note} A scoped enumeration
shall not be later redeclared as unscoped or with a different underlying type.
An unscoped enumeration shall not be later redeclared as scoped and each
redeclaration shall include an \grammarterm{enum-base} specifying the same
underlying type as in the original declaration.

\pnum
If the \grammarterm{enum-key} is followed by a
\grammarterm{nested-name-specifier}, the \grammarterm{enum-specifier} shall
refer to an enumeration that was previously declared directly in the class or
namespace to which the \grammarterm{nested-name-specifier} refers (i.e., neither
inherited nor introduced by a \grammarterm{using-declaration}), and the
\grammarterm{enum-specifier} shall appear in a namespace enclosing the previous
declaration.

\pnum
\indextext{\idxcode{enum}!type of}%
\indextext{\idxcode{enum}!underlying type|see{type, underlying}}%
Each enumeration defines a type that is different from all other types.
Each enumeration also has an \defnx{underlying type}{type!underlying!enumeration}.
The underlying type can be explicitly specified using an \grammarterm{enum-base}.
For a scoped enumeration type, the underlying type is \tcode{int} if it is not
explicitly specified. In both of these cases, the underlying type is said to be
\defnx{fixed}{type!underlying!fixed}.
Following the closing brace of an \grammarterm{enum-specifier}, each
enumerator has the type of its enumeration.
If the underlying type is fixed, the type of each enumerator
prior to the closing brace is the underlying
type
and the \grammarterm{constant-expression} in the \grammarterm{enumerator-definition}
shall be a
\deflinkx{converted constant expression}{expression!converted constant}{\ref{expr.const}}
of the underlying type.
If the underlying
type is not fixed,
the type of each enumerator prior to the closing brace is determined as
follows:

\begin{itemize}
\item If an
initializer is specified for an enumerator, the
\grammarterm{constant-expression} shall be an
\deflinkx{integral constant expression}{expression!integral constant}{\ref{expr.const}}.
If the expression has
unscoped enumeration type, the enumerator has the underlying type of that
enumeration type, otherwise it has the same type as the expression.

\item If no initializer is specified for the
first enumerator, its type is an unspecified signed integral type.

\item  Otherwise
the type of the enumerator is the same as that of the
preceding enumerator unless the incremented value is not representable
in that type, in which case the type is an unspecified integral type
sufficient to contain the incremented value. If no such type exists, the program
is ill-formed.
\end{itemize}

\pnum
An enumeration whose underlying type is fixed is an incomplete type from its
\deflink{point of declaration}{\ref{basic.scope.pdecl}} to immediately after its
\grammarterm{enum-base} (if any), at which point it becomes a complete type.
An enumeration whose underlying type is not fixed is an incomplete type from
its point of declaration to immediately after the closing \tcode{\}} of its
\grammarterm{enum-specifier}, at which point it becomes a complete type.

\pnum
For an enumeration whose underlying type is not fixed,
the underlying type
is an
integral type that can represent all the enumerator values defined in
the enumeration. If no integral type can represent all the enumerator
values, the enumeration is ill-formed. It is \impldef{underlying type for enumeration}
which integral type is used as the underlying type
except that the underlying type shall not be larger than \tcode{int}
unless the value of an enumerator cannot fit in an \tcode{int} or
\tcode{unsigned int}. If the \grammarterm{enumerator-list} is empty, the
underlying type is as if the enumeration had a single enumerator with
value 0.

\pnum
\indextext{signed integer representation!ones' complement}%
\indextext{signed integer representation!two's complement}%
\indextext{signed integer representation!signed magnitude}%
For an enumeration whose underlying type is fixed, the values of
the enumeration are the values of the underlying type. Otherwise,
for an enumeration where $e_\text{min}$ is the smallest enumerator and
$e_\text{max}$ is the largest, the values of the enumeration are the
values in the range $b_\text{min}$ to $b_\text{max}$, defined as follows: Let $K$
be 1 for a two's complement representation and 0 for a ones' complement
or sign-magnitude representation. $b_\text{max}$ is the smallest value
greater than or equal to $max(|e_\text{min}| - K, |e_\text{max}|)$ and equal to
$2^M-1$, where $M$ is a non-negative integer. $b_\text{min}$ is zero if
$e_\text{min}$ is non-negative and $-(b_\text{max}+K)$ otherwise. The size of the
smallest bit-field large enough to hold all the values of the
enumeration type is $max(M,1)$ if $b_\text{min}$ is zero and $M+1$ otherwise.
It is possible to define an enumeration that has values not defined by
any of its enumerators. If the \grammarterm{enumerator-list} is empty, the
values of the enumeration are as if the enumeration had a single enumerator with
value 0.\footnote{This set of values is used to define promotion and
conversion semantics for the enumeration type. It does not preclude an
expression of enumeration type from having a value that falls outside
this range.}

\pnum
Two enumeration types are \defnx{layout-compatible enumerations}{layout-compatible!enumeration}
if they have the same underlying type.

\pnum
The value of an enumerator or an object of an unscoped enumeration type is
converted to an integer by \deflinkx{integral promotion}{integral promotions}{\ref{conv.prom}}.
\begin{example}
\begin{codeblock}
  enum color { red, yellow, green=20, blue };
  color col = red;
  color* cp = &col;
  if (*cp == blue)              // ...
\end{codeblock}
makes \tcode{color} a type describing various colors, and then declares
\tcode{col} as an object of that type, and \tcode{cp} as a pointer to an
object of that type. The possible values of an object of type
\tcode{color} are \tcode{red}, \tcode{yellow}, \tcode{green},
\tcode{blue}; these values can be converted to the integral values
\tcode{0}, \tcode{1}, \tcode{20}, and \tcode{21}. Since enumerations are
distinct types, objects of type \tcode{color} can be assigned only
values of type \tcode{color}.
\begin{codeblock}
color c = 1;                    // error: type mismatch, no conversion from \tcode{int} to \tcode{color}
int i = yellow;                 // OK: \tcode{yellow} converted to integral value \tcode{1}, integral promotion
\end{codeblock}
Note that this implicit \tcode{enum} to \tcode{int}
conversion is not provided for a scoped enumeration:
\begin{codeblock}
enum class Col { red, yellow, green };
int x = Col::red;               // error: no \tcode{Col} to \tcode{int} conversion
Col y = Col::red;
if (y) { }                      // error: no \tcode{Col} to \tcode{bool} conversion
\end{codeblock}
\end{example}

\pnum
\indextext{class!scope of enumerator}%
Each \grammarterm{enum-name} and each unscoped \grammarterm{enumerator} is
declared in the scope that immediately contains the \grammarterm{enum-specifier}.
Each scoped \grammarterm{enumerator} is declared in the scope of the
enumeration.
These names obey the scope rules defined for all names
in~\ref{basic.scope} and~\ref{basic.lookup}. \begin{example}
\begin{codeblock}
enum direction { left='l', right='r' };

void g()  {
  direction d;                  // OK
  d = left;                     // OK
  d = direction::right;         // OK
}

enum class altitude { high='h', low='l' };

void h()  {
  altitude a;                   // OK
  a = high;                     // error: \tcode{high} not in scope
  a = altitude::low;            // OK
}
\end{codeblock}
\end{example}
\indextext{member!enumerator}%
An enumerator declared in class scope can be referred to using the class
member access operators (\tcode{::}, \tcode{.} (dot) and \tcode{->}
(arrow)), see~\ref{expr.ref}.
\begin{example}

\begin{codeblock}
struct X {
  enum direction { left='l', right='r' };
  int f(int i) { return i==left ? 0 : i==right ? 1 : 2; }
};

void g(X* p) {
  direction d;                  // error: \tcode{direction} not in scope
  int i;
  i = p->f(left);               // error: \tcode{left} not in scope
  i = p->f(X::right);           // OK
  i = p->f(p->left);            // OK
  // ...
}
\end{codeblock}
\end{example}

\pnum
If an \grammarterm{enum-head} contains a \grammarterm{nested-name-specifier},
the \grammarterm{enum-specifier} shall refer to an enumeration
that was previously declared directly in the class or namespace
to which the \grammarterm{nested-name-specifier} refers, or
in an element of the inline namespace set\iref{namespace.def}
of that namespace (i.e., not merely inherited or introduced by a
\grammarterm{using-declaration}), and
the \grammarterm{enum-specifier} shall appear in
a namespace enclosing the previous declaration.
In such cases, the \grammarterm{nested-name-specifier}
of the \grammarterm{enum-head} of the definition
shall not begin with a \grammarterm{decltype-specifier}.

\rSec1[basic.namespace]{Namespaces}%
\indextext{namespaces|(}

\pnum
A namespace is an optionally-named declarative region. The name of a
namespace can be used to access entities declared in that namespace;
that is, the members of the namespace. Unlike other declarative regions,
the definition of a namespace can be split over several parts of one or
more translation units.

\pnum
The outermost declarative region of a translation unit is a namespace;
see~\ref{basic.scope.namespace}.

\rSec2[namespace.def]{Namespace definition}%
\indextext{definition!namespace}%
\indextext{namespace!definition}

\begin{bnf}
\nontermdef{namespace-name}\br
        identifier\br
        namespace-alias
\end{bnf}

\begin{bnf}
\nontermdef{namespace-definition}\br
        named-namespace-definition\br
        unnamed-namespace-definition\br
        nested-namespace-definition
\end{bnf}

\begin{bnf}
\nontermdef{named-namespace-definition}\br
        \terminal{\opt{inline}} \terminal{namespace} \opt{attribute-specifier-seq} identifier \terminal{\{} namespace-body \terminal{\}}
\end{bnf}

\begin{bnf}
\nontermdef{unnamed-namespace-definition}\br
        \terminal{\opt{inline}} \terminal{namespace} \opt{attribute-specifier-seq} \terminal{\{} namespace-body \terminal{\}}
\end{bnf}

\begin{bnf}
\nontermdef{nested-namespace-definition}\br
        \terminal{namespace} enclosing-namespace-specifier \terminal{::} identifier \terminal{\{} namespace-body \terminal{\}}
\end{bnf}

\begin{bnf}
\nontermdef{enclosing-namespace-specifier}\br
        identifier\br
        enclosing-namespace-specifier \terminal{::} identifier
\end{bnf}

\begin{bnf}
\nontermdef{namespace-body}\br
        \opt{declaration-seq}
\end{bnf}

\pnum
Every \grammarterm{namespace-definition} shall appear in the global scope
or in a namespace scope\iref{basic.scope.namespace}.

\pnum
In a \grammarterm{named-namespace-definition},
the \grammarterm{identifier} is the name of the namespace.
If the \grammarterm{identifier}, when \link{looked up}{\ref{basic.lookup.unqual}},
refers to a \grammarterm{namespace-name} (but not a \grammarterm{namespace-alias})
that was introduced in the namespace
in which the \grammarterm{named-namespace-definition} appears
or that was introduced in a member of the inline namespace set of that namespace,
the \grammarterm{namespace-definition}
\indextext{extend|see{namespace, extend}}
\defnx{extends}{namespace!extend} the previously-declared namespace.
Otherwise, the \grammarterm{identifier} is introduced
as a \grammarterm{namespace-name} into the declarative region
in which the \grammarterm{named-namespace-definition} appears.

\pnum
Because a \grammarterm{namespace-definition} contains
\grammarterm{declaration}{s} in its \grammarterm{namespace-body} and a
\grammarterm{namespace-definition} is itself a \grammarterm{declaration}, it
follows that \grammarterm{namespace-definition}{s} can be nested.
\begin{example}
\begin{codeblock}
namespace Outer {
  int i;
  namespace Inner {
    void f() { i++; }           // \tcode{Outer::i}
    int i;
    void g() { i++; }           // \tcode{Inner::i}
  }
}
\end{codeblock}
\end{example}

\pnum
The \defnx{enclosing namespaces}{namespace!enclosing} of a declaration are those
namespaces in which the declaration lexically appears, except for a
redeclaration of a namespace member outside its original namespace
(e.g., a definition as specified in~\ref{namespace.memdef}). Such a
redeclaration has the same enclosing namespaces as the original
declaration.
\begin{example}
\begin{codeblock}
namespace Q {
  namespace V {
    void f();                   // enclosing namespaces are the global namespace, \tcode{Q}, and \tcode{Q::V}
    class C { void m(); };
  }
  void V::f() {                 // enclosing namespaces are the global namespace, \tcode{Q}, and \tcode{Q::V}
    extern void h();            // ... so this declares \tcode{Q::V::h}
  }
  void V::C::m() {              // enclosing namespaces are the global namespace, \tcode{Q}, and \tcode{Q::V}
  }
}
\end{codeblock}
\end{example}

\pnum
If the optional initial \tcode{inline} keyword appears in a
\grammarterm{namespace-definition} for a particular namespace, that namespace is
declared to be an \defnx{inline namespace}{namespace!inline}. The \tcode{inline} keyword may be
used on a \grammarterm{namespace-definition} that extends a namespace
only if it was previously used on the \grammarterm{namespace-definition}
that initially declared the \grammarterm{namespace-name} for that namespace.

\pnum
The optional \grammarterm{attribute-specifier-seq}
in a \grammarterm{named-namespace-definition}
appertains to the namespace being defined or extended.

\pnum
Members of an inline namespace can be used in most respects as though they were members
of the enclosing namespace. Specifically, the inline namespace and its enclosing
namespace are both added to the set of associated namespaces used in
\link{argument-dependent lookup}{\ref{basic.lookup.argdep}} whenever one of them is,
and a \grammarterm{using-directive}\iref{namespace.udir} that names the inline
namespace is implicitly inserted into the enclosing namespace as for an \link{unnamed
namespace}{\ref{namespace.unnamed}}. Furthermore, each
member of the inline namespace can subsequently be \link{partially
specialized}{\ref{temp.class.spec}}, \link{explicitly
instantiated}{\ref{temp.explicit}}, or \link{explicitly specialized}{\ref{temp.expl.spec}} as
though it were a member of the enclosing namespace. Finally, looking up a name in the
enclosing namespace via explicit qualification\iref{namespace.qual} will include
members of the inline namespace brought in by the \grammarterm{using-directive} even if
there are declarations of that name in the enclosing namespace.

\pnum
These properties are transitive: if a namespace \tcode{N} contains an inline namespace
\tcode{M}, which in turn contains an inline namespace \tcode{O}, then the members of
\tcode{O} can be used as though they were members of \tcode{M} or \tcode{N}.
The \defn{inline namespace set} of \tcode{N} is the transitive closure of all
inline namespaces in \tcode{N}.
The \defn{enclosing namespace set} of \tcode{O} is the set of namespaces
consisting of the innermost non-inline namespace enclosing
an inline namespace \tcode{O}, together with any intervening inline namespaces.

\pnum
A \grammarterm{nested-namespace-definition} with an
\grammarterm{enclosing-namespace-specifier} \tcode{E},
\grammarterm{identifier} \tcode{I} and
\grammarterm{namespace-body} \tcode{B}
is equivalent to
\begin{codeblock}
namespace E { namespace I { B } }
\end{codeblock}
\begin{example}
\begin{codeblock}
namespace A::B::C {
  int i;
}
\end{codeblock}
The above has the same effect as:
\begin{codeblock}
namespace A {
  namespace B {
    namespace C {
      int i;
    }
  }
}
\end{codeblock}
\end{example}

\rSec3[namespace.unnamed]{Unnamed namespaces}%
\indextext{namespace!unnamed}

\pnum
An \grammarterm{unnamed-namespace-definition} behaves as if it were
replaced by
\begin{ncsimplebnf}
\opt{\terminal{inline}} \terminal{namespace} \terminal{\uniquens} \terminal{\{ /* empty body */ \}}\br
\terminal{using namespace} \terminal{\uniquens} \terminal{;}\br
\terminal{namespace} \terminal{\uniquens} \terminal{\{} namespace-body \terminal{\}}
\end{ncsimplebnf}
where
\tcode{inline} appears if and only if it appears in the
\grammarterm{unnamed-namespace-definition}
and all occurrences of \tcode{\uniquens} in a translation unit are replaced by
the same identifier, and this identifier differs from all other
identifiers in the translation unit.
The optional \grammarterm{attribute-specifier-seq}
in the \grammarterm{unnamed-namespace-definition}
appertains to \tcode{\uniquens}.
\begin{example}
\begin{codeblock}
namespace { int i; }            // \tcode{\uniquens::i}
void f() { i++; }               // \tcode{\uniquens::i++}

namespace A {
  namespace {
    int i;                      // \tcode{A::\uniquens::i}
    int j;                      // \tcode{A::\uniquens::j}
  }
  void g() { i++; }             // \tcode{A::\uniquens::i++}
}

using namespace A;
void h() {
  i++;                          // error: \tcode{\uniquens::i} or \tcode{A::\uniquens::i}
  A::i++;                       // \tcode{A::\uniquens::i}
  j++;                          // \tcode{A::\uniquens::j}
}
\end{codeblock}
\end{example}

\rSec3[namespace.memdef]{Namespace member definitions}%
\indextext{namespace!member definition}

\pnum
A declaration in a namespace \tcode{N} (excluding declarations in nested scopes)
whose \grammarterm{declarator-id} is an \grammarterm{unqualified-id}\iref{dcl.meaning},
whose \grammarterm{class-head-name}\iref{class} or
\grammarterm{enum-head-name}\iref{dcl.enum} is an \grammarterm{identifier}, or
whose \grammarterm{elaborated-type-specifier} is of the form \grammarterm{class-key}
\opt{\grammarterm{attribute-specifier-seq}} \grammarterm{identifier}\iref{dcl.type.elab}, or
that is an \grammarterm{opaque-enum-declaration},
declares (or redeclares) its \grammarterm{unqualified-id} or
\grammarterm{identifier} as a member of \tcode{N}.
\begin{note}
An \link{explicit instantiation}{\ref{temp.explicit}} or
\link{explicit specialization}{\ref{temp.expl.spec}} of a template
does not introduce a name and thus may be declared using an
\grammarterm{unqualified-id} in a member of the enclosing namespace set,
if the primary template is declared in an inline namespace.
\end{note}
\begin{example}
\begin{codeblock}
namespace X {
  void f() { @\commentellip@ }        // OK: introduces \tcode{X::f()}

  namespace M {
    void g();                   // OK: introduces \tcode{X::M::g()}
  }
  using M::g;
  void g();                     // error: conflicts with \tcode{X::M::g()}
}
\end{codeblock}
\end{example}

\pnum
Members of a named namespace can also be
defined outside that namespace by explicit
qualification\iref{namespace.qual} of the name being defined, provided
that the entity being defined was already declared in the namespace and
the definition appears after the point of declaration in a namespace
that encloses the declaration's namespace.
\begin{example}
\begin{codeblock}
namespace Q {
  namespace V {
    void f();
  }
  void V::f() { @\commentellip@ }     // OK
  void V::g() { @\commentellip@ }     // error: \tcode{g()} is not yet a member of \tcode{V}
  namespace V {
    void g();
  }
}

namespace R {
  void Q::V::g() { @\commentellip@ }  // error: \tcode{R} doesn't enclose \tcode{Q}
}
\end{codeblock}
\end{example}

\pnum
If a friend declaration in a non-local class first declares a
class, function, class template or function template\footnote{this implies that the name of the class or function is unqualified.}
the friend is a member of the innermost enclosing
namespace. The friend declaration does not by itself make the name
visible to \link{unqualified lookup}{\ref{basic.lookup.unqual}} or \link{qualified
lookup}{\ref{basic.lookup.qual}}. \begin{note} The name of the friend will be
visible in its namespace if a matching declaration is provided at namespace
scope (either before or after the class definition granting friendship).
\end{note} If a friend
function or function template is called, its name may be found by the
name lookup that considers functions from namespaces and classes
associated with the types of the function
arguments\iref{basic.lookup.argdep}. If the
name in a friend declaration is neither qualified nor a
\grammarterm{template-id} and the declaration is a function or an
\grammarterm{elaborated-type-specifier}, the lookup to determine whether
the entity has been previously declared shall not consider any scopes
outside the innermost enclosing namespace. \begin{note} The other forms of
friend declarations cannot declare a new member of the innermost
enclosing namespace and thus follow the usual lookup rules.
\end{note}
\begin{example}

\begin{codeblock}
// Assume \tcode{f} and \tcode{g} have not yet been declared.
void h(int);
template <class T> void f2(T);
namespace A {
  class X {
    friend void f(X);           // \tcode{A::f(X)} is a friend
    class Y {
      friend void g();          // \tcode{A::g} is a friend
      friend void h(int);       // \tcode{A::h} is a friend
                                // \tcode{::h} not considered
      friend void f2<>(int);    // \tcode{::f2<>(int)} is a friend
    };
  };

  // \tcode{A::f}, \tcode{A::g} and \tcode{A::h} are not visible here
  X x;
  void g() { f(x); }            // definition of \tcode{A::g}
  void f(X) { @\commentellip@ }       // definition of \tcode{A::f}
  void h(int) { @\commentellip@ }     // definition of \tcode{A::h}
  // \tcode{A::f}, \tcode{A::g} and \tcode{A::h} are visible here and known to be friends
}

using A::x;

void h() {
  A::f(x);
  A::X::f(x);                   // error: \tcode{f} is not a member of \tcode{A::X}
  A::X::Y::g();                 // error: \tcode{g} is not a member of \tcode{A::X::Y}
}
\end{codeblock}
\end{example}

\rSec2[namespace.alias]{Namespace alias}%
\indextext{namespace!alias}%
\indextext{alias!namespace}%
\indextext{synonym}

\pnum
A \grammarterm{namespace-alias-definition} declares an alternate name for a
namespace according to the following grammar:

\begin{bnf}
\nontermdef{namespace-alias}\br
        identifier
\end{bnf}

\begin{bnf}
\nontermdef{namespace-alias-definition}\br
        \terminal{namespace} identifier \terminal{=} qualified-namespace-specifier \terminal{;}
\end{bnf}

\begin{bnf}
\nontermdef{qualified-namespace-specifier}\br
    \opt{nested-name-specifier} namespace-name
\end{bnf}

\pnum
The \grammarterm{identifier} in a \grammarterm{namespace-alias-definition} is
a synonym for the name of the namespace denoted by the
\grammarterm{qualified-namespace-specifier} and becomes a
\grammarterm{namespace-alias}.
\begin{note}
When looking up a \grammarterm{namespace-name} in a
\grammarterm{namespace-alias-definition}, only namespace names are
considered, see~\ref{basic.lookup.udir}.
\end{note}

\pnum
In a declarative region, a \grammarterm{namespace-alias-definition} can be
used to redefine a \grammarterm{namespace-alias} declared in that
declarative region to refer only to the namespace to which it already
refers.
\begin{example}
The following declarations are well-formed:

\begin{codeblock}
namespace Company_with_very_long_name { @\commentellip@ }
namespace CWVLN = Company_with_very_long_name;
namespace CWVLN = Company_with_very_long_name;  // OK: duplicate
namespace CWVLN = CWVLN;
\end{codeblock}
\end{example}

\rSec2[namespace.udecl]{The \tcode{using} declaration}%
\indextext{using-declaration|(}

\begin{bnf}
\nontermdef{using-declaration}\br
    \terminal{using} using-declarator-list \terminal{;}
\end{bnf}

\begin{bnf}
\nontermdef{using-declarator-list}\br
    using-declarator \opt{\terminal{...}}\br
    using-declarator-list \terminal{,} using-declarator \opt{\terminal{...}}
\end{bnf}

\begin{bnf}
\nontermdef{using-declarator}\br
    \terminal{\opt{typename}} nested-name-specifier unqualified-id
\end{bnf}

\pnum
Each \grammarterm{using-declarator} in a \grammarterm{using-declaration}%
\footnote{A \grammarterm{using-declaration} with more than one
\grammarterm{using-declarator} is equivalent to a corresponding sequence
of \grammarterm{using-declaration}{s} with
one \grammarterm{using-declarator} each.}
introduces a set of declarations into the declarative region in
which the \grammarterm{using-declaration} appears.
The set of declarations introduced by the \grammarterm{using-declarator} is found by
performing qualified name lookup~(\ref{basic.lookup.qual}, \ref{class.member.lookup})
for the name in the \grammarterm{using-declarator},
excluding functions that are hidden as described below.
If the \grammarterm{using-declarator} does not name a constructor,
the \grammarterm{unqualified-id} is declared in the declarative region
in which the \grammarterm{using-declaration} appears
as a synonym for each declaration introduced by the \grammarterm{using-declarator}.
\begin{note} Only the specified name is so declared;
specifying an enumeration name in a \grammarterm{using-declaration}
does not declare its enumerators
in the \grammarterm{using-declaration}{'s} declarative region.
\end{note}
\indextext{inheritance!\idxgram{using-declaration} and}%
If the \grammarterm{using-declarator} names a constructor,
it declares that the class \defnx{inherits}{constructor!inherited} the set of constructor declarations
introduced by the \grammarterm{using-declarator} from the nominated base class.

\pnum
Every \grammarterm{using-declaration} is a \grammarterm{declaration} and a
\grammarterm{member-declaration} and can therefore be used in a class definition.
\begin{example}

\begin{codeblock}
struct B {
  void f(char);
  void g(char);
  enum E { e };
  union { int x; };
};

struct D : B {
  using B::f;
  void f(int) { f('c'); }       // calls \tcode{B::f(char)}
  void g(int) { g('c'); }       // recursively calls \tcode{D::g(int)}
};
\end{codeblock}
\end{example}

\pnum
In a \grammarterm{using-declaration} used as a
\grammarterm{member-declaration},
each \grammarterm{using-declarator}{'s} \grammarterm{nested-name-specifier}
shall name a base class of the class being defined. If a
\grammarterm{using-declarator} names a constructor, its
\grammarterm{nested-name-specifier} shall name a direct base class of the class
being defined.
\begin{example}
\begin{codeblock}
template <typename... bases>
struct X : bases... {
  using bases::g...;
};

X<B, D> x;                      // OK: \tcode{B::g} and \tcode{D::g} introduced
\end{codeblock}
\end{example}
\begin{example}
\begin{codeblock}
class C {
  int g();
};

class D2 : public B {
  using B::f;                   // OK: \tcode{B} is a base of \tcode{D2}
  using B::e;                   // OK: \tcode{e} is an enumerator of base \tcode{B}
  using B::x;                   // OK: \tcode{x} is a union member of base \tcode{B}
  using C::g;                   // error: \tcode{C} isn't a base of \tcode{D2}
};
\end{codeblock}
\end{example}

\pnum
\begin{note}
Since destructors do not have names, a
\grammarterm{using-declaration} cannot refer to a
destructor for a base class. Since specializations of member templates
for conversion functions are not found by name lookup, they are not
considered when a \grammarterm{using-declaration} specifies a conversion
function\iref{temp.mem}.
\end{note}
If a constructor or assignment operator brought from a base class into a derived class
has the signature of a copy/move constructor or assignment operator
for the derived class\iref{class.copy},
the \grammarterm{using-declaration} does not by itself
suppress the implicit declaration of the derived class member;
the member from the base class is hidden or overridden
by the implicitly-declared copy/move constructor or assignment operator
of the derived class, as described below.

\pnum
A \grammarterm{using-declaration} shall not name a \grammarterm{template-id}.
\begin{example}

\begin{codeblock}
struct A {
  template <class T> void f(T);
  template <class T> struct X { };
};
struct B : A {
  using A::f<double>;           // ill-formed
  using A::X<int>;              // ill-formed
};
\end{codeblock}
\end{example}

\pnum
A \grammarterm{using-declaration} shall not name a namespace.

\pnum
A \grammarterm{using-declaration} shall not name a scoped enumerator.

\pnum
A \grammarterm{using-declaration} that names a class member shall be a
\grammarterm{member-declaration}.
\begin{example}
\begin{codeblock}
struct X {
  int i;
  static int s;
};

void f() {
  using X::i;                   // error: \tcode{X::i} is a class member and this is not a member declaration.
  using X::s;                   // error: \tcode{X::s} is a class member and this is not a member declaration.
}
\end{codeblock}
\end{example}

\pnum
Members declared by a \grammarterm{using-declaration} can be referred to by
explicit qualification just like other member
names\iref{namespace.qual}.
\begin{example}
\begin{codeblock}
void f();

namespace A {
  void g();
}

namespace X {
  using ::f;                    // global \tcode{f}
  using A::g;                   // \tcode{A}'s \tcode{g}
}

void h()
{
  X::f();                       // calls \tcode{::f}
  X::g();                       // calls \tcode{A::g}
}
\end{codeblock}
\end{example}

\pnum
A \grammarterm{using-declaration} is a \grammarterm{declaration} and can
therefore be used repeatedly where (and only where) multiple
declarations are allowed.
\begin{example}
\begin{codeblock}
namespace A {
  int i;
}

namespace A1 {
  using A::i, A::i;             // OK: double declaration
}

struct B {
  int i;
};

struct X : B {
  using B::i, B::i;             // error: double member declaration
};
\end{codeblock}
\end{example}

\pnum
\begin{note}
For a \grammarterm{using-declaration}
whose \grammarterm{nested-name-specifier} names a namespace,
members added to the namespace after the \grammarterm{using-declaration}
are not in the set of introduced declarations, so they are not
considered when a use of the name is made. Thus, additional
overloads added after the \grammarterm{using-declaration} are ignored, but
default function arguments\iref{dcl.fct.default}, default template
arguments\iref{temp.param}, and template specializations~(\ref{temp.class.spec},
\ref{temp.expl.spec}) are considered. \end{note}
\begin{example}

\begin{codeblock}
namespace A {
  void f(int);
}

using A::f;         // \tcode{f} is a synonym for \tcode{A::f}; that is, for \tcode{A::f(int)}.
namespace A {
  void f(char);
}

void foo() {
  f('a');           // calls \tcode{f(int)}, even though \tcode{f(char)} exists.
}

void bar() {
  using A::f;       // \tcode{f} is a synonym for \tcode{A::f}; that is, for \tcode{A::f(int)} and \tcode{A::f(char)}.
  f('a');           // calls \tcode{f(char)}
}
\end{codeblock}
\end{example}

\pnum
\begin{note}
Partial specializations of class templates are found by looking up the
primary class template and then considering all partial specializations
of that template. If a \grammarterm{using-declaration} names a class
template, partial specializations introduced after the
\grammarterm{using-declaration} are effectively visible because the primary
template is visible\iref{temp.class.spec}.
\end{note}

\pnum
Since a \grammarterm{using-declaration} is a declaration, the restrictions
on declarations of the same name in the same
\deflink{declarative region}{\ref{basic.scope}} also apply to \grammarterm{using-declaration}{s}.
\begin{example}

\begin{codeblock}
namespace A {
  int x;
}

namespace B {
  int i;
  struct g { };
  struct x { };
  void f(int);
  void f(double);
  void g(char);     // OK: hides \tcode{struct g}
}

void func() {
  int i;
  using B::i;       // error: \tcode{i} declared twice
  void f(char);
  using B::f;       // OK: each \tcode{f} is a function
  f(3.5);           // calls \tcode{B::f(double)}
  using B::g;
  g('a');           // calls \tcode{B::g(char)}
  struct g g1;      // \tcode{g1} has class type \tcode{B::g}
  using B::x;
  using A::x;       // OK: hides \tcode{struct B::x}
  x = 99;           // assigns to \tcode{A::x}
  struct x x1;      // \tcode{x1} has class type \tcode{B::x}
}
\end{codeblock}
\end{example}

\pnum
If a function declaration in namespace scope or block scope has the same
name and the same \deflink{parameter-type-list}{\ref{dcl.fct}} as
a function introduced by a \grammarterm{using-declaration}, and the
declarations do not declare the same function, the program is
ill-formed. If a function template declaration in namespace scope has
the same name, parameter-type-list, return type, and template
parameter list as a function template introduced by a
\grammarterm{using-declaration}, the program is ill-formed.
\begin{note}
Two \grammarterm{using-declaration}{s} may introduce functions with the same
name and the same parameter-type-list. If, for a call to an unqualified
function name, function overload resolution selects the functions
introduced by such \grammarterm{using-declaration}{s}, the function call is
ill-formed.
\begin{example}

\begin{codeblock}
namespace B {
  void f(int);
  void f(double);
}
namespace C {
  void f(int);
  void f(double);
  void f(char);
}

void h() {
  using B::f;       // \tcode{B::f(int)} and \tcode{B::f(double)}
  using C::f;       // \tcode{C::f(int)}, \tcode{C::f(double)}, and \tcode{C::f(char)}
  f('h');           // calls \tcode{C::f(char)}
  f(1);             // error: ambiguous: \tcode{B::f(int)} or \tcode{C::f(int)}?
  void f(int);      // error: \tcode{f(int)} conflicts with \tcode{C::f(int)} and \tcode{B::f(int)}
}
\end{codeblock}
\end{example}
\end{note}

\pnum
\indextext{name hiding!using-declaration and}%
When a \grammarterm{using-declarator} brings declarations from a base class into
a derived class, member functions and member function templates in
the derived class override and/or hide member functions and member
function templates with the same name,
\deflink{parameter-type-list}{\ref{dcl.fct}}, cv-qualification, and \grammarterm{ref-qualifier} (if any) in a base
class (rather than conflicting).
Such hidden or overridden declarations are excluded from the set of
declarations introduced by the \grammarterm{using-declarator}.
\begin{example}

\begin{codeblock}
struct B {
  virtual void f(int);
  virtual void f(char);
  void g(int);
  void h(int);
};

struct D : B {
  using B::f;
  void f(int);      // OK: \tcode{D::f(int)} overrides \tcode{B::f(int)};

  using B::g;
  void g(char);     // OK

  using B::h;
  void h(int);      // OK: \tcode{D::h(int)} hides \tcode{B::h(int)}
};

void k(D* p)
{
  p->f(1);          // calls \tcode{D::f(int)}
  p->f('a');        // calls \tcode{B::f(char)}
  p->g(1);          // calls \tcode{B::g(int)}
  p->g('a');        // calls \tcode{D::g(char)}
}

struct B1 {
  B1(int);
};

struct B2 {
  B2(int);
};

struct D1 : B1, B2 {
  using B1::B1;
  using B2::B2;
};
D1 d1(0);           // ill-formed: ambiguous

struct D2 : B1, B2 {
  using B1::B1;
  using B2::B2;
  D2(int);          // OK: \tcode{D2::D2(int)} hides \tcode{B1::B1(int)} and \tcode{B2::B2(int)}
};
D2 d2(0);           // calls \tcode{D2::D2(int)}
\end{codeblock}
\end{example}

\pnum
\indextext{overloading!using-declaration and}%
For the purpose of forming a set of candidates during overload resolution,
the functions that are
introduced by a \grammarterm{using-declaration} into a derived class
are treated as though they were members of the derived class. In
particular, the implicit \tcode{this} parameter shall be treated as if
it were a pointer to the derived class rather than to the base class.
This has no effect on the type of the function, and in all other
respects the function remains a member of the base class.
Likewise, constructors that are introduced by a \grammarterm{using-declaration}
are treated as though they were constructors of the derived class
when looking up the constructors of the derived class\iref{class.qual}
or forming a set of overload candidates~(\ref{over.match.ctor}, \ref{over.match.copy}, \ref{over.match.list}).
If such a constructor is selected to perform the initialization
of an object of class type, all subobjects other than the base class
from which the constructor originated
are implicitly initialized\iref{class.inhctor.init}.
\begin{note}
A member of a derived class is sometimes preferred to a member of a base class
if they would otherwise be ambiguous\iref{over.match.best}.
\end{note}

\pnum
\indextext{access control!using-declaration and}%
In a \grammarterm{using-declarator} that does not name a constructor,
all members of the set of introduced declarations shall be accessible.
In a \grammarterm{using-declarator} that names a constructor,
no access check is performed.
In particular, if a derived class uses a
\grammarterm{using-declarator} to access a member of a base class, the
member name shall be accessible. If the name is that of an overloaded
member function, then all functions named shall be accessible. The base
class members mentioned by a \grammarterm{using-declarator} shall be
visible in the scope of at least one of the direct base classes of the
class where the \grammarterm{using-declarator} is specified.

\pnum
\begin{note}
Because a \grammarterm{using-declarator} designates a base class member
(and not a member subobject or a member function of a base class
subobject), a \grammarterm{using-declarator} cannot be used to resolve
inherited member ambiguities.
\begin{example}
\begin{codeblock}
struct A { int x(); };
struct B : A { };
struct C : A {
  using A::x;
  int x(int);
};

struct D : B, C {
  using C::x;
  int x(double);
};
int f(D* d) {
  return d->x();    // error: overload resolution selects \tcode{A::x}, but \tcode{A} is an ambiguous base class
}
\end{codeblock}
\end{example}
\end{note}

\pnum
A synonym created by a \grammarterm{using-declaration} has the usual
accessibility for a \grammarterm{member-declaration}.
A \grammarterm{using-declarator} that names a constructor does not
create a synonym; instead, the additional constructors
are accessible if they would be accessible
when used to construct an object of the corresponding base class,
and the accessibility of the \grammarterm{using-declaration} is ignored.
\begin{example}

\begin{codeblock}
class A {
private:
    void f(char);
public:
    void f(int);
protected:
    void g();
};

class B : public A {
  using A::f;       // error: \tcode{A::f(char)} is inaccessible
public:
  using A::g;       // \tcode{B::g} is a public synonym for \tcode{A::g}
};
\end{codeblock}
\end{example}

\pnum
If a \grammarterm{using-declarator} uses the keyword \tcode{typename} and
specifies a dependent name\iref{temp.dep}, the name introduced by the
\grammarterm{using-declaration} is treated as a
\grammarterm{typedef-name}\iref{dcl.typedef}.%
\indextext{using-declaration|)}

\rSec2[namespace.udir]{Using directive}%
\indextext{using-directive|(}

\begin{bnf}
\nontermdef{using-directive}\br
    \opt{attribute-specifier-seq} \terminal{using  namespace} \opt{nested-name-specifier} namespace-name \terminal{;}
\end{bnf}

\pnum
A \grammarterm{using-directive} shall not appear in class scope, but may
appear in namespace scope or in block scope.
\begin{note}
When looking up a \grammarterm{namespace-name} in a
\grammarterm{using-directive}, only namespace names are considered,
see~\ref{basic.lookup.udir}.
\end{note}
The optional \grammarterm{attribute-specifier-seq} appertains to the \grammarterm{using-directive}.

\pnum
A \grammarterm{using-directive} specifies that the names in the nominated
namespace can be used in the scope in which the
\grammarterm{using-directive} appears after the \grammarterm{using-directive}.
During \link{unqualified name lookup}{\ref{basic.lookup.unqual}}, the names
appear as if they were declared in the nearest enclosing namespace which
contains both the \grammarterm{using-directive} and the nominated
namespace.
\begin{note}
In this context, ``contains'' means ``contains directly or indirectly''.
\end{note}

\pnum
A \grammarterm{using-directive} does not add any members to the declarative
region in which it appears.
\begin{example}

\begin{codeblock}
namespace A {
  int i;
  namespace B {
    namespace C {
      int i;
    }
    using namespace A::B::C;
    void f1() {
      i = 5;        // OK, \tcode{C::i} visible in \tcode{B} and hides \tcode{A::i}
    }
  }
  namespace D {
    using namespace B;
    using namespace C;
    void f2() {
      i = 5;        // ambiguous, \tcode{B::C::i} or \tcode{A::i}?
    }
  }
  void f3() {
    i = 5;          // uses \tcode{A::i}
  }
}
void f4() {
  i = 5;            // ill-formed; neither \tcode{i} is visible
}
\end{codeblock}
\end{example}

\pnum
For \link{unqualified lookup}{\ref{basic.lookup.unqual}}, the
\grammarterm{using-directive} is transitive: if a scope contains a
\grammarterm{using-directive} that nominates a second namespace that itself
contains \grammarterm{using-directive}{s}, the effect is as if the
\grammarterm{using-directive}{s} from the second namespace also appeared in
the first.
\begin{note} For qualified lookup, see~\ref{namespace.qual}. \end{note}
\begin{example}

\begin{codeblock}
namespace M {
  int i;
}

namespace N {
  int i;
  using namespace M;
}

void f() {
  using namespace N;
  i = 7;            // error: both \tcode{M::i} and \tcode{N::i} are visible
}
\end{codeblock}

For another example,

\begin{codeblock}
namespace A {
  int i;
}
namespace B {
  int i;
  int j;
  namespace C {
    namespace D {
      using namespace A;
      int j;
      int k;
      int a = i;    // \tcode{B::i} hides \tcode{A::i}
    }
    using namespace D;
    int k = 89;     // no problem yet
    int l = k;      // ambiguous: \tcode{C::k} or \tcode{D::k}
    int m = i;      // \tcode{B::i} hides \tcode{A::i}
    int n = j;      // \tcode{D::j} hides \tcode{B::j}
  }
}
\end{codeblock}
\end{example}


\pnum
If a namespace is \deflinkx{extended}{namespace!extend}{\ref{namespace.def}} after a
\grammarterm{using-directive} for that namespace is given, the additional
members of the extended namespace and the members of namespaces
nominated by \grammarterm{using-directive}{s} in the
extending \grammarterm{namespace-definition} can be used after the
extending \grammarterm{namespace-definition}.

\pnum
\begin{note}
If name lookup finds a declaration for a name in two different
namespaces, and the declarations do not declare the same entity and do
not declare functions or function templates, the use of the name is ill-formed\iref{basic.lookup}.
In particular, the name of a variable, function or enumerator does not
hide the name of a class or enumeration declared in a different
namespace. For example,

\begin{codeblock}
namespace A {
  class X { };
  extern "C"   int g();
  extern "C++" int h();
}
namespace B {
  void X(int);
  extern "C"   int g();
  extern "C++" int h(int);
}
using namespace A;
using namespace B;

void f() {
  X(1);             // error: name \tcode{X} found in two namespaces
  g();              // OK: name \tcode{g} refers to the same entity
  h();              // OK: overload resolution selects \tcode{A::h}
}
\end{codeblock}
\end{note}

\pnum
\indextext{overloading!using directive and}%
During overload resolution, all functions from the transitive search are
considered for argument matching. The set of declarations found by the
transitive search is unordered.
\begin{note}
In particular, the order in which namespaces were considered and the
relationships among the namespaces implied by the
\grammarterm{using-directive}{s} do not cause preference to be given to any
of the declarations found by the search.
\end{note}
An ambiguity exists if the best match finds two functions with the same
signature, even if one is in a namespace reachable through
\grammarterm{using-directive}{s} in the namespace of the other.\footnote{During
name lookup in a class hierarchy, some ambiguities may be
resolved by considering whether one member hides the other along some
paths\iref{class.member.lookup}. There is no such disambiguation when
considering the set of names found as a result of following
\grammarterm{using-directive}{s}.}
\begin{example}

\begin{codeblock}
namespace D {
  int d1;
  void f(char);
}
using namespace D;

int d1;             // OK: no conflict with \tcode{D::d1}

namespace E {
  int e;
  void f(int);
}

namespace D {       // namespace extension
  int d2;
  using namespace E;
  void f(int);
}

void f() {
  d1++;             // error: ambiguous \tcode{::d1} or \tcode{D::d1}?
  ::d1++;           // OK
  D::d1++;          // OK
  d2++;             // OK: \tcode{D::d2}
  e++;              // OK: \tcode{E::e}
  f(1);             // error: ambiguous: \tcode{D::f(int)} or \tcode{E::f(int)}?
  f('a');           // OK: \tcode{D::f(char)}
}
\end{codeblock}
\end{example}%
\indextext{using-directive|)}%
\indextext{namespaces|)}

\rSec1[dcl.asm]{The \tcode{asm} declaration}%
\indextext{declaration!\idxcode{asm}}%
\indextext{assembler}%
\indextext{\idxcode{asm}!implementation-defined}

\pnum
An \tcode{asm} declaration has the form

\begin{bnf}
\nontermdef{asm-definition}\br
    \opt{attribute-specifier-seq} \terminal{asm (} string-literal \terminal{) ;}
\end{bnf}

The \tcode{asm} declaration is conditionally-supported; its meaning is
\impldef{meaning of \tcode{asm} declaration}.
The optional \grammarterm{attribute-specifier-seq} in
an \grammarterm{asm-definition} appertains to the \tcode{asm} declaration.
\begin{note}
Typically it is used to pass information through the implementation to
an assembler.
\end{note}

\rSec1[dcl.link]{Linkage specifications}%
\indextext{specification!linkage|(}

\pnum
All function types, function names with external linkage, and variable
names with external linkage have a \defn{language linkage}.
\begin{note}
Some of the properties associated with an entity with language linkage
are specific to each implementation and are not described here. For
example, a particular language linkage may be associated with a
particular form of representing names of objects and functions with
external linkage, or with a particular calling convention, etc.
\end{note}
The default language linkage of all function types, function names, and
variable names is \Cpp{} language linkage. Two function types with
different language linkages are distinct types even if they are
otherwise identical.

\pnum
\link{Linkage}{\ref{basic.link}} between \Cpp{} and  non-\Cpp{} code fragments can
be achieved using a \grammarterm{linkage-specification}:

\indextext{\idxgram{linkage-specification}}%
\indextext{specification!linkage!\idxcode{extern}}%
%
\begin{bnf}
\nontermdef{linkage-specification}\br
    \terminal{extern} string-literal \terminal{\{} \opt{declaration-seq} \terminal{\}}\br
    \terminal{extern} string-literal declaration
\end{bnf}

The \grammarterm{string-literal} indicates the required language linkage.
This document specifies the semantics for the
\grammarterm{string-literal}{s} \tcode{"C"} and \tcode{"C++"}. Use of a
\grammarterm{string-literal} other than \tcode{"C"} or \tcode{"C++"} is
conditionally-supported, with \impldef{semantics of linkage specifiers} semantics.
\begin{note}
Therefore, a linkage-specification with a \grammarterm{string-literal} that
is unknown to the implementation requires a diagnostic.
\end{note}
\begin{note}
It is recommended that the spelling of the \grammarterm{string-literal} be
taken from the document defining that language. For example, \tcode{Ada}
(not \tcode{ADA}) and \tcode{Fortran} or \tcode{FORTRAN}, depending on
the vintage.
\end{note}

\pnum
\indextext{specification!linkage!implementation-defined}%
Every implementation shall provide for linkage to functions written in
the C programming language,
\indextext{C!linkage to}%
\tcode{"C"}, and linkage to \Cpp{} functions, \tcode{"C++"}.
\begin{example}
\begin{codeblock}
complex sqrt(complex);          // \Cpp{} linkage by default
extern "C" {
  double sqrt(double);          // C linkage
}
\end{codeblock}
\end{example}

\pnum
\indextext{specification!linkage!nesting}%
Linkage specifications nest. When linkage specifications nest, the
innermost one determines the language linkage. A linkage specification
does not establish a scope. A \grammarterm{linkage-specification} shall
occur only in \link{namespace scope}{\ref{basic.scope.namespace}}. In a
\grammarterm{linkage-specification}, the specified language linkage applies
to the function types of all function declarators, function names with
external linkage, and variable names with external linkage declared
within the \grammarterm{linkage-specification}.
\begin{example}
\begin{codeblock}
extern "C"                      // the name \tcode{f1} and its function type have C language linkage;
  void f1(void(*pf)(int));      // \tcode{pf} is a pointer to a C function

extern "C" typedef void FUNC();
FUNC f2;                        // the name \tcode{f2} has \Cpp{} language linkage and the
                                // function's type has C language linkage

extern "C" FUNC f3;             // the name of function \tcode{f3} and the function's type have C language linkage

void (*pf2)(FUNC*);             // the name of the variable \tcode{pf2} has \Cpp{} linkage and the type
                                // of \tcode{pf2} is ``pointer to \Cpp{} function that takes one parameter of type
                                // pointer to C function''
extern "C" {
  static void f4();             // the name of the function \tcode{f4} has internal linkage (not C language linkage)
                                // and the function's type has C language linkage.
}

extern "C" void f5() {
  extern void f4();             // OK: Name linkage (internal) and function type linkage (C language linkage)
                                // obtained from previous declaration.
}

extern void f4();               // OK: Name linkage (internal) and function type linkage (C language linkage)
                                // obtained from previous declaration.

void f6() {
  extern void f4();             // OK: Name linkage (internal) and function type linkage (C language linkage)
                                // obtained from previous declaration.
}
\end{codeblock}
\end{example}
\indextext{class!linkage specification}%
A C language linkage is ignored
in determining the language linkage of
the names of class members and the
function type of class member functions.
\begin{example}
\begin{codeblock}
extern "C" typedef void FUNC_c();

class C {
  void mf1(FUNC_c*);            // the name of the function \tcode{mf1} and the member function's type have
                                // \Cpp{} language linkage; the parameter has type ``pointer to C function''

  FUNC_c mf2;                   // the name of the function \tcode{mf2} and the member function's type have
                                // \Cpp{} language linkage

  static FUNC_c* q;             // the name of the data member \tcode{q} has \Cpp{} language linkage and
                                // the data member's type is ``pointer to C function''
};

extern "C" {
  class X {
    void mf();                  // the name of the function \tcode{mf} and the member function's type have
                                // \Cpp{} language linkage
    void mf2(void(*)());        // the name of the function \tcode{mf2} has \Cpp{} language linkage;
                                // the parameter has type ``pointer to C function''
  };
}
\end{codeblock}
\end{example}

\pnum
If two declarations declare functions with the same name and
\deflink{parameter-type-list}{\ref{dcl.fct}} to be members of the same
namespace or declare objects with the same name to be members of the same
namespace and the declarations give the names different language linkages, the
program is ill-formed; no diagnostic is required if the declarations appear in
different translation units.
\indextext{consistency!linkage specification}%
Except for functions with \Cpp{} linkage, a function declaration without a
linkage specification shall not precede the first linkage specification
for that function. A function can be declared without a linkage
specification after an explicit linkage specification has been seen; the
linkage explicitly specified in the earlier declaration is not affected
by such a function declaration.

\pnum
\indextext{function!linkage specification overloaded}%
At most one function with a particular name can have C language linkage.
Two declarations for a function with C language linkage with the same
function name (ignoring the namespace names that qualify it) that appear
in different namespace scopes refer to the same function. Two
declarations for a variable with C language linkage with the same name
(ignoring the namespace names that qualify it) that appear in different
namespace scopes refer to the same variable.
An entity with C language linkage shall not be declared with the same name
as a variable in global scope, unless both declarations denote the same entity;
no diagnostic is required if the declarations appear in different translation units.
A variable with C language linkage shall not be declared with the same name as a
function with C language linkage (ignoring the namespace names that qualify the
respective names); no diagnostic is required if the declarations appear in
different translation units.
\begin{note}
Only
one definition for an entity with a given name
with C language linkage may appear in the
program (see~\ref{basic.def.odr});
this implies that such an entity
must not be defined in more
than one namespace scope.\end{note}
\begin{example}

\begin{codeblock}
int x;
namespace A {
  extern "C" int f();
  extern "C" int g() { return 1; }
  extern "C" int h();
  extern "C" int x();               // ill-formed: same name as global-space object \tcode{x}
}

namespace B {
  extern "C" int f();               // \tcode{A::f} and \tcode{B::f} refer to the same function
  extern "C" int g() { return 1; }  // ill-formed, the function \tcode{g} with C language linkage has two definitions
}

int A::f() { return 98; }           // definition for the function \tcode{f} with C language linkage
extern "C" int h() { return 97; }   // definition for the function \tcode{h} with C language linkage
                                    // \tcode{A::h} and \tcode{::h} refer to the same function
\end{codeblock}
\end{example}

\pnum
A declaration directly contained in a
\grammarterm{linkage-specification}
is treated as if it contains the
\linkx{\tcode{extern}
specifier}{extern}{\ref{dcl.stc}} for the purpose of determining the linkage of the
declared name and whether it is a definition. Such a declaration shall
not specify a storage class.
\begin{example}

\begin{codeblock}
extern "C" double f();
static double f();                  // error
extern "C" int i;                   // declaration
extern "C" {
  int i;                            // definition
}
extern "C" static void g();         // error
\end{codeblock}
\end{example}

\pnum
\begin{note}
Because the language linkage is part of a function type, when
indirecting through a pointer to C function, the function to
which the resulting lvalue refers is considered a C function.
\end{note}

\pnum
\indextext{object!linkage specification}%
\indextext{linkage!implementation-defined object}%
Linkage from \Cpp{} to objects defined in other languages and to objects
defined in \Cpp{} from other languages is \impldef{linkage of objects between \Cpp{} and other languages} and
language-dependent. Only where the object layout strategies of two
language implementations are similar enough can such linkage be
achieved.%
\indextext{specification!linkage|)}

\rSec1[dcl.attr]{Attributes}%
\indextext{attribute|(}

\rSec2[dcl.attr.grammar]{Attribute syntax and semantics}

\pnum
\indextext{attribute!syntax and semantics}%
Attributes specify additional information for various source constructs
such as types, variables, names, blocks, or translation units.

\begin{bnf}
\nontermdef{attribute-specifier-seq}\br
  \opt{attribute-specifier-seq} attribute-specifier
\end{bnf}

\begin{bnf}
\nontermdef{attribute-specifier}\br
  \terminal{[} \terminal{[} \opt{attribute-using-prefix} attribute-list \terminal{]} \terminal{]}\br
  alignment-specifier
\end{bnf}

\begin{bnf}
\nontermdef{alignment-specifier}\br
  \terminal{alignas (} type-id \opt{\terminal{...}} \terminal{)}\br
  \terminal{alignas (} constant-expression \opt{\terminal{...}} \terminal{)}
\end{bnf}

\begin{bnf}
\nontermdef{attribute-using-prefix}\br
  \terminal{using} attribute-namespace \terminal{:}
\end{bnf}

\begin{bnf}
\nontermdef{attribute-list}\br
  \opt{attribute}\br
  attribute-list \terminal{,} \opt{attribute}\br
  attribute \terminal{...}\br
  attribute-list \terminal{,} attribute \terminal{...}
\end{bnf}

\begin{bnf}
\nontermdef{attribute}\br
    attribute-token \opt{attribute-argument-clause}
\end{bnf}

\begin{bnf}
\nontermdef{attribute-token}\br
    identifier\br
    attribute-scoped-token
\end{bnf}

\begin{bnf}
\nontermdef{attribute-scoped-token}\br
    attribute-namespace \terminal{::} identifier
\end{bnf}

\begin{bnf}
\nontermdef{attribute-namespace}\br
    identifier
\end{bnf}

\begin{bnf}
\nontermdef{attribute-argument-clause}\br
    \terminal{(} \opt{balanced-token-seq} \terminal{)}
\end{bnf}

\begin{bnf}
\nontermdef{balanced-token-seq}\br
    balanced-token\br
    balanced-token-seq balanced-token
\end{bnf}

\begin{bnf}
\nontermdef{balanced-token}\br
    \terminal{(} \opt{balanced-token-seq} \terminal{)}\br
    \terminal{[} \opt{balanced-token-seq} \terminal{]}\br
    \terminal{\{} \opt{balanced-token-seq} \terminal{\}}\br
    \textnormal{any \grammarterm{token} other than a parenthesis, a bracket, or a brace}
\end{bnf}

\pnum
If an \grammarterm{attribute-specifier}
contains an \grammarterm{attribute-using-prefix},
the \grammarterm{attribute-list} following that \grammarterm{attribute-using-prefix}
shall not contain an \grammarterm{attribute-scoped-token}
and every \grammarterm{attribute-token} in that \grammarterm{attribute-list}
is treated as if
its \grammarterm{identifier} were prefixed with \tcode{N::},
where \tcode{N} is the \grammarterm{attribute-namespace}
specified in the \grammarterm{attribute-using-prefix}.
\begin{note}
This rule imposes no constraints on how
an \grammarterm{attribute-using-prefix}
affects the tokens in an \grammarterm{attribute-argument-clause}.
\end{note}
\begin{example}
\begin{codeblock}
[[using CC: opt(1), debug]]         // same as \tcode{[[CC::opt(1), CC::debug]]}
  void f() {}
[[using CC: opt(1)]] [[CC::debug]]  // same as \tcode{[[CC::opt(1)]] [[CC::debug]]}
  void g() {}
[[using CC: CC::opt(1)]]            // error: cannot combine \tcode{using} and scoped attribute token
  void h() {}
\end{codeblock}
\end{example}

\pnum
\begin{note} For each individual attribute, the form of the
\grammarterm{balanced-token-seq} will be specified. \end{note}

\pnum
In an \grammarterm{attribute-list}, an ellipsis may appear only if that
\grammarterm{attribute}'s specification permits it. An \grammarterm{attribute} followed
by an ellipsis is a \deflink{pack expansion}{\ref{temp.variadic}}.
An \grammarterm{attribute-specifier} that contains no \grammarterm{attribute}{s} has no
effect. The order in which the \grammarterm{attribute-token}{s} appear in an
\grammarterm{attribute-list} is not significant. If a
\link{keyword}{\ref{lex.key}}
or an \link{alternative token}{\ref{lex.digraph}} that satisfies the syntactic requirements
of an \grammarterm{identifier}\iref{lex.name} is
contained in
an \grammarterm{attribute-token}, it is considered an identifier. No
\link{name lookup}{\ref{basic.lookup}} is performed on any of the identifiers contained in an
\grammarterm{attribute-token}. The \grammarterm{attribute-token} determines additional
requirements on the \grammarterm{attribute-argument-clause} (if any).

\pnum
Each \grammarterm{attribute-specifier-seq} is said to \defn{appertain} to some entity or
statement, identified by the syntactic context where it appears
(\ref{stmt.stmt}, \ref{dcl.dcl},
\ref{dcl.decl}). If an \grammarterm{attribute-specifier-seq} that appertains to some
entity or statement contains an \grammarterm{attribute} or \grammarterm{alignment-specifier} that
is not allowed to apply to that
entity or statement, the program is ill-formed. If an \grammarterm{attribute-specifier-seq}
appertains to a \link{friend declaration}{\ref{class.friend}}, that declaration shall be a
definition. No \grammarterm{attribute-specifier-seq} shall appertain to an
\link{explicit instantiation}{\ref{temp.explicit}}.

\pnum
For an \grammarterm{attribute-token}
(including an \grammarterm{attribute-scoped-token})
not specified in this document, the
behavior is \impldef{behavior of non-standard attributes}.
Any \grammarterm{attribute-token} that is not recognized by the implementation
is ignored.
\begin{note}
Each implementation should choose a distinctive name for the
\grammarterm{attribute-namespace} in an \grammarterm{attribute-scoped-token}.
\end{note}

\pnum
Two consecutive left square bracket tokens shall appear only
when introducing an \grammarterm{attribute-specifier} or
within the \grammarterm{balanced-token-seq} of
an \grammarterm{attribute-argument-clause}.
\begin{note} If two consecutive left square brackets appear
where an \grammarterm{attribute-specifier} is not allowed, the program is ill-formed even
if the brackets match an alternative grammar production. \end{note} \begin{example}
\begin{codeblock}
int p[10];
void f() {
  int x = 42, y[5];
  int(p[[x] { return x; }()]);  // error: invalid attribute on a nested \grammarterm{declarator-id} and
                                // not a function-style cast of an element of \tcode{p}.
  y[[] { return 2; }()] = 2;    // error even though attributes are not allowed in this context.
  int i [[vendor::attr([[]])]]; // well-formed implementation-defined attribute.
}
\end{codeblock}
\end{example}

\rSec2[dcl.align]{Alignment specifier}%
\indextext{attribute!alignment}
\indextext{\idxcode{alignas}}

\pnum
An \grammarterm{alignment-specifier}
may be applied to a variable
or to a class data member, but it shall not be applied to a bit-field, a function
parameter, or an \grammarterm{exception-declaration}\iref{except.handle}.
An \grammarterm{alignment-specifier} may also be applied to the declaration or
definition of a class (in an
\grammarterm{elaborated-type-specifier}\iref{dcl.type.elab} or
\grammarterm{class-head}\iref{class}, respectively) and to the
declaration or definition of an enumeration (in an
\grammarterm{opaque-enum-declaration} or \grammarterm{enum-head},
respectively).
An \grammarterm{alignment-specifier} with an ellipsis is a \deflink{pack expansion}{\ref{temp.variadic}}.

\pnum
When the \grammarterm{alignment-specifier} is of the form
\tcode{alignas(} \grammarterm{constant-expression} \tcode{)}:
\begin{itemize}
\item the \grammarterm{constant-expression} shall be an integral constant expression

\item if the constant expression does not evaluate to an alignment
value\iref{basic.align}, or evaluates to an extended alignment and
the implementation does not support that alignment in the context of the
declaration, the program is ill-formed.
\end{itemize}

\pnum
An \grammarterm{alignment-specifier} of the form
\tcode{alignas(} \grammarterm{type-id} \tcode{)} has the same
effect as \tcode{alignas(\brk{}\link{alignof}{expr.alignof}(} \grammarterm{type-id}~\tcode{))}.

\pnum
The alignment requirement of an entity is the strictest nonzero alignment
specified by its \grammarterm{alignment-specifier}{s}, if any;
otherwise, the \grammarterm{alignment-specifier}{s} have no effect.

\pnum
The combined effect of all \grammarterm{alignment-specifier}{s} in a declaration shall not
specify an alignment that is less strict than the alignment that would
be required for the entity being declared if all \grammarterm{alignment-specifier}{s}
appertaining to that entity
were omitted.
\begin{example}
\begin{codeblock}
struct alignas(8) S {};
struct alignas(1) U {
  S s;
};  // error: \tcode{U} specifies an alignment that is less strict than if the \tcode{alignas(1)} were omitted.
\end{codeblock}
\end{example}

\pnum
If the defining declaration of an entity has an
\grammarterm{alignment-specifier}{}, any non-defining
declaration of that entity shall either specify equivalent alignment or have no
\grammarterm{alignment-specifier}{}.
Conversely, if any declaration of an entity has an
\grammarterm{alignment-specifier}{},
every defining
declaration of that entity shall specify an equivalent alignment.
No diagnostic is required if declarations of an entity have
different \grammarterm{alignment-specifier}{s}
in different translation units.
\begin{example}
\begin{codeblock}
// Translation unit \#1:
struct S { int x; } s, *p = &s;

// Translation unit \#2:
struct alignas(16) S;           // error: definition of \tcode{S} lacks alignment, no diagnostic required
extern S* p;
\end{codeblock}
\end{example}

\pnum
\begin{example} An aligned buffer with an alignment requirement
of \tcode{A} and holding \tcode{N} elements of type \tcode{T}
can be declared as:
\begin{codeblock}
alignas(T) alignas(A) T buffer[N];
\end{codeblock}
Specifying \tcode{alignas(T)} ensures
that the final requested alignment will not be weaker than \tcode{alignof(T)},
and therefore the program will not be ill-formed.
\end{example}

\pnum
\begin{example}
\begin{codeblock}
alignas(double) void f();                           // error: alignment applied to function
alignas(double) unsigned char c[sizeof(double)];    // array of characters, suitably aligned for a \tcode{double}
extern unsigned char c[sizeof(double)];             // no \tcode{alignas} necessary
alignas(float)
  extern unsigned char c[sizeof(double)];           // error: different alignment in declaration
\end{codeblock}
\end{example}

\rSec2[dcl.attr.depend]{Carries dependency attribute}%
\indextext{attribute!carries dependency}

\pnum
The \grammarterm{attribute-token} \tcode{carries_dependency} specifies
dependency propagation into and out of functions. It shall appear at most once
in each \grammarterm{attribute-list} and no
\grammarterm{attribute-argument-clause} shall be present. The attribute may be
applied to the \grammarterm{declarator-id} of a
\grammarterm{parameter-declaration} in a function declaration or lambda, in
which case it specifies that the initialization of the parameter
\deflink{carries a dependency}{\ref{intro.multithread}} to each \link{lvalue-to-rvalue
conversion}{\ref{conv.lval}} of that object. The attribute may also be applied
to the \grammarterm{declarator-id} of a function declaration, in which case it
specifies that the return value, if any, carries a dependency to the evaluation
of the function call expression.

\pnum
The first declaration of a function shall specify the \tcode{carries_dependency} attribute for its
\grammarterm{declarator-id} if any declaration of the function specifies the
\tcode{carries_dependency} attribute. Furthermore, the first declaration of a function shall specify
the \tcode{carries_dependency} attribute for a parameter if any declaration of that function
specifies the \tcode{carries_dependency} attribute for that parameter. If a function or one of its
parameters is declared with the \tcode{carries_dependency} attribute in its first declaration in one
translation unit and the same function or one of its parameters is declared without the
\tcode{carries_dependency} attribute in its first declaration in another translation unit, the
program is ill-formed, no diagnostic required.

\pnum
\begin{note} The \tcode{carries_dependency} attribute does not change the meaning of the
program, but may result in generation of more efficient code. \end{note}

\pnum
\begin{example}
\begin{codeblock}
/* Translation unit A. */

struct foo { int* a; int* b; };
std::atomic<struct foo *> foo_head[10];
int foo_array[10][10];

[[carries_dependency]] struct foo* f(int i) {
  return foo_head[i].load(memory_order::consume);
}

int g(int* x, int* y [[carries_dependency]]) {
  return kill_dependency(foo_array[*x][*y]);
}

/* Translation unit B. */

[[carries_dependency]] struct foo* f(int i);
int g(int* x, int* y [[carries_dependency]]);

int c = 3;

void h(int i) {
  struct foo* p;

  p = f(i);
  do_something_with(g(&c, p->a));
  do_something_with(g(p->a, &c));
}
\end{codeblock}

The \tcode{carries_dependency} attribute on function \tcode{f} means that the
return value carries a dependency out of \tcode{f}, so that the implementation
need not constrain ordering upon return from \tcode{f}. Implementations of
\tcode{f} and its caller may choose to preserve dependencies instead of emitting
hardware memory ordering instructions (a.k.a.\ fences).
Function \tcode{g}'s second parameter has a \tcode{carries_dependency} attribute,
but its first parameter does not. Therefore, function \tcode{h}'s first call to
\tcode{g} carries a dependency into \tcode{g}, but its second call does not. The
implementation might need to insert a fence prior to the second call to
\tcode{g}.
\end{example}%
\indextext{attribute|)}%
\indextext{declaration|)}

\rSec2[dcl.attr.deprecated]{Deprecated attribute}%
\indextext{attribute!deprecated}

\pnum
The \grammarterm{attribute-token} \tcode{deprecated} can be used to mark names and entities
whose use is still allowed, but is discouraged for some reason. \begin{note} In particular,
\tcode{deprecated} is appropriate for names and entities that are deemed obsolescent or
unsafe. \end{note} It shall appear at most once in each \grammarterm{attribute-list}. An
\grammarterm{attribute-argument-clause} may be present and, if present, it shall have the form:
\begin{codeblock}
( @\grammarterm{string-literal}@ )
\end{codeblock}
\begin{note} The \grammarterm{string-literal} in the \grammarterm{attribute-argument-clause}
could be used to explain the rationale for deprecation and/or to suggest a replacing entity.
\end{note}

\pnum
The attribute may be applied to the declaration of
a class,
a \grammarterm{typedef-name},
a variable,
a non-static data member,
a function,
a namespace,
an enumeration,
an enumerator, or
a template specialization.

\pnum
A name or entity declared without the \tcode{deprecated} attribute can later be redeclared
with the attribute and vice-versa. \begin{note} Thus, an entity initially declared without the
attribute can be marked as deprecated by a subsequent redeclaration. However, after an entity
is marked as deprecated, later redeclarations do not un-deprecate the entity. \end{note}
Redeclarations using different forms of the attribute (with or without the
\grammarterm{attribute-argument-clause} or with different
\grammarterm{attribute-argument-clause}{s}) are allowed.

\pnum
\begin{note} Implementations may use the \tcode{deprecated} attribute to produce a diagnostic
message in case the program refers to a name or entity other than to declare it, after a
declaration that specifies the attribute. The diagnostic message may include the text provided
within the \grammarterm{attribute-argument-clause} of any \tcode{deprecated} attribute applied
to the name or entity. \end{note}

\rSec2[dcl.attr.fallthrough]{Fallthrough attribute}
\indextext{attribute!fallthrough}

\pnum
The \grammarterm{attribute-token} \tcode{fallthrough}
may be applied to a \deflink{null statement}{\ref{stmt.expr}};
\indextext{statement!fallthrough}
such a statement is a fallthrough statement.
The \grammarterm{attribute-token} \tcode{fallthrough}
shall appear at most once in each \grammarterm{attribute-list} and
no \grammarterm{attribute-argument-clause} shall be present.
A fallthrough statement may only appear within
an enclosing \link{\tcode{switch} statement}{\ref{stmt.switch}}.
The next statement that would be executed after a fallthrough statement
shall be a labeled statement whose label is a case label or
default label for the same \tcode{switch} statement.
The program is ill-formed if there is no such statement.

\pnum
\begin{note}
The use of a fallthrough statement is intended to suppress
a warning that an implementation might otherwise issue
for a case or default label that is reachable
from another case or default label along some path of execution.
Implementations should issue a warning
if a fallthrough statement is not dynamically reachable.
\end{note}

\pnum
\begin{example}
\begin{codeblock}
void f(int n) {
  void g(), h(), i();
  switch (n) {
  case 1:
  case 2:
    g();
    [[fallthrough]];
  case 3:                       // warning on fallthrough discouraged
    h();
  case 4:                       // implementation may warn on fallthrough
    i();
    [[fallthrough]];            // ill-formed
  }
}
\end{codeblock}
\end{example}

\rSec2[dcl.attr.likelihood]{Likelihood attributes}%
\indextext{attribute!likely}
\indextext{attribute!unlikely}

\pnum
The \grammarterm{attribute-token}s
\tcode{likely} and \tcode{unlikely}
may be applied to labels or statements.
The \grammarterm{attribute-token}s
\tcode{likely} and \tcode{unlikely}
shall appear at most once in each \grammarterm{attribute-list}
and no \grammarterm{attribute-argument-clause} shall be present.
The \grammarterm{attribute-token} \tcode{likely}
shall not appear in an \grammarterm{attribute-specifier-seq}
that contains the \grammarterm{attribute-token} \tcode{unlikely}.

\pnum
\begin{note}
The use of the \tcode{likely} attribute
is intended to allow implementations to optimize for
the case where paths of execution including it
are arbitrarily more likely
than any alternative path of execution
that does not include such an attribute on a statement or label.
The use of the \tcode{unlikely} attribute
is intended to allow implementations to optimize for
the case where paths of execution including it
are arbitrarily more unlikely
than any alternative path of execution
that does not include such an attribute on a statement or label.
A path of execution includes a label
if and only if it contains a jump to that label.
Excessive usage of either of these attributes
is liable to result in performance degradation.
\end{note}

\pnum
\begin{example}
\begin{codeblock}
void g(int);
int f(int n) {
  if (n > 5) [[unlikely]] {     // \tcode{n > 5} is considered to be arbitrarily unlikely
    g(0);
    return n * 2 + 1;
  }

  switch (n) {
  case 1:
    g(1);
    [[fallthrough]];

  [[likely]] case 2:            // \tcode{n == 3} is considered to be arbitrarily more
    g(2);                       // likely than any other value of \tcode{n}
    break;
  }
  return 3;
}
\end{codeblock}
\end{example}

\rSec2[dcl.attr.unused]{Maybe unused attribute}%
\indextext{attribute!maybe unused}

\pnum
The \grammarterm{attribute-token} \tcode{maybe_unused}
indicates that a name or entity is possibly intentionally unused.
It shall appear at most once in each \grammarterm{attribute-list} and
no \grammarterm{attribute-argument-clause} shall be present.

\pnum
The attribute may be applied to the declaration of a class,
a \grammarterm{typedef-name}, a variable, a non-static data member,
a function, an enumeration, or an enumerator.

\pnum
\begin{note}
For an entity marked \tcode{maybe_unused}, implementations
should not emit a warning that the entity is unused, or
that the entity is used despite the presence of the attribute.
\end{note}

\pnum
A name or entity declared without the \tcode{maybe_unused} attribute
can later be redeclared with the attribute
and vice versa.
An entity is considered marked
after the first declaration that marks it.

\pnum
\begin{example}
\begin{codeblock}
[[maybe_unused]] void f([[maybe_unused]] bool thing1,
                        [[maybe_unused]] bool thing2) {
  [[maybe_unused]] bool b = thing1 && thing2;
  assert(b);
}
\end{codeblock}
Implementations should not warn that \tcode{b} is unused,
whether or not \tcode{NDEBUG} is defined.
\end{example}

\rSec2[dcl.attr.nodiscard]{Nodiscard attribute}%
\indextext{attribute!nodiscard}

\pnum
The \grammarterm{attribute-token} \tcode{nodiscard}
may be applied to the \grammarterm{declarator-id}
in a function declaration or to the declaration of a class or enumeration.
It shall appear at most once in each \grammarterm{attribute-list} and
no \grammarterm{attribute-argument-clause} shall be present.

\pnum
\begin{note}
A nodiscard call is a function call expression that
calls a function previously declared \tcode{nodiscard}, or
whose return type is a possibly cv-qualified class or enumeration type
marked \tcode{nodiscard}. Appearance of a nodiscard call as
a potentially-evaluated \deflink{discarded-value expression}{\ref{expr.prop}}
is discouraged unless explicitly cast to \tcode{void}.
Implementations should issue a warning in such cases.
This is typically because discarding the return value
of a nodiscard call has surprising consequences.
\end{note}

\pnum
\begin{example}
\begin{codeblock}
struct [[nodiscard]] error_info { @\commentellip@ };
error_info enable_missile_safety_mode();
void launch_missiles();
void test_missiles() {
  enable_missile_safety_mode(); // warning encouraged
  launch_missiles();
}
error_info &foo();
void f() { foo(); }             // warning not encouraged: not a nodiscard call, because neither
                                // the (reference) return type nor the function is declared nodiscard
\end{codeblock}
\end{example}

\rSec2[dcl.attr.noreturn]{Noreturn attribute}%
\indextext{attribute!noreturn}

\pnum
The \grammarterm{attribute-token} \tcode{noreturn} specifies that a function does not return. It
shall appear at most once in each \grammarterm{attribute-list} and no
\grammarterm{attribute-argument-clause} shall be present. The attribute may be applied to the
\grammarterm{declarator-id} in a function declaration. The first declaration of a function shall
specify the \tcode{noreturn} attribute if any declaration of that function specifies the
\tcode{noreturn} attribute. If a function is declared with the \tcode{noreturn} attribute in one
translation unit and the same function is declared without the \tcode{noreturn} attribute in another
translation unit, the program is ill-formed, no diagnostic required.

\pnum
If a function \tcode{f} is called where \tcode{f} was previously declared with the \tcode{noreturn}
attribute and \tcode{f} eventually returns, the behavior is undefined. \begin{note} The function may
terminate by throwing an exception. \end{note} \begin{note} Implementations should issue a
warning if a function marked \tcode{[[noreturn]]} might return. \end{note}

\pnum
\begin{example}
\begin{codeblock}
[[ noreturn ]] void f() {
  throw "error";                // OK
}

[[ noreturn ]] void q(int i) {  // behavior is undefined if called with an argument \tcode{<= 0}
  if (i > 0)
    throw "positive";
}
\end{codeblock}
\end{example}

\rSec2[dcl.attr.nouniqueaddr]{No unique address attribute}%
\indextext{attribute!no unique address}

\pnum
The \grammarterm{attribute-token} \tcode{no_unique_address}
specifies that a non-static data member
is a potentially-overlapping subobject\iref{intro.object}.
It shall appear at most once in each \grammarterm{attribute-list}
and no \grammarterm{attribute-argument-clause} shall be present.
The attribute may appertain to a non-static data member
other than a bit-field.

\pnum
\begin{note}
The non-static data member can share the address of
another non-static data member or that of a base class,
and any padding that would normally be inserted
at the end of the object
can be reused as storage for other members.
\end{note}
\begin{example}
\begin{codeblock}
template<typename Key, typename Value,
         typename Hash, typename Pred, typename Allocator>
class hash_map {
  [[no_unique_address]] Hash hasher;
  [[no_unique_address]] Pred pred;
  [[no_unique_address]] Allocator alloc;
  Bucket *buckets;
  // ...
public:
  // ...
};
\end{codeblock}
Here, \tcode{hasher}, \tcode{pred}, and \tcode{alloc}
could have the same address as \tcode{buckets}
if their respective types are all empty.
\end{example}