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
Published
Publication Date
12-Nov-2015
Current Stage
6060 - International Standard published
Start Date
16-Sep-2015
Completion Date
13-Nov-2015
Ref Project

Buy Standard

Technical specification
ISO/IEC TS 19217:2015 - Information technology -- Programming languages -- C++ Extensions for concepts
English language
53 pages
sale 15% off
Preview
sale 15% off
Preview

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. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
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
List of Tables
Foreword
1 General

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]

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.

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.
1.2 Normative references [intro.refs]

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]

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]

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.
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.
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:
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:

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:

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”.

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.

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
+ - * / % ˆ & | << >>
+= -= *= /= %= ˆ= &= |= <<= >>= =
== != < > <= >= && || , .* ->*

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).

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.

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

A requires-expression defines a constraint (14.10) based on its parameters (if any) and its nested

requirements.

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]

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]

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]

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.

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 ;

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

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

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 ;

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.

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:

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.

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.

The placeholder typePlaceholders can appear with a function declarator in the decl-specifier-seq,

type-specifier-seq, conversion-fun
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.