ISO/IEC TS 21544:2018
(Main)Programming languages — Extensions to C++ for modules
Programming languages — Extensions to C++ for modules
This document describes extensions to the C++ Programming Language (Clause 2) that introduce modules, a functionality for designating a set of translation units by symbolic name and ability to express symbolic dependency on modules, and to define interfaces of modules. These extensions include new syntactic forms and modifications to existing language semantics. ISO/IEC 14882 provides important context and specification for this document. This document is written as a set of changes against that specification. Instructions to modify or add paragraphs are written as explicit instructions. Modifications made directly to existing text from ISO/IEC 14882 use underlining to represent added text and strikethrough to represent deleted text.
Langages de programmation — Extensions C++ pour les modules
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/IEC TS
SPECIFICATION 21544
First edition
2018-05
Programming languages — Extensions
to C++ for modules
Langages de programmation — Extensions C++ pour les modules
Reference number
ISO/IEC TS 21544:2018(E)
©
ISO/IEC 2018
---------------------- Page: 1 ----------------------
ISO/IEC TS 21544:2018(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2018, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2018 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TS 21544:2018
Contents
Foreword iv
1 Scope 1
2 Normative references 2
3 Terms and definitions 3
4 General 4
4.1 Implementation compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5 Lexical conventions 5
5.1 Separate translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2 Phases of translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.11 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 Basic concepts 8
6.1 Declarations and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 One-definition rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.4 Name lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.5 Program and linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.6 Start and termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10 Declarations 13
10.1 Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.3 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.7 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12 Classes 24
12.2 Class members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
16 Overloading 25
16.5 Overloaded operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
17 Templates 26
17.6 Name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
c
Contents �ISO/IEC 2018 — All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TS 21544:2018
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are described in
the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the
ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and ex-
pressions related to conformity assessment, as well as information about ISO’s adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following URL:
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee
SC 22, Programming languages, their environments and system software interfaces.
c
�ISO/IEC 2018 — All rights reserved iv
---------------------- Page: 4 ----------------------
ISO/IEC TS 21544:2018
1 Scope [intro.scope]
1
++
This document describes extensions to the C Programming Language (Clause 2) that introduce modules,
a functionality for designating a set of translation units by symbolic name and ability to express symbolic
dependency on modules, and to define interfaces of modules. These extensions include new syntactic forms
and modifications to existing language semantics.
2
ISO/IEC 14882 provides important context and specification for this document. This document is written as
a set of changes against that specification. Instructions to modify or add paragraphs are written as explicit
instructions. Modifications made directly to existing text from ISO/IEC 14882 use underlining to represent
added text and strikethrough to represent deleted text.
c
Scope �ISO/IEC 2018 — All rights reserved 1
---------------------- Page: 5 ----------------------
ISO/IEC TS 21544:2018
2 Normative references [intro.refs]
1
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
(1.1) ++
— ISO/IEC 14882:2017, Programming Languages – C
++
ISO/IEC 14882:2017 is hereafter called the C Standard. The numbering of clauses, subclauses, and
++
paragraphs in this document reflects the numbering in the C Standard. References to clauses and
++
subclauses not appearing in this document refer to the original, unmodified text in the C Standard.
c
Normative references �ISO/IEC 2018 — All rights reserved 2
---------------------- Page: 6 ----------------------
ISO/IEC TS 21544:2018
3 Terms and definitions [intro.defs]
No terms and definitions are listed in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org
c
Terms and definitions �ISO/IEC 2018 — All rights reserved 3
---------------------- Page: 7 ----------------------
ISO/IEC TS 21544:2018
4 General [intro]
4.1 Implementation compliance [intro.compliance]
1
Conformance requirements for this document are those defined in ISO 14882:2017, 4.1 except that references
to the C++ Standard therein shall be taken as referring to the document that is the result of applying the
editing instructions. Similarly, all references to the C++ Standard in the resulting document shall be taken
as referring to the resulting document itself. [Note: Conformance is defined in terms of the behavior of
programs. —end note]
4.2 Acknowledgments [intro.ack]
1
This document is based, in part, on the design and implementation described in the paper P0142R0 “A
Module System for C++”.
c
§ 4.2 �ISO/IEC 2018 — All rights reserved 4
---------------------- Page: 8 ----------------------
ISO/IEC TS 21544:2018
5 Lexical conventions [lex]
5.1 Separate translation [lex.separate]
Modify paragraph 5.1/2 as follows
2 [ Note: Previously translated translation units and instantiation units can be preserved individ-
ually or in libraries. The separate translation units of a program communicate (6.5) by (for
example) calls to functions whose identifiers have external or module linkage, manipulation of
objects whose identifiers have external or module linkage, or manipulation of data files. Transla-
tion units can be separately translated and then later linked to produce an executable program
(6.5). — end note ]
5.2 Phases of translation [lex.phases]
Modify bullet 7 of paragraph 5.2/1 as follows:
7. White-space characters separating tokens are no longer significant. Each preprocessing
token is converted into a token (5.6). The resulting tokens are syntactically and semanti-
cally analyzed and translated as a translation unit. [ Note: The process of analyzing and
translating the tokens may occasionally result in one token being replaced by a sequence
of other tokens (17.2). — end note ] It is implementation-defined whether the source for
module interface units for modules on which the current translation unit has an interface
dependency (10.7.3) is required to be available. [ Note: Source files, translation units and
translated translation units need not necessarily be stored as files, nor need there be any
one-to-one correspondence between these entities and any external representation. The
description is conceptual only, and does not specify any particular implementation. — end
note ]
Add new paragraphs as follows:
2 The result of processing a translation unit from phases 1 through 7 is a directed graph called
the abstract semantics graph of the translation unit:
— Each vertex, called a declset, is a citation (10.7.3), or a collection of non-local declarations
and redeclarations (Clause 10) declaring the same entity or other non-local declarations of
the same name that do not declare an entity.
— A directed edge (D ,D ) exists in the graph if and only if the declarations contained inD
1 2 2
declare an entity mentioned in a declaration contained inD .
1
The abstract semantics graph of a module is the subgraph of the abstract semantics graph of its
module interface unit generated by the declsets the declarations of which are in the purview of
that module interface unit. [ Note: The abstract semantics graphs of modules, as appropriately
restricted (10.7.6), are used in the processing of module-import-declarations (10.7.3) and module
implementation units. — end note ]
3 An entity is mentioned in a declaration D if that entity is a member of the basis of D, a set of
entities determined as follows:
— IfD is a namespace-definition, the basis is the union of the bases of the declarations in its
namespace-body.
— IfD is a nodeclspec-function-declaration,
— if D declares a contructor, the basis is the union of the type-bases of the parameter
types
c
§ 5.2 �ISO/IEC 2018 — All rights reserved 5
---------------------- Page: 9 ----------------------
ISO/IEC TS 21544:2018
— ifD declares a conversion function, the basis is the type-basis of the return type
— otherwise, the basis is empty.
— IfD is a function-definition, the basis is the type-basis of the function’s type
— IfD is a simple-declaration
— ifD declares a typedef-name, the basis is the type-basis of the aliased type
— ifD declares a variable, the basis is the type-basis of the type of that variable
— ifD declares a function, the basis is the type-basis of the type of that function
— if D defines a class type, the basis is the union of the type-bases of its direct base
classes (if any), and the bases of its member-declarations.
— otherwise, the basis is the empty set.
— IfD is a template-declaration, the basis is the union of the basis of its declaration, the set
consisting of the entities (if any) designated by the default template template arguments,
the default non-type template arguments, the type-bases of the default type template ar-
guments. Furthermore, if D declares a partial specialization, the basis also includes the
primary template.
— If D is an explicit-instantiation or an explicit-specialization, the basis includes the primary
template, and all the entities in the basis of the declaration ofD.
— If D is a linkage-specification, the basis is the union of all the bases of the declarations
contained inD.
— IfD is a namespace-alias-definition, the basis is the singleton consisting of the namespace
denoted by the qualified-namespace-specifier.
— IfD is a using-declaration, the basis is the union of the bases of all the declarations intro-
duced by the using-declarator.
— IfD is a using-directive, the basis is the singleton consisting of the norminated namespace.
— IfD is an alias-declaration, the basis is the type-basis of its defining-type-id.
— Otherwise, the basis is empty.
The type-basis of a typeT is
— IfT is a fundamental type, the type-basis is the empty set.
— IfT is a cv-qualified type, the type-basis is the type-basis of the unqualified type.
— If T is a member of an unknown specialization, the type-basis is the type-basis of that
specialization.
— If T is a class template specialization, the type-basis is the union of the set consisting of
the primary template and the template template arguments (if any) and the non-dependent
non-type template arguments (if any), and the type-bases of the type template arguments
(if any).
— IfT is a class type or an enumeration type, the type-basis is the singleton{T}.
— IfT is a reference toU, or a pointer toU, or an array ofU, the type-basis is the type-basis
ofU.
— IfT is a function type, the type-basis is the union of the type-basis of the return type and
the type-bases of the parameter types.
— IfT is a pointer to data member of a classX, the type-basis is the union of the type-basis
ofX and the type-basis of member type.
— If T is a pointer to member function type of a class X, the type-basis is the union of the
type-basis ofX and the type-basis of the function type.
— Otherwise, the type-basis is the empty set.
4 [ Note: The basis of a declaration includes neither non-fully evaluated expressions nor entities
used in those expressions. [ Example:
c
§ 5.2 �ISO/IEC 2018 — All rights reserved 6
---------------------- Page: 10 ----------------------
ISO/IEC TS 21544:2018
const int size = 2;
int ary1[size]; // size not in ary1’s basis
constexpr int identity(int x) { return x; }
int ary2[identity(2)]; // identity not in ary2’s basis
template struct S;
template struct S2;
constexpr int g(int);
template
S> f(); // f’s basis:{S,S2}
— end example ] — end note ]
5.11 Keywords [lex.key]
In 5.11, add these two keywords to Table 5 in paragraph 5.11/1: module and import.
Modify note in paragraph 5.11/1 as follows:
1 .
[ Note: Theexport andregister keywords are is unused but are is reserved for future use. — end
note ]
c
§ 5.11 �ISO/IEC 2018 — All rights reserved 7
---------------------- Page: 11 ----------------------
ISO/IEC TS 21544:2018
6 Basic concepts [basic]
Modify paragraph 6/3 as follows:
3 An entity is a value, object, reference, function, enumerator, type, class member, bit-field, tem-
plate, template specialization, namespace, module, or parameter pack.
Modify paragraph 6/4 as follows:
4 A name is a use of an identifier (5.10), operator-function-id (16.5), literal-operator-id (16.5.8),
conversion-function-id (15.3.2), or template-id (17.2), or module-name (10.7) that denotes an
entity or label (9.6.4, 9.1).
Add a sixth bullet to paragraph 6/8 as follows:
– they are module-names composed of the same dotted sequence of identifiers.
6.1 Declarations and definitions [basic.def]
Modify paragraph 6.1/1 as follows:
1 A declaration (Clause 10) may introduce one or more names into a translation unit or redeclare
names introduced by previous declarations. If so, the declaration specifies the interpretation
and attributessemantic properties of these names. [.]
Append the following two bullets to paragraph 6.1/2:
2 A declaration is a definition unless
— .
— it is an explicit specialization (17.7.3) whose declaration is not definition.,
— it is a module-import-declaration,
— it is a proclaimed-ownership-declaration.
[ Example:
import std.io; // make names from std.io available
export module M; // toplevel declaration for M
export struct Point { // define and export Point
int x;
int y;
};
— end example ]
6.2 One-definition rule [basic.def.odr]
Replace paragraph 6.2/1 with:
1 A variable, function, class type, enumeration type, or template shall not be defined where a prior
definition is reachable (6.4).
Modify opening of paragraph 6.2/6 as follows
c
§ 6.2 �ISO/IEC 2018 — All rights reserved 8
---------------------- Page: 12 ----------------------
ISO/IEC TS 21544:2018
6 There can be more than one definition of a class type (Clause 12), enumeration type (10.2), in-
line function with external or module linkage (10.1.6), inline variable with external or module
linkage (10.1.6), class template (Clause 17), non-static function template (17.5.6), static data
member of a class template (17.5.1.3), member function of a class template (17.5.1.1), or tem-
plate specialization for which some template parameters are not specified (17.7, 17.5.5) in a
program provided that each definition appears in a different translation unit no prior definition
is reachable (6.4) at the point where a definition appears, and provided the definitions satisfy
the following requirements. For an entity with an exported declaration, there shall be only one
definition of that entity; a diagnostic is required only if the abstract semantics graph of the
module contains a definition of the entity. [ Note: If the definition is not in the interface unit,
then at most one module unit can have and make use of the definition. — end note ] Given
such an entity named D defined in more than one translation unit, then
6.3 Scope [basic.scope]
6.3.2 Point of declaration [basic.scope.pdecl]
Add a new paragraph 6.3.2/13 as follows:
13 The point of declaration of a module is immediately after the module-name in a module-declaration.
6.3.6 Namespace scope [basic.scope.namespace]
From end-user perspective, there are really no new lookup rules to learn. The “old” rules are the “new” rules,
with appropriate adjustment in the definition of “associated entities.”
Modify paragraph 6.3.6/1 as follows:
1 The declarative region of a namespace-definition is its namespace-body. Entities declared in a
namespace-body are said to be members of the namespace, and names introduced by these
declarations into the declarative region of the namespace are said to be member names of the
namespace. A namespace member name has namespace scope. Its potential scope includes its
namespace from the name’s point of declaration (6.3.2) onwards; and for each using-directive
(10.3.4) that nominates the member’s namespace, the member’s potential scope includes that
portion of the potential scope of the using-directive that follows the member’s point of declaration.
If a name X (not having internal linkage) is declared in a namespace N in the purview of the
module interface unit of a module M, the potential scope of X includes the portion of the
namespace N in the purview of every module implementation unit of M and, if the name X is
exported, in every translation unit that importsM after a module-import-declaration nominating
M. [ Example:
// Translation unit #1
export module M;
export int sq(int i) { return i*i; }
// Translation unit #2
import M;
int main() { return sq(9); } // OK: ’sq’ from module M
— end example ]
6.4 Name lookup [basic.lookup]
Modify paragraph 6.4/1 as follows:
1 The name lookup rules apply uniformly to all names (including typedef-names (10.1.3), namespace-
names (10.3), and class-names (12.1)) wherever the grammar allows such names in the context
c
§ 6.4 �ISO/IEC 2018 — All rights reserved 9
---------------------- Page: 13 ----------------------
ISO/IEC TS 21544:2018
discussed by a particular rule. Name lookup associates the use of a name with a set of decla-
rations (6.1) or citations (10.7.3) of that name. For all intent and purposes of further semantic
processing requiring declarations, a citation is replaced with the declarations contained in its
declset. [.] Only after name lookup, function overload resolution (if applicable) and access
checking have succeeded are the attributessemantic properties introduced by the name’s decla-
ration used further in the expression processing (Clause 8).
Add new paragraph 6.4/5 as follows:
5 A declaration is reachable from a program point if it can be found by unqualified name lookup
in its scope.
6.4.2 Argument-dependent name lookup [basic.lookup.argdep]
Modify paragraph 6.4.2/2 as follows:
2 For each argument type T in the function call, there is a set of zero or more associated name-
spaces (10.3) and a set of zero or more associated classes entities (other than namespaces) to
be considered. The sets of namespaces and classes entities are determined entirely by the types
of the function arguments (and the namespace of any template template argument). Typedef
names and using-declarations used to specify the types do not contribute to this set. The sets
of namespaces and classes entities are determined in the following way:
— If T is a fundamental type, its associated sets of namespaces and classes entities are both
empty.
— If T is a class type (including unions), its associated classes entities are the class itself;
the class of which it is a member, if any; and its direct and indirect base classes. Its
associated namespaces are the innermost enclosing namespaces of its associated classes
entities. Furthermore, if T is a class template specialization, its associated namespaces
and classes entities also include: the namespace and classes entities associated with the
types of the template arguments provided for template type parameters (excluding template
template arguments); the templates used as template template arguments; the namespaces
of which any template template arguments are members; and the classes of which any
member template used as template template arguments are members. [ Note: Non-type
template arguments do not contribute to the set of associated namespaces. — end note ]
— If T is an enumeration type, its associated namespace is the innermost enclosing name-
space of its declaration, and its associated entities are T, and, if. If it is a class member, its
associated class is the member’s class; else it has no associated class.
— If T is a pointer to U or an array of U, its associated namespaces and classes entities are
those associated with U.
— If T is a function type, its associated namespaces and classes entities are those associated
with the function parameter types and those associated with the return type.
— If T is a pointer to a data member of class X, its associated namespaces and classes entities
are those associated with the member type together with those associated with X.
If an associated namespace is an inline namespace (10.3.1), its enclosing namespace is also
included in the set. If an associated namespace directly contains inline namespaces, those
inline namespaces are also included in the set. In addition, if the argument is the name or ad-
dress of a set of overloaded functions and/or function templates, its associated classes entities
and namespaces are the union of those associated with each of the members of the set, i.e.,
the classes entities and namespaces associated with its parameter types and return type. Ad-
ditionally, if the aforementioned set of overloaded functions is named with a template-id, its
associated classes entities and namespaces also include those of its type template-arguments
and its template template-arguments.
Modify paragraph 6.4.2/4 as follows:
c
§ 6.4.2 �ISO/IEC 2018 — All rights reserved 10
---------------------- Page: 14 ----------------------
ISO/IEC TS 21544:2018
4 When considering an associated namespace, the lookup is the same as the lookup performed
when the associated namespace is used as a qualifier (6.4.3.2) except that:
— Any using-directives in the associated namespace are ignored.
— Any namespace-scope friend declaration functions or friend function templates declared
in associated classes in the set of associated entities are visible within their respective
namespaces even if they are not visible during an ordinary lookup (14.3).
— All names except those of (possibly overloaded) functions and function templates are ig-
nored.
— In resolving dependent names (17.6.4), any function or function template that is owned by
a named module M (10.7), that is declared in the module interface unit of M, and that has
the same innermost enclosing non-inline namespace as some entity owned by M in the set
of associated entities, is visible within its namespace even if it is not exported.
6.5 Program and linkage [basic.link]
Change the definition of translation-unit in paragraph 6.5/1 to:
translation-unit
toplevel-declaration-seq
opt
toplevel-declaration-seq
toplevel-declaration
toplevel-declaration-seq toplevel-declaration
toplevel-declaration
module-declaration
declaration
Insert a new bullet between first and second bullet of paragraph 6.5/2:
— When a name has module linkage, the entity it denotes can be referred to by names from
other scopes of the same module unit (10.7.1) or from scopes of other module units of that
same module.
Modify bullet (3.2) of paragraph 6.5/3 as follows:
— a non-inline non-exported variable of non-volatile const-qualified type that is neither ex-
plicitly declared extern nor previously declared to have external or module linkage; or
Modify paragraph 6.5/4 as follows:
4 An unnamed namespace or a namespace declared directly or indirectly within an unnamed
namespace has internal linkage. All other namespaces have external linkage. A name having
namespace scope that has not been given internal linkage above has the same linkage as the
enclosing namespace if itand that is the name of
— a variable; or
— a function; or
— a named class (Clause 12), or an unnamed class defined in a typedef declaration in which
the class has the typedef name for linkage purposes (10.1.3); or
— a named enumeration (10.2), or an unnamed enumeration defined in a typedef declaration
in which the enumeration has the typedef name for linkage purposes (10.1.3); or
— a template.
has the same linkage as the enclosing namespace if
— said namespace has internal linkage, or
c
§ 6.5 �ISO/IEC 2018 — All rights reserved 11
---------------------- Page: 15 ----------------------
ISO/IEC TS 21544:2018
— the name is exported (10.7.2), or is declared in a proclaimed-ownership-declaration, or is
not being declared in the purview of a named module (10.7.1);
otherwise, the name has module linkage.
Modify 6.5/6 as follows:
6 The name of a function declared in block scope and the name of a variable declared by a block
scope extern declaration have linkage. If there is a visible declaration of an entity with link-
age having the same name and type, ignoring entities declared outside the innermost enclosing
namespace scope, the block scope declaration declares that same entity and receives the link-
age of the previous declaration. If that entity was exported by an imported module or if the
containing block scope is in the purview of a named module, the program is ill-formed. If there
is more than one such matching entity, the program is ill-formed. Otherwise, if no matching
entity is found, the block scope entity receives external linkage.
Modify paragrapgh 6.5/9 as follows:
9 Two names that are the same (Clause 9) and that are declared in different scopes shall denote
the same variable, function, type, template or namespace if
— both names have external or module linkage and are declared in declarations attached to
1
the same module , or else both names have internal linkage and are declared in the same
translation unit; and
— both names refer to members of the same namespace or to members, not by inheritance,
of the same class; and
— when both names denote functions, the parameter-typelists of the functions (11.3.5) are
identical; and
— when both names denote function templates, the signatures (17.5.6.1) ar the same.
If two declarations declaring entities (other than namespaces) and attached to different modules
introduce two names that are the same and that both have external linkage, the program is
ill-formed; no diagnostic required. [ Note: using-declarations, typedef declarations, and alias-declarations
do not declare entities, but merely introduce synonyms. Similarly, using-directives do not
declare entities, either. — end note ]
6.6 Start and termination [basic.start]
6.6.1 main function [basic.start.main]
Modify paragraph 6.6.1/1 as follows:
1 A program shall contain a global function called main declared in the purview of the global
module.
1) This provision supports implementations where exported entities in different modules have different implementation symbols.
Conversely, for other implementations, exported entities have the same implementation symbols regardless of in which module
they are declared. Such implementations are supported for the time being by disallowing all situations where the same names
with external linkage might appear from different modules.
c
§ 6.6.1 �ISO/IEC 2018 — All rights reserved 12
---------------------- Page: 16 ----------------------
ISO/IEC TS 21544:2018
1
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.