\rSec0[basic]{Basics}

\gramSec[gram.basic]{Basics}

\rSec1[basic.pre]{Preamble}

\begin{note}

This Clause presents the basic concepts of the \Cpp{} language.

It explains the difference between an object and a

name and how they relate to the value categories for expressions.

It introduces the concepts of a

declaration and a definition and presents \Cpp{}'s

notion of type, scope, linkage, and

storage duration. The mechanisms for starting and

terminating a program are discussed. Finally, this Clause presents the

fundamental types of the language and lists the ways of constructing

compound types from these.

\end{note}

\begin{note}

This Clause does not cover concepts that affect only a single

part of the language. Such concepts are discussed in the relevant

Clauses.

\end{note}

\indextext{type}%

\indextext{object}%

\indextext{storage class}%

\indextext{scope}%

\indextext{linkage}%

An \defn{entity} is a value, object, reference,

structured binding,

function, enumerator, type,

class member, bit-field, template, template specialization, namespace, or

pack.

A \defn{name} is an \grammarterm{identifier}\iref{lex.name},

\grammarterm{operator-function-id}\iref{over.oper},

\grammarterm{literal-operator-id}\iref{over.literal}, or

\grammarterm{conversion-function-id}\iref{class.conv.fct}.

Every name is introduced by a \defn{declaration}, which is a

\begin{itemize}

\grammarterm{declaration},

\grammarterm{block-declaration}, or

\grammarterm{member-declaration} (\ref{dcl.pre}, \ref{class.mem}),

\grammarterm{init-declarator}\iref{dcl.decl},

\grammarterm{identifier}

in a structured binding declaration\iref{dcl.struct.bind},

\grammarterm{init-capture}\iref{expr.prim.lambda.capture},

\grammarterm{condition} with a \grammarterm{declarator}\iref{stmt.pre},

\grammarterm{member-declarator}\iref{class.mem},

\grammarterm{using-declarator}\iref{namespace.udecl},

\grammarterm{parameter-declaration}\iref{dcl.fct},

\grammarterm{type-parameter}\iref{temp.param},

\grammarterm{elaborated-type-specifier}

that introduces a name\iref{dcl.type.elab},

\grammarterm{class-specifier}\iref{class.pre},

\grammarterm{enum-specifier} or

\grammarterm{enumerator-definition}\iref{dcl.enum},

\grammarterm{exception-declaration}\iref{except.pre}, or

implicit declaration of an injected-class-name\iref{class.pre}.

\end{itemize}

\begin{note}

The interpretation of a \grammarterm{for-range-declaration} produces

one or more of the above\iref{stmt.ranged}.

\end{note}

An entity $E$ is denoted by the name (if any)

that is introduced by a declaration of $E$ or

by a \grammarterm{typedef-name} introduced by a declaration specifying $E$.

A \defn{variable} is introduced by the

declaration of

a reference other than a non-static data member or of

an object. The variable's name, if any, denotes the reference or object.

A \defnadj{local}{entity} is a variable with

automatic storage duration\iref{basic.stc.auto},

a structured binding\iref{dcl.struct.bind}

whose corresponding variable is such an entity,

or the \tcode{*this} object\iref{expr.prim.this}.

Some names denote types or templates. In general,

whenever a name is encountered it is necessary to determine whether that name denotes

one of these entities before continuing to parse the program that contains it. The

process that determines this is called

\defnx{name lookup}{lookup!name}\iref{basic.lookup}.

Two names are \defnx{the same}{name!same} if

\begin{itemize}

\item they are \grammarterm{identifier}{s} composed of the same character sequence, or

\item they are \grammarterm{operator-function-id}{s} formed with

the same operator, or

\item they are \grammarterm{conversion-function-id}{s} formed

with equivalent\iref{temp.over.link} types, or

\item they are \grammarterm{literal-operator-id}{s}\iref{over.literal} formed with

the same literal suffix identifier.

\end{itemize}

\indextext{translation unit!name and}%

\indextext{linkage}%

A name used in more than one translation unit can potentially

refer to the same entity in these translation units depending on the

linkage\iref{basic.link} of the name specified in each

translation unit.

\rSec1[basic.def]{Declarations and definitions}

\indextext{declaration!definition versus}%

\indextext{declaration}%

\indextext{declaration!name}%

A declaration\iref{dcl.dcl} may (re)introduce

one or more names and/or entities into a translation

unit.

If so, the

declaration specifies the interpretation and semantic properties of these names.

A declaration of an entity or \grammarterm{typedef-name} $X$ is

a redeclaration of $X$

if another declaration of $X$ is reachable from it\iref{module.reach}.

A declaration may also have effects including:

\begin{itemize}

\item a static assertion\iref{dcl.pre},

\item controlling template instantiation\iref{temp.explicit},

\item guiding template argument deduction for constructors\iref{temp.deduct.guide},

\item use of attributes\iref{dcl.attr}, and

\item nothing (in the case of an \grammarterm{empty-declaration}).

\end{itemize}

\indextext{declaration!function}%

\indextext{definition}%

Each entity declared by a \grammarterm{declaration} is

also \defnx{defined}{define} by that declaration unless:

\begin{itemize}

it declares a function

without specifying the function's body\iref{dcl.fct.def},

it contains

the

\indextext{declaration!\idxcode{extern}}%

\tcode{extern} specifier\iref{dcl.stc} or a

\grammarterm{linkage-specification}

\begin{footnote}

Appearing inside the brace-enclosed

\grammarterm{declaration-seq} in a \grammarterm{linkage-specification} does

not affect whether a declaration is a definition.

\end{footnote}

\iref{dcl.link}

and neither an \grammarterm{initializer} nor a

\grammarterm{function-body},

\indextext{declaration!static member@\tcode{static} member}%

it declares a non-inline static data member in a class

definition~(\ref{class.mem}, \ref{class.static}),

it declares a static data member outside a class definition

and the variable was defined within the class with the \tcode{constexpr}

specifier (this usage is deprecated; see \ref{depr.static.constexpr}),

\indextext{declaration!class name}%

it is an \grammarterm{elaborated-type-specifier}\iref{class.name},

it is an

\indextext{declaration!opaque enum}%

\grammarterm{opaque-enum-declaration}\iref{dcl.enum},

it is a

\indextext{parameter!template}\indextext{template parameter}%

\grammarterm{template-parameter}\iref{temp.param},

it is a

\indextext{declaration!parameter}\indextext{parameter declaration}%

\grammarterm{parameter-declaration}\iref{dcl.fct} in a function

\indextext{declarator}%

declarator that is not the \grammarterm{declarator} of a

\grammarterm{function-definition},

it is a

\indextext{declaration!\idxcode{typedef}}%

\tcode{typedef} declaration\iref{dcl.typedef},

\item it is

an \grammarterm{alias-declaration}\iref{dcl.typedef},

\item it is

a

\grammarterm{using-declaration}\iref{namespace.udecl},

\item it is

a \grammarterm{deduction-guide}\iref{temp.deduct.guide},

\item it is

a \grammarterm{static_assert-declaration}\iref{dcl.pre},

it is an

\grammarterm{attribute-declaration}\iref{dcl.pre},

it is an

\grammarterm{empty-declaration}\iref{dcl.pre},

\item it is

a \grammarterm{using-directive}\iref{namespace.udir},

\item it is

a \grammarterm{using-enum-declaration}\iref{enum.udecl},

\item it is

a \grammarterm{template-declaration}\iref{temp.pre}

whose \grammarterm{template-head} is not followed by

either a \grammarterm{concept-definition} or a \grammarterm{declaration}

that defines a function, a class, a variable, or a static data member.

\item it is

an explicit instantiation declaration\iref{temp.explicit}, or

\item it is

an explicit specialization\iref{temp.expl.spec} whose

\grammarterm{declaration} is not a definition.

\end{itemize}

A declaration is said to be a \defn{definition} of each entity that it defines.

\begin{example}

All but one of the following are definitions:

\begin{codeblock}

int a; // defines \tcode{a}

extern const int c = 1; // defines \tcode{c}

int f(int x) { return x+a; } // defines \tcode{f} and defines \tcode{x}

struct S { int a; int b; }; // defines \tcode{S}, \tcode{S::a}, and \tcode{S::b}

struct X { // defines \tcode{X}

int x; // defines non-static data member \tcode{x}

static int y; // declares static data member \tcode{y}

X(): x(0) { } // defines a constructor of \tcode{X}

};

int X::y = 1; // defines \tcode{X::y}

enum { up, down }; // defines \tcode{up} and \tcode{down}

namespace N { int d; } // defines \tcode{N} and \tcode{N::d}

namespace N1 = N; // defines \tcode{N1}

X anX; // defines \tcode{anX}

\end{codeblock}

whereas these are just declarations:

\begin{codeblock}

extern int a; // declares \tcode{a}

extern const int c; // declares \tcode{c}

int f(int); // declares \tcode{f}

struct S; // declares \tcode{S}

typedef int Int; // declares \tcode{Int}

extern X anotherX; // declares \tcode{anotherX}

using N::d; // declares \tcode{d}

\end{codeblock}

\end{example}

\begin{note}

\indextext{implementation-generated}%

In some circumstances, \Cpp{} implementations implicitly define the

default constructor\iref{class.default.ctor},

copy constructor, move constructor\iref{class.copy.ctor},

copy assignment operator, move assignment operator\iref{class.copy.assign},

or destructor\iref{class.dtor} member functions.

\end{note}

\begin{example}

Given

\begin{codeblock}

#include <string>

struct C {

std::string s; // \tcode{std::string} is the standard library class\iref{string.classes}

};

int main() {

C a;

C b = a;

b = a;

}

\end{codeblock}

the implementation will implicitly define functions to make the

definition of \tcode{C} equivalent to

\begin{codeblock}

struct C {

std::string s;

C() : s() { }

C(const C& x): s(x.s) { }

C(C&& x): s(static_cast<std::string&&>(x.s)) { }

@\rlap{\normalfont\itshape //}@ : s(std::move(x.s)) { }

C& operator=(const C& x) { s = x.s; return *this; }

C& operator=(C&& x) { s = static_cast<std::string&&>(x.s); return *this; }

@\rlap{\normalfont\itshape //}@ { s = std::move(x.s); return *this; }

~C() { }

};

\end{codeblock}

\end{example}

\begin{note}

A class name can also be implicitly declared by an

\grammarterm{elaborated-type-specifier}\iref{dcl.type.elab}.

\end{note}

\indextext{type!incomplete}%

In the definition of an object,

the type of that object shall not be

an incomplete type\iref{basic.types},

an abstract class type\iref{class.abstract}, or

a (possibly multi-dimensional) array thereof.

\rSec1[basic.def.odr]{One-definition rule}%

\indextext{object!definition}%

\indextext{function!definition}%

\indextext{class!definition}%

\indextext{enumerator!definition}%

\indextext{one-definition rule|(}%

No translation unit shall contain more than one definition of any

variable, function, class type, enumeration type, template,

default argument for a parameter (for a function in a given scope), or

default template argument.

\indextext{expression!potentially evaluated}%

An expression or conversion is \defn{potentially evaluated} unless it is

an unevaluated operand\iref{expr.prop},

a subexpression thereof, or

a conversion in an initialization or conversion sequence in such a context.

The set of \defn{potential results} of an expression $E$ is

defined as follows:

\begin{itemize}

\item If $E$ is an

\grammarterm{id-expression}\iref{expr.prim.id}, the set

contains only $E$.

\item If $E$ is a subscripting operation\iref{expr.sub} with

an array operand, the set contains the potential results of that operand.

\item If $E$ is a class member access

expression\iref{expr.ref} of the form

$E_1$ \tcode{.} \opt{\keyword{template}} $E_2$

naming a non-static data member,

the set contains the potential results of $E_1$.

\item If $E$ is a class member access expression

naming a static data member,

the set contains the \grammarterm{id-expression} designating the data member.

\item If $E$ is a pointer-to-member

expression\iref{expr.mptr.oper} of the form

$E_1$ \tcode{.*} $E_2$,

the set contains the potential results of $E_1$.

\item If $E$ has the form \tcode{($E_1$)}, the set contains the

potential results of $E_1$.

\item If $E$ is a glvalue conditional

expression\iref{expr.cond}, the set is the union of the sets of

potential results of the second and third operands.

\item If $E$ is a comma expression\iref{expr.comma}, the set

contains the potential results of the right operand.

\item Otherwise, the set is empty.

\end{itemize}

\begin{note}

This set is a (possibly-empty) set of \grammarterm{id-expression}{s},

each of which is either $E$ or a subexpression of $E$.

\begin{example}

In the following example, the set of potential results of the initializer

of \tcode{n} contains the first \tcode{S::x} subexpression, but not the second

\tcode{S::x} subexpression.

\begin{codeblock}

struct S { static const int x = 0; };

const int &f(const int &r);

int n = b ? (1, S::x) // \tcode{S::x} is not odr-used here

: f(S::x); // \tcode{S::x} is odr-used here, so a definition is required

\end{codeblock}

\end{example}

\end{note}

A function is \defnx{named by}{function!named by expression or conversion}

an expression or conversion as follows:

\begin{itemize}

A function is named by an expression or conversion

if it is the selected member

of an overload set~(\ref{basic.lookup}, \ref{over.match}, \ref{over.over})

in an overload resolution performed

as part of forming that expression or conversion,

unless it is a pure virtual function and either

the expression is not an \grammarterm{id-expression} naming the function with

an explicitly qualified name or

the expression forms a pointer to member\iref{expr.unary.op}.

\begin{note}

This covers

taking the address of functions~(\ref{conv.func}, \ref{expr.unary.op}),

calls to named functions\iref{expr.call},

operator overloading\iref{over},

user-defined conversions\iref{class.conv.fct},

allocation functions for \grammarterm{new-expression}{s}\iref{expr.new}, as well as

non-default initialization\iref{dcl.init}.

A constructor selected to copy or move an object of class type

is considered to be named by an expression or conversion

even if the call is actually elided by the implementation\iref{class.copy.elision}.

\end{note}

A deallocation function for a class

is named by a \grammarterm{new-expression}

if it is the single matching deallocation function

for the allocation function selected by overload resolution,

as specified in~\ref{expr.new}.

A deallocation function for a class

is named by a \grammarterm{delete-expression}

if it is the selected usual deallocation function

as specified in~\ref{expr.delete} and~\ref{class.free}.

\end{itemize}

A variable is named by an expression

if the expression is an \grammarterm{id-expression} that denotes it.

A variable \tcode{x} whose name appears as a

potentially-evaluated expression $E$

is \defnx{odr-used}{odr-use} by $E$ unless

\begin{itemize}

\tcode{x} is a reference that is

usable in constant expressions\iref{expr.const}, or

\tcode{x} is a variable of non-reference type that is

usable in constant expressions and has no mutable subobjects, and

$E$ is an element of the set of potential results of an expression

of non-volatile-qualified non-class type

to which the lvalue-to-rvalue conversion\iref{conv.lval} is applied, or

\tcode{x} is a variable of non-reference type, and

$E$ is an element of the set of potential results

of a discarded-value expression\iref{expr.prop}

to which the lvalue-to-rvalue conversion is not applied.

\end{itemize}

A structured binding is odr-used if it appears as a potentially-evaluated expression.

\tcode{*this} is odr-used if \tcode{this} appears as a potentially-evaluated expression

(including as the result of the implicit transformation in the body of a non-static

member function~(\ref{class.mfct.non-static})).

A virtual member

function is odr-used if it is not pure.

A function is odr-used if it is named by

a potentially-evaluated expression or conversion.

A non-placement allocation or deallocation

function for a class is odr-used by the definition of a constructor of that

class. A non-placement deallocation function for a class is odr-used by the

definition of the destructor of that class, or by being selected by the

lookup at the point of definition of a virtual

destructor\iref{class.dtor}.

\begin{footnote}

An implementation is not required

to call allocation and

deallocation functions from constructors or destructors; however, this

is a permissible implementation technique.

\end{footnote}

An assignment operator function in a class is odr-used by an

implicitly-defined

copy-assignment or move-assignment function for another class as specified

in~\ref{class.copy.assign}.

A constructor for a class is odr-used as specified

in~\ref{dcl.init}. A destructor for a class is odr-used if it is potentially

invoked\iref{class.dtor}.

A local entity\iref{basic.pre}

is \defn{odr-usable} in a scope\iref{basic.scope.scope} if:

\begin{itemize}

\item either the local entity is not \tcode{*this}, or

an enclosing class or non-lambda function parameter scope exists and,

if the innermost such scope is a function parameter scope,

it corresponds to a non-static member function, and

for each intervening scope\iref{basic.scope.scope}

between the point at which the entity is introduced and the scope

(where \tcode{*this} is considered to be introduced

within the innermost enclosing class or non-lambda function definition scope),

either:

\begin{itemize}

\item the intervening scope is a block scope, or

\item the intervening scope is the function parameter scope of a \grammarterm{lambda-expression}

that has a \grammarterm{simple-capture}

naming the entity or has a \grammarterm{capture-default}, and

the block scope of the \grammarterm{lambda-expression}

is also an intervening scope.

\end{itemize}

\end{itemize}

If a local entity is odr-used

in a scope in which it is not odr-usable,

the program is ill-formed.

\begin{example}

\begin{codeblock}

void f(int n) {

[] { n = 1; }; // error: \tcode{n} is not odr-usable due to intervening lambda-expression

struct A {

void f() { n = 2; } // error: \tcode{n} is not odr-usable due to intervening function definition scope

};

void g(int = n); // error: \tcode{n} is not odr-usable due to intervening function parameter scope

[=](int k = n) {}; // error: \tcode{n} is not odr-usable due to being

// outside the block scope of the \grammarterm{lambda-expression}

[&] { [n]{ return n; }; }; // OK

}

\end{codeblock}

\end{example}

Every program shall contain exactly one definition of every non-inline

function or variable that is odr-used in that program

outside of a discarded statement\iref{stmt.if}; no diagnostic required.

The definition can appear explicitly in the program, it can be found in

the standard or a user-defined library, or (when appropriate) it is

implicitly defined (see~\ref{class.default.ctor}, \ref{class.copy.ctor},

\ref{class.dtor}, and \ref{class.copy.assign}).

\begin{example}

\begin{codeblock}

auto f() {

struct A {};

return A{};

}

decltype(f()) g();

auto x = g();

\end{codeblock}

A program containing this translation unit is ill-formed

because \tcode{g} is odr-used but not defined,

and cannot be defined in any other translation unit

because the local class \tcode{A} cannot be named outside this

translation unit.

\end{example}

A \defn{definition domain} is

a \grammarterm{private-module-fragment} or

the portion of a translation unit

excluding its \grammarterm{private-module-fragment} (if any).

A definition of an inline function or variable shall be reachable

from the end of every definition domain

in which it is odr-used outside of a discarded statement.

\indextext{type!incomplete}%

A definition of a class shall be reachable in every context in which

the class is used in a way that requires the class type to be complete.

\begin{example}

The following complete translation unit is well-formed,

even though it never defines \tcode{X}:

\begin{codeblock}

struct X; // declare \tcode{X} as a struct type

struct X* x1; // use \tcode{X} in pointer formation

X* x2; // use \tcode{X} in pointer formation

\end{codeblock}

\end{example}

\begin{note}

The rules for declarations and expressions

describe in which contexts complete class types are required. A class

type \tcode{T} must be complete if:

\begin{itemize}

\item an object of type \tcode{T} is defined\iref{basic.def}, or

\item a non-static class data member of type \tcode{T} is

declared\iref{class.mem}, or

\item \tcode{T} is used as the allocated type or array element type in a

\grammarterm{new-expression}\iref{expr.new}, or

\item an lvalue-to-rvalue conversion is applied to

a glvalue referring

to an object of type \tcode{T}\iref{conv.lval}, or

\item an expression is converted (either implicitly or explicitly) to

type \tcode{T} (\ref{conv}, \ref{expr.type.conv},

\ref{expr.dynamic.cast}, \ref{expr.static.cast}, \ref{expr.cast}), or

\item an expression that is not a null pointer constant, and has type

other than \cv{}~\tcode{void*}, is converted to the type pointer to \tcode{T}

or reference to \tcode{T} using a standard conversion\iref{conv},

a \tcode{dynamic_cast}\iref{expr.dynamic.cast} or

a \tcode{static_cast}\iref{expr.static.cast}, or

\item a class member access operator is applied to an expression of type

\tcode{T}\iref{expr.ref}, or

\item the \tcode{typeid} operator\iref{expr.typeid} or the

\tcode{sizeof} operator\iref{expr.sizeof} is applied to an operand of

type \tcode{T}, or

\item a function with a return type or argument type of type \tcode{T}

is defined\iref{basic.def} or called\iref{expr.call}, or

\item a class with a base class of type \tcode{T} is

defined\iref{class.derived}, or

\item an lvalue of type \tcode{T} is assigned to\iref{expr.ass}, or

\item the type \tcode{T} is the subject of an

\tcode{alignof} expression\iref{expr.alignof}, or

\item an \grammarterm{exception-declaration} has type \tcode{T}, reference to

\tcode{T}, or pointer to \tcode{T}\iref{except.handle}.

\end{itemize}

\end{note}

There can be more than one definition of a

\begin{itemize}

\item class type\iref{class},

\item enumeration type\iref{dcl.enum},

\item inline function or variable\iref{dcl.inline},

\item templated entity\iref{temp.pre},

\item default argument for a parameter (for a function in a given scope)%

\iref{dcl.fct.default}, or

\item default template argument\iref{temp.param}

\end{itemize}

in a program provided that

each definition appears in a different translation unit and

the definitions satisfy the following requirements.

Given such an entity \tcode{D} defined in more than one translation unit,

for all definitions of \tcode{D}, or,

if \tcode{D} is an unnamed enumeration,

for all definitions of \tcode{D} that are reachable at any given program point,

the following requirements shall be satisfied.

\begin{itemize}

\item Each such definition

shall not be attached to a named module\iref{module.unit}.

\item Each such definition shall consist of

the same sequence of tokens,

where the definition of a closure type

is considered to consist of the sequence of tokens of

the corresponding \grammarterm{lambda-expression}.

\item In each such definition, corresponding names, looked up

according to~\ref{basic.lookup}, shall refer to the same entity, after

overload resolution\iref{over.match} and after matching of partial

template specialization\iref{temp.over}, except that a name can refer to

\begin{itemize}

a non-volatile const object with internal or no linkage if the object

\begin{itemize}

\item has the same literal type in all definitions of \tcode{D},

\item is initialized with a constant expression\iref{expr.const},

\item is not odr-used in any definition of \tcode{D}, and

\item has the same value in all definitions of \tcode{D},

\end{itemize}

or

a reference with internal or no linkage

initialized with a constant expression such that

the reference refers to the same entity in all definitions of \tcode{D}.

\end{itemize}

\item In each such definition, except within

the default arguments and default template arguments of \tcode{D},

corresponding \grammarterm{lambda-expression}{s} shall have

the same closure type (see below).

\item In each such definition, corresponding entities shall have the

same language linkage.

\item In each such definition, the overloaded operators referred

to, the implicit calls to conversion functions, constructors, operator

new functions and operator delete functions, shall refer to the same

function.

\item In each such definition,

a default argument used by an (implicit or explicit) function call or

a default template argument used by an (implicit or explicit)

\grammarterm{template-id} or \grammarterm{simple-template-id}

is treated as if its token sequence

were present in the definition of \tcode{D};

that is, the default argument or default template argument

is subject to the requirements described in this paragraph (recursively).

\item If \tcode{D} is a class with an implicitly-declared

constructor (\ref{class.default.ctor}, \ref{class.copy.ctor}),

it is as if the constructor was

implicitly defined in every translation unit where it is odr-used, and the

implicit definition in every translation unit shall call the same

constructor for a subobject of \tcode{D}.

\begin{example}

\begin{codeblock}

// translation unit 1:

struct X {

X(int, int);

X(int, int, int);

};

X::X(int, int = 0) { }

class D {

X x = 0;

};

D d1; // \tcode{X(int, int)} called by \tcode{D()}

// translation unit 2:

struct X {

X(int, int);

X(int, int, int);

};

X::X(int, int = 0, int = 0) { }

class D {

X x = 0;

};

D d2; // \tcode{X(int, int, int)} called by \tcode{D()};

// \tcode{D()}'s implicit definition violates the ODR

\end{codeblock}

\end{example}

\item If \tcode{D} is a class with

a defaulted three-way comparison operator function\iref{class.spaceship},

it is as if the operator was

implicitly defined in every translation unit where it is odr-used, and the

implicit definition in every translation unit shall call the same

comparison operators for each subobject of \tcode{D}.

\end{itemize}

If \tcode{D} is a template and is defined in more than one

translation unit, then the preceding requirements

shall apply both to names from the template's enclosing scope used in the

template definition, and also to dependent names at

the point of instantiation\iref{temp.dep}.

These requirements also apply to corresponding entities

defined within each definition of \tcode{D}

(including the closure types of \grammarterm{lambda-expression}{s},

but excluding entities defined within default arguments or

default template arguments of either \tcode{D} or

an entity not defined within \tcode{D}).

For each such entity and for \tcode{D} itself,

the behavior is as if there is a single entity with a single definition,

including in the application of these requirements to other entities.

\begin{note}

The entity is still declared in multiple translation units, and \ref{basic.link}

still applies to these declarations. In particular,

\grammarterm{lambda-expression}{s}\iref{expr.prim.lambda}

appearing in the type of \tcode{D} can result

in the different declarations having distinct types, and

\grammarterm{lambda-expression}{s} appearing in a default argument of \tcode{D}

might still denote different types in different translation units.

\end{note}

If these definitions do not satisfy these requirements,

then the program is ill-formed;

a diagnostic is required only if

the entity is attached to a named module and

a prior definition is reachable at the point where a later definition occurs.

\begin{example}

\begin{codeblock}

inline void f(bool cond, void (*p)()) {

if (cond) f(false, []{});

}

inline void g(bool cond, void (*p)() = []{}) {

if (cond) g(false);

}

struct X {

void h(bool cond, void (*p)() = []{}) {

if (cond) h(false);

}

};

\end{codeblock}

If the definition of \tcode{f} appears in multiple translation units,

the behavior of the program is as if

there is only one definition of \tcode{f}.

If the definition of \tcode{g} appears in multiple translation units,

the program is ill-formed (no diagnostic required) because

each such definition uses a default argument that

refers to a distinct \grammarterm{lambda-expression} closure type.

The definition of \tcode{X} can appear

in multiple translation units of a valid program;

the \grammarterm{lambda-expression}{s} defined within

the default argument of \tcode{X::h} within the definition of \tcode{X}

denote the same closure type in each translation unit.

\end{example}

If, at any point in the program,

there is more than one

reachable unnamed enumeration definition in the same scope

that have the same first enumerator name and

do not have typedef names for linkage purposes\iref{dcl.enum},

those unnamed enumeration types shall be the same; no diagnostic required.

\indextext{one-definition rule|)}

\rSec1[basic.scope]{Scope}%

\indextext{scope|(}

\rSec2[basic.scope.scope]{General}

The declarations in a program appear in a number of \defnx{scopes}{scope}

that are in general discontiguous.

The \defnadj{global}{scope} contains the entire program;

every other scope $S$ is introduced by a

declaration,

\grammarterm{parameter-declaration-clause},

\grammarterm{statement}, or \grammarterm{handler}

(as described in the following subclauses of \ref{basic.scope})

appearing in another scope which thereby contains $S$.

An \defnadj{enclosing}{scope} at a program point is any scope that contains it;

the smallest such scope is said to be the \defnadj{immediate}{scope}

at that point.

A scope \defnx{intervenes}{scope!intervene}

between a program point $P$ and a scope $S$

(that does not contain $P$) if it is or contains $S$ but does not contain $P$.

Unless otherwise specified:

\begin{itemize}

The smallest scope that contains a scope $S$ is

the \defnadj{parent}{scope} of $S$.

No two declarations (re)introduce the same entity.

A declaration \defnx{inhabits}{scope!inhabit}

the immediate scope at its locus\iref{basic.scope.pdecl}.

A declaration's \defnadj{target}{scope} is the scope it inhabits.

Any names (re)introduced by a declaration are \defnx{bound}{name!bound} to it

in its target scope.

\end{itemize}

An entity \defnx{belongs}{entity!belong} to a scope $S$

if $S$ is the target scope of a declaration of the entity.

\begin{note}

Special cases include that:

\begin{itemize}

Template parameter scopes are parents

only to other template parameter scopes\iref{basic.scope.temp}.

Corresponding declarations with appropriate linkage

declare the same entity\iref{basic.link}.

The declaration in a \grammarterm{template-declaration}

inhabits the same scope as the \grammarterm{template-declaration}.

Friend declarations and

declarations of qualified names and

template specializations do not bind names\iref{dcl.meaning};

those with qualified names target a specified scope, and

other friend declarations and

certain \grammarterm{elaborated-type-specifier}s\iref{dcl.type.elab}

target a larger enclosing scope.

Block-scope extern declarations target a larger enclosing scope

but bind a name in their immediate scope.

The names of unscoped enumerators are bound

in the two innermost enclosing scopes\iref{dcl.enum}.

A class's name is also bound in its own scope\iref{class.pre}.

The names of the members of an anonymous union are bound in

the union's parent scope\iref{class.union.anon}.

\end{itemize}

\end{note}

Two declarations \defn{correspond}

if they (re)introduce the same name,

both declare constructors, or

both declare destructors,

unless

\begin{itemize}

either is a \grammarterm{using-declarator}, or

one declares a type (not a \grammarterm{typedef-name}) and the other declares a

variable,

non-static data member other than of an anonymous union\iref{class.union.anon},

enumerator,

function, or

function template, or

each declares a function or function template, except when

\begin{itemize}

both declare functions with the same parameter-type-list,

\begin{footnote}

An implicit object parameter\iref{over.match.funcs}

is not part of the parameter-type-list.

\end{footnote}

equivalent\iref{temp.over.link} trailing \grammarterm{requires-clause}s

(if any, except as specified in \ref{temp.friend}), and,

if both are non-static members,

the same \grammarterm{cv-qualifier}s (if any) and

\grammarterm{ref-qualifier} (if both have one), or

both declare function templates with equivalent

parameter-type-lists,

return types (if any),

\grammarterm{template-head}s, and

trailing \grammarterm{requires-clause}s (if any), and,

if both are non-static members,

the same \grammarterm{cv-qualifier}s (if any) and

\grammarterm{ref-qualifier} (if both have one).

\end{itemize}

\end{itemize}

\begin{note}

Declarations can correspond even if neither binds a name.

\begin{example}

\begin{codeblock}

struct A {

friend void f(); // \#1

};

struct B {

friend void f() {} // corresponds to, and defines, \#1

};

\end{codeblock}

\end{example}

\end{note}

\begin{example}

\begin{codeblock}

typedef int Int;

enum E : int { a };

void f(int); // \#1

void f(Int) {} // defines \#1

void f(E) {} // OK: another overload

struct X {

static void f();

void f() const; // error: redeclaration

void g();

void g() const; // OK

void g() &; // error: redeclaration

};

\end{codeblock}

\end{example}

\indextext{declaration!potentially conflict}%

Two declarations \defn{potentially conflict}

if they correspond and

cause their shared name to denote different entities\iref{basic.link}.

The program is ill-formed

if, in any scope, a name is bound to two declarations

that potentially conflict and one precedes the other\iref{basic.lookup}.

\begin{note}

Overload resolution can consider potentially conflicting declarations

found in multiple scopes

(e.g. via \grammarterm{using-directive}s or for operator functions),

in which case it is often ambiguous.

\end{note}

\begin{example}

\begin{codeblock}

void f() {

int x,y;

void x(); // error: different entity for \tcode{x}

int y; // error: redefinition

}

enum { f }; // error: different entity for \tcode{::f}

namespace A {}

namespace B = A;

namespace B = A; // OK: no effect

namespace B = B; // OK: no effect

namespace A = B; // OK: no effect

namespace B {} // error: different entity for \tcode{B}

\end{codeblock}

\end{example}

\indextext{declaration!nominable}%

A declaration is \defn{nominable}

in a class, class template, or namespace $E$ at a point $P$ if

it precedes $P$,

it does not inhabit a block scope, and

its target scope is the scope associated with $E$ or,

if $E$ is a namespace,

any element of the inline namespace set of $E$\iref{namespace.def}.

\begin{example}

\begin{codeblock}

namespace A {

void f() {void g();}

inline namespace B {

struct S {

friend void h();

static int i;

};

}

}

\end{codeblock}

At the end of this example,

the declarations of \tcode{f}, \tcode{B}, \tcode{S}, and \tcode{h}

are nominable in \tcode{A}, but those of \tcode{g} and \tcode{i} are not.

\end{example}

When instantiating a templated entity\iref{temp.pre},

any scope $S$ introduced by any part of the template definition is considered

to be introduced by the instantiated entity and