ISO/IEC TS 19217:2015

Information technology — Programming languages — C++ Extensions for concepts

ISO/IEC TS 19217:2015 describes extensions to the C++ Programming Language (1.2) that enable the specification and checking of constraints on template arguments, and the ability to overload functions and specialize class templates based on those constraints. These extensions include new syntactic forms and modifications to existing language semantics. The International Standard, ISO/IEC 14882, provides important context and specification for this Technical Specification. 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 the International Standard use underlining to represent added text and strikethrough to represent deleted text. WG21 paper N4191 defines "fold expressions", which are used to define constraint expressions resulting from the use of constrained-parameters that declare template parameter packs. This feature is not present in ISO/IEC 14882:2014, but it is planned to be included in the next revision of that International Standard. The specification of that feature is included in this document.

Technologie de l'information — Langages de programmation — Extensions C++ pour les concepts warning

General Information

• Status: Withdrawn
• Publication Date: 12-Nov-2015
• ICS: 35.060 - Languages used in information technology
• Technical Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Drafting Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 07-Sep-2022

Standards Content (Sample)

TECHNICAL ISO/IEC TS
SPECIFICATION 19217
First edition
2015-11-15
Information technology —
Programming languages — C++
Extensions for concepts
Technologie de l'information — Langages de programmation —
Extensions C++ pour les concepts warning
Reference number
ISO/IEC TS 19217:2015(E)
©
ISO/IEC 2015

---------------------- Page: 1 ----------------------
ISO/IEC TS 19217:2015(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2015, 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. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
Contents
iii
Contents
iv
List of Tables
v
Foreword
1 General
1
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Terms and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Implementation compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Feature-testing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Lexical conventions 3
2.1 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5 Expressions 4
5.1 Primary expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7 Declarations 11
7.1 Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8 Declarators 21
8.3 Meaning of declarators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10 Derived classes 25
10.3 Virtual functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13 Overloading 26
13.1 Overloadable declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.3 Overload resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.4 Address of overloaded function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14 Templates 28
14.1 Template parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.2 Introduction of template parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.3 Names of template specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.4 Template arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.6 Template declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.7 Name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.8 Template instantiation and specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.9 Function template specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
14.10 Template constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A Compatibility 53
++ ++
A.1 C extensions for Concepts and ISO C 2014 . . . . . . . . . . . . . . . . . . . . . . . 53
Contents iii
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 3 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
List of Tables
A Feature-test macro(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
10 simple-type-specifiers and the types they specify . . . . . . . . . . . . . . . . . . . . . . . . . . 12
B Value of folding empty sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
List of Tables iv
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC TS 19217:2015 (E)
© ISO/IEC
N4549
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 meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO's adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 22,
Programming languages, their environments and system software interfaces.
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 5 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
1 General [intro]
1.1 Scope [intro.scope]
1
++
This Technical Specification describes extensions to the C Programming Language (1.2) that enable the
specification and checking of constraints on template arguments, and the ability to overload functions and
specialize class templates based on those constraints. These extensions include new syntactic forms and
modifications to existing language semantics.
2
The International Standard, ISO/IEC 14882, provides important context and specification for this Technical
Specification. 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 the
International Standard use underlining to represent added text and strikethrough to represent deleted text.
3
WG21 paper N4191 defines “fold expressions”, which are used to define constraint expressions resulting
from the use of constrained-parameters that declare template parameter packs. This feature is not present
in ISO/IEC 14882:2014, but it is planned to be included in the next revision of that International Standard.
The specification of that feature is included in this document.
1.2 Normative references [intro.refs]
1
The following referenced document is indispensable for the application of this document. For dated refer-
ences, only the edition cited applies. For undated references, the latest edition of the referenced document
(including any amendments) applies.
(1.1)
++
— ISO/IEC 14882:2014, Programming Languages – C
++
ISO/IEC 14882:2014 is hereafter called the C Standard. The numbering of Clauses, sections, and para-
++
graphs in this document reflects the numbering in the C Standard. References to Clauses and sections
++
not appearing in this Technical Specification refer to the original, unmodified text in the C Standard.
1.3 Terms and definitions [intro.defs]
Modify the definitions of “signature” to include associated constraints (14.10.2). This allows different trans-
lation units to contain definitions of functions with the same signature, excluding associated constraints,
without violating the one definition rule (3.2). That is, without incorporating the constraints in the signa-
ture, such functions would have the same mangled name, thus appearing as multiple definitions of the same
function.
1.3.1 [defns.signature]
signature
name,parametertypelist(8.3.5), andenclosingnamespace(ifany),andanyassociated
constraints (14.10.2)
[Note: Signatures are used as a basis for name mangling and linking.—end note]
1.3.2 [defns.signature.templ]
signature
name, parameter type list (8.3.5), enclosing namespace (if any), return
type, and template parameter list, and any associated constraints (14.10.2)
1.3.3 [defns.signature.member]
§ 1.3 1
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 6 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
signature
name, parameter type list (8.3.5), class of which the function is a
member, cv-qualifiers (if any), and ref-qualifier (if any), and any associated constraints (14.10.2)
1.3.4 [defns.signature.member.templ]
signature
name, parameter type list (8.3.5), class of which the function
is a member, cv-qualifiers (if any), ref-qualifier (if any), return type, and template parameter
list, and any associated constraints (14.10.2)
1.4 Implementation compliance [intro.compliance]
1 ++
Conformance requirements for this specification are the same as those defined in 1.4 in the C Standard.
[Note: Conformance is defined in terms of the behavior of programs. —end note]
1.5 Feature-testing recommendations [intro.features]
1
An implementation that provides support for this Technical Specification shall define the feature test
macro(s) in Table A.
Table A — Feature-test macro(s)
Macro name Value
__cpp_concepts 201507
1.6 Acknowledgments [intro.ack]
1
The design of this specification is based, in part, on a concept specification of the algorithms part of the
C++ standard library, known as “The Palo Alto” report (WG21 N3351), which was developed by a large
group of experts as a test of the expressive power of the idea of concepts. Despite syntactic differences
between the notation of the Palo Alto report and this Technical Specification, the report can be seen as a
large-scale test of the expressiveness of this Technical Specification.
2
This work was funded by NSF grant ACI-1148461.
§ 1.6 2
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
2 Lexical conventions [lex]
2.1 Keywords [lex.key]
In 2.1, add the keywords concept and requires to Table 4.
§ 2.1 3
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
5 Expressions [expr]
Modify paragraph 8 to include a reference to requires-expressions.
1
In some contexts, unevaluated operands appear (5.1.4, 5.2.8, 5.3.3, 5.3.7).
5.1 Primary expressions [expr.prim]
5.1.1 General [expr.prim.general]
In this section, add the requires-expression to the rule for primary-expression.
primary-expression:
literal
this
( expression )
id-expression
lambda-expression
fold-expression
requires-expression
In paragraph 8, add auto and constrained-type-name to nested-name-specifier:
8
nested-name-specifier:
::
type-name ::
namespace-name ::
decltype-specifier ::
auto ::
constrained-type-name ::
nested-name-specifier identifier ::
nested-name-specifier template ::
opt
Add a new paragraph after paragraph 11:
12
In a nested-name-specifier of the form auto:: or C::, where C is a constrained-type-name, that
nested-name-specifier designates a placeholder that will be replaced later according to the rules
for placeholder deduction in 7.1.6.4. If a placeholder designated by a constrained-type-specifier
is not a placeholder type, the program is ill-formed. [Note: A constrained-type-specifier can
designate a placeholder for a non-type or template (7.1.6.4.2). —end note] The replacement
type deduced for a placeholder shall be a class or enumeration type. [Example:
template concept bool C = sizeof(T) == sizeof(int);
template concept bool D = true;
struct S1 { int n; };
struct S2 { char c; };
struct S3 { struct X { using Y = int; }; };
int auto::* p1 = &S1::n; // auto deduced as S1
int D::* p2 = &S1::n; // error: D does not designate a placeholder type
int C::* p3 = &S1::n; // OK: C deduced as S1
char C::* p4 = &S2::c; // error: deduction fails because constraints are not satisfied
§ 5.1.1 4
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
void f(typename auto::X::Y);
f(S1()); // error: auto cannot be deduced from S1()
f(0); // OK
In the declaration of f, the placeholder appears in a non-deduced context (14.8.2.5). It may be
replaced later through the explicit specification of template arguments. —end example]
Add a new paragraph after paragraph 13:
14
A program that refers explicitly or implicitly to a function with associated constraints that are
not satisfied (14.10.2), other than to declare it, is ill-formed. [Example:
void f(int) requires false;
f(0); // error: cannot call f
void (*p1)(int) = f; // error: cannot take the address of f
decltype(f)* p2 = nullptr; // error: the type decltype(f) is invalid
In each case the associated constraints of f are not satisfied. In the declaration of p2, those
constraints are required to be satisfied even though f is an unevaluated operand (Clause 5).
—end example]
5.1.2 Lambda expressions [expr.prim.lambda]
Insert the following paragraph after paragraph 4 to define the term “generic lambda”.
5
A generic lambda is a lambda-expression where one or more placeholders (7.1.6.4) appear in the
parameter-type-list of the lambda-declarator.
Modify paragraph 5 so that the meaning of a generic lambda is defined in terms of its abbreviated member
function template call operator.
The closure type for a non-generic lambda-expression has a public inline function call operator
(13.5.4) whose parameters and return type are described by the lambda-expression’s parameter-
declaration-clause and trailing-return-type, respectively. For a generic lambda, the closure type
hasapublic inline function calloperatormembertemplate (14.5.2)whosetemplate-parameter-list
consists of one invented type template-parameter for each occurrence of auto in the lambda’s
parameter-declaration-clause, in order of appearance. The invented type template-parameter
is a parameter pack if the corresponding parameter-declaration declares a function parameter
pack (8.3.5). The return type and function parameters of the function call operator template
are derived from the lambda-expression’s trailing-return-type and parameter-declaration-clause
by replacing each occurrence of auto in the decl-specifiers of the parameter-declaration-clause
with the name of the corresponding invented template-parameter. The closure type for a
generic lambda has a public inline function call operator member template that is an abbreviated
function template whose parameters and return type are derived from the lambda-expression’s
parameter-declaration-clause and trailing-return-type according to the rules in (8.3.5).
++
Add the following example after those in paragraph 5 in the C Standard.
[Example:
template concept bool C = true;
auto gl = [](C& a, C* b) { a = *b; }; // OK: denotes a generic lambda
struct Fun {
auto operator()(C& a, C* b) const { a = *b; }
} fun;
§ 5.1.2 5
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
C is a constrained-type-specifier, signifying that the lambda is generic. The generic lambda gl
and the function object fun have equivalent behavior when called with the same arguments.
—end example]
5.1.3 Fold expressions [expr.prim.fold]
Add this section after 5.1.2.
1
A fold expression performs a fold of a template parameter pack (14.6.3) over a binary operator.
fold-expression:
( cast-expression fold-operator . )
( . fold-operator cast-expression )
( cast-expression fold-operator . fold-operator cast-expression )
fold-operator: one of
+ - * / % ˆ & | << >>
+= -= *= /= %= ˆ= &= |= <<= >>= =
== != < > <= >= && || , .* ->*
2
An expression of the form (. op e) where op is a fold-operator is called a unary left fold.
An expression of the form (e op .) where op is a fold-operator is called a unary right fold.
Unary left folds and unary right folds are collectively called unary folds. In a unary fold, the
cast-expression shall contain an unexpanded parameter pack (14.6.3).
3
An expression of the form (e1 op1 . op2 e2) where op1 and op2 are fold-operators is called
a binary fold. In a binary fold, op1 and op2 shall be the same fold-operator, and either e1 shall
contain an unexpanded parameter pack or e2 shall contain an unexpanded parameter pack, but
not both. If e2 contains an unexpanded parameter pack, the expression is called a binary left
fold. If e1 contains an unexpanded parameter pack, the expression is called a binary right fold.
[Example:
template
bool f(Args .args) {
return (true && . && args); // OK
}
template
bool f(Args .args) {
return (args + . + args); // error: both operands contain unexpanded parameter packs
}
—end example]
5.1.4 Requires expressions [expr.prim.req]
Add this section to 5.1.
1
A requires-expression provides a concise way to express requirements on template arguments. A
requirement is one that can be checked by name lookup (3.4) or by checking properties of types
and expressions.
§ 5.1.4 6
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
requires-expression:
requires requirement-parameter-list requirement-body
opt
requirement-parameter-list:
( parameter-declaration-clause )
opt
requirement-body:
{ requirement-seq }
requirement-seq:
requirement
requirement-seq requirement
requirement:
simple-requirement
type-requirement
compound-requirement
nested-requirement
2
A requires-expression defines a constraint (14.10) based on its parameters (if any) and its nested
requirements.
3
A requires-expression has type bool and is an unevaluated expression (5). [Note: A requires-
expression is transformed into a constraint in order to determine if it is satisfied (14.10.2). —end
note]
4
A requires-expression shall appear only within a concept definition (7.1.7), or within the requires-
clause ofatemplate-declaration (Clause14)orfunctiondeclaration(8.3.5). [Example: Acommon
use of requires-expressions is to define requirements in concepts such as the one below:
template
concept bool R() {
return requires (T i) {
typename T::type;
{*i} -> const T::type&;
};
}
A requires-expression can also be used in a requires-clause as a way of writing ad hoc constraints
on template arguments such as the one below:
template
requires requires (T x) { x + x; }
T add(T a, T b) { return a + b; }
Thefirstrequiresintroducestherequires-clause,andthesecondintroducestherequires-expression.
—end example] [Note: Such requirements can also be written by defining them within a con-
cept.
template
concept bool C = requires (T x) { x + x; };
template requires C
T add(T a, T b) { return a + b; }
—end note]
5
Arequires-expression mayintroducelocalparametersusingaparameter-declaration-clause (8.3.5).
A local parameter of a requires-expression shall not have a default argument. Each name intro-
duced by a local parameter is in scope from the point of its declaration until the closing brace
of the requirement-body. These parameters have no linkage, storage, or lifetime; they are only
§ 5.1.4 7
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
used as notation for the purpose of defining requirements. The parameter-declaration-clause of a
requirement-parameter-list shall not terminate with an ellipsis. [Example:
template
concept bool C1() {
requires(T t, .) { t; }; // error: terminates with an ellipsis
}
template
concept bool C2() {
requires(T t, void (*p)(T*, .)) // OK: the parameter-declaration-clause of
{ p(t); }; // the requires-expression does not terminate
} // with an ellipsis
—end example]
6
The requirement-body is comprised of a sequence of requirements. These requirements may refer
to local parameters, template parameters, and any other declarations visible from the enclosing
context. Each requirement appends a constraint (14.10) to the conjunction of constraints defined
by the requires-expression. Constraints are appended in the order in which they are written.
7
The substitution of template arguments into a requires-expression may result in the formation
of invalid types or expressions in its requirements. In such cases, the constraints corresponding
to those requirements are not satisfied; it does not cause the program to be ill-formed. If the
substitution of template arguments into a requirement would always result in a substitution
failure, the program is ill-formed; no diagnostic required. [Example:
template concept bool C =
requires {
new int[-(int)sizeof(T)]; // ill-formed, no diagnostic required
};
—end example]
5.1.4.1 Simple requirements [expr.prim.req.simple]
simple-requirement:
expression ;
1
A simple-requirement introduces an expression constraint (14.10.1.3) for its expression. [Note:
An expression constraint asserts the validity of an expression. —end note]
[Example:
template concept bool C =
requires (T a, T b) {
a + b; // an expression constraint for a + b
};
—end example]
5.1.4.2 Type requirements [expr.prim.req.type]
type-requirement:
typename nested-name-specifier type-name ;
opt
1
A type-requirement introduces a type constraint (14.10.1.4) for the type named by its optional
nested-name-specifier and type-name. [Note: A type requirement asserts the validity of an
associated type, either as a member type, a class template specialization, or an alias template.
It is not used to specify requirements for arbitrary type-specifiers. —end note] [Example:
§ 5.1.4.2 8
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 13 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
template struct S { };
template using Ref = T&;
template concept bool C =
requires () {
typename T::inner; // required nested member name
typename S; // required class template specialization
typename Ref; // required alias template substitution
};
—end example]
5.1.4.3 Compound requirements [expr.prim.req.compound]
compound-requirement:
{ expression } noexcept trailing-return-type ;
opt opt
1
A compound-requirement introduces a conjunction of one or more constraints for the expression
E. The order in which those constraints are introduced is:
(1.1)
— the compound-requirement introduces an expression constraint for E (14.10.1.3);
(1.2)
— if the noexcept specifier is present, the compound-requirement appends an exception con-
straint for E (14.10.1.7);
(1.3)
— if the trailing-return-type is present, the compound-requirement appends one or more con-
straints derived from the type T named by the trailing-return-type:
(1.3.1)
— if T contains one or more placeholders (7.1.6.4), the requirement appends a deduction
constraint (14.10.1.6) of E against the type T.
(1.3.2)
— otherwise, the requirement appends two constraints: a type constraint on the formation
of T (14.10.1.4) and an implicit conversion constraint from E to T (14.10.1.5).
[Example:
template concept bool C1 =
requires(T x) {
{x++};
};
The compound-requirement in C1 introduces an expression constraint for x++. It is equivalent to
a simple-requirement with the same expression.
template concept bool C2 =
requires(T x) {
{*x} -> typename T::inner;
};
The compound-requirement in C2 introduces three constraints: an expression constraint for *x, a
type constraint for typename T::inner, and a conversion constraint requiring *x to be implicitly
convertible to typename T::inner.
template concept bool C3 =
requires(T x) {
{g(x)} noexcept;
};
The compound-requirement in C3 introduces two constraints: an expression constraint for g(x)
and an exception constraint for g(x).
§ 5.1.4.3 9
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 14 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
template concept bool C() { return true; }
template concept bool C5 =
requires(T x) {
{f(x)} -> const C&;
};
The compound-requirement in C5 introduces two constraints: an expression constraint for f(x),
and a deduction constraint requiring that overload resolution succeeds for the call g(f(x)) where
g is the following invented abbreviated function template.
void g(const C&);
—end example]
5.1.4.4 Nested requirements [expr.prim.req.nested]
nested-requirement:
requires-clause ;
1
A nested-requirement can be used to specify additional constraints in terms of local parameters.
A nested-requirement appends a predicate constraint (14.10.1.2) for its constraint-expression to
the conjunction of constraints introduced by its enclosing requires-expression. [Example:
template concept bool C() { return sizeof(T) == 1; }
template concept bool D =
requires (T t) {
requires C();
};
Thenested-requirement appendsthepredicateconstraintsizeof(decltype (+t)) == 1(14.10.1.2).
—end example] [Note: The constraint-expression of the predicate constraint introduced by a
nested-requirement is later normalized for the purposes of determining constraint satisfaction
(14.10.2) and partial ordering (14.10.3). —end note]
§ 5.1.4.4 10
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 15 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
7 Declarations [dcl.dcl]
7.1 Specifiers [dcl.spec]
Extend the decl-specifier production in paragraph 1 to include the concept specifier.
1
The specifiers that can be used in a declaration are
decl-specifier:
storage-class-specifier
type-specifier
function-specifier
friend
typedef
constexpr
concept
7.1.6 Type specifiers [dcl.type]
7.1.6.2 Simple type specifiers [dcl.type.simple]
Add constrained-type-specifier to the grammar for simple-type-specifiers.
simple-type-specifier:
nested-name-specifier type-name
opt
nested-name-specifier template simple-template-id
char
char16_t
char32_t
wchar_t
bool
short
int
long
signed
unsigned
float
double
void
auto
decltype-specifier
constrained-type-specifier
Modify paragraph 2 to begin:
1
The auto specifier is a placeholder for a type to be deduced (7.1.6.4). The auto specifier and
constrained-type-specifiers are placeholders for values (type, non-type, template) to be deduced
(7.1.6.4).
Add constrained-type-specifiers to the table of simple-type-specifiers in Table 10.
7.1.6.4 auto specifier [dcl.spec.auto]
Extend this section to allow for constrained-type-specifiers as a new syntax for designating placeholders.
The section is refactored so that placeholders are introduced in this section, deduction rules are defined in
subsection 7.1.6.4.1, and the meaning of constrained-type-specifiers is described in 7.1.6.4.2.
§ 7.1.6.4 11
© ISO/IEC 2015 – All rights reserved

---------------------- Page: 16 ----------------------
ISO/IEC TS 19217:2015 (E)
�c ISO/IEC N4549
Table 10 — simple-type-specifiers and the types they specify
Specifier(s) Type
type-name the type named
simple-template-id the type as defined in 14.3
.
.
.
auto placeholder for a type to be deduced
decltype(expression) the type as defined below
constrained-type-specifier placeholder for value (type, non-type, template) to be deduced
Replace paragraph 1 with the text below.
1
The type-specifiers auto and decltype(auto) and constrained-type-specifiers designate a place-
holder (type, non-type, or template) that will be replaced later, either through deduction or an
explicit specification. The auto and decltype(auto) type-specifiers designate placeholder types;
a constrained-type-specifier can also designate placeholders for values and templates. [Note: The
deduction of placeholders is done through the invention of template parameters as described
in 7.1.6.4.1 and 8.3.5. —end note] Placeholders are also used to signify that a lambda is a
generic lambda (5.1.2), that a function declaration is an abbreviated function template (8.3.5),
or that a trailing-return-type in a compound-requirement (5.1.4.3) introduces an argument deduc-
tion constraint (14.10.1.6). [Note: A nested-name-specifier can also include placeholders (5.1).
Replacements for those placeholders are determined according to the rules in this section. —end
note]
Modify paragraph 2 to allow constrained-type-specifiers with function declarators, except in the declared
return type.
2
The placeholder typePlaceholders can appear with a function declarator in the decl-specifier-seq,
type-specifier-seq, conversion-fun
...