Programming languages — C++ Extensions for ranges

ISO/IEC TS 21425:2017 describes extensions to the C++ Programming Language (2) that permit operations on ranges of data. These extensions include changes and additions to the existing library facilities as well as the extension of one core language facility. In particular, changes and extensions to the Standard Library include: - The formulation of the foundational and iterator concept requirements using the syntax of the Concepts TS (2). - Analogues of the Standard Library algorithms specified in terms of the new concepts. - The loosening of the algorithm constraints to permit the use of sentinels to denote the end of a range and corresponding changes to algorithm return types where necessary. - The addition of new concepts describing range and view abstractions; that is, objects with a begin iterator and an end sentinel. - New algorithm overloads that take range objects. - Support of callable objects (as opposed to function objects) passed as arguments to the algorithms. - The addition of optional projection arguments to the algorithms to permit on-the-fly data transforma- tions. - Analogues of the iterator primitives and new primitives in support of the addition of sentinels to the library. - Constrained analogues of the standard iterator adaptors and stream iterators that satisfy the new iterator concepts. - New iterator adaptors (counted_iterator and common_iterator) and sentinels (unreachable). Changes to the core language include: - the extension of the range-based for statement to support the new iterator range requirements (10.4). ISO/IEC TS 21425:2017 does not specify constrained analogues of other parts of the Standard Library (e.g., the numeric algorithms), nor does it add range support to all the places that could benefit from it (e.g., the containers). ISO/IEC TS 21425:2017 does not specify any new range views, actions, or facade or adaptor utilities; all are left as future work.

Langages de programmation — Extensions C++ pour les «ranges»

General Information

Status
Withdrawn
Publication Date
03-Dec-2017
Withdrawal Date
03-Dec-2017
Current Stage
9599 - Withdrawal of International Standard
Start Date
28-Jun-2021
Completion Date
28-Jun-2021
Ref Project

RELATIONS

Buy Standard

Technical specification
ISO/IEC TS 21425:2017 - Programming languages -- C++ Extensions for ranges
English language
158 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

TECHNICAL ISO/IEC TS
SPECIFICATION 21425
First edition
2017-11
Programming languages — C++
Extensions for ranges
Langages de programmation — Extensions C++ pour les «ranges»
Reference number
ISO/IEC TS 21425:2017(E)
ISO/IEC 2017
---------------------- Page: 1 ----------------------
ISO/IEC TS 21425:2017(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2017, 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 2017 – All rights reserved
---------------------- Page: 2 ----------------------
Contents
Foreword v
1 Scope 1
2 Normative references 1
3 Terms and definitions 1
4 General principles 2

4.1 Implementation compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

4.2 Namespaces, headers, and modifications to standard classes . . . . . . . . . . . . . . . . . 2

5 Statements 3

5.1 Iteration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

6 Library introduction 4

6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

6.2 Method of description (Informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

6.3 Library-wide requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

7 Concepts library 8

7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

7.2 Header synopsis . . . . . . . . . . . . . . . . . . . . . 9

7.3 Core language concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7.4 Comparison concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7.5 Object concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.6 Callable concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8 General utilities library 21

8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8.2 Utility components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8.3 Function objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.4 Metaprogramming and type traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8.5 Tagged tuple-like types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9 Iterators library 34

9.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.2 Header synopsis . . . . . . . . . . . . . . . . . . . . . 34

9.3 Iterator requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.4 Indirect callable requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

9.5 Common algorithm requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9.6 Iterator primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9.7 Iterator adaptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9.8 Stream iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10 Ranges library 94

10.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

10.2 decay_copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

10.3 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . 94

10.4 Range access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

10.5 Range primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

10.6 Range requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

iii
© ISO/IEC 2017 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC TS 21425:2017(E)
11 Algorithms library 101

11.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

11.2 Tag specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

11.3 Non-modifying sequence operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.4 Mutating sequence operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

11.5 Sorting and related operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

12 Numerics library 146

12.1 Uniform random number generator requirements . . . . . . . . . . . . . . . . . . . . . . . 146

A Compatibility features 147

A.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

A.2 Rvalue range access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

A.3 Range-and-a-half algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

B Acknowledgements 149
C Compatibility 150

C.1 C and Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

C.2 Ranges and the Palo Alto TR (N3351) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Bibliography 153
Index 154
Index of library names 155
© ISO/IEC 2017 – All rights reserved
---------------------- Page: 4 ----------------------
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.
© ISO/IEC 2017 – All rights reserved
---------------------- Page: 5 ----------------------
TECHNICAL SPECIFICATION ISO/IEC TS 21425:2017(E)
Programming languages — C++ Extensions for ranges
1 Scope [intro.scope]

This document describes extensions to the C Programming Language (2) that permit operations on ranges

of data. These extensions include changes and additions to the existing library facilities as well as the

extension of one core language facility. In particular, changes and extensions to the Standard Library include:

(1.1)

— The formulation of the foundational and iterator concept requirements using the syntax of the Concepts

TS (2).
(1.2)

— Analogues of the Standard Library algorithms specified in terms of the new concepts.

(1.3)

— The loosening of the algorithm constraints to permit the use of sentinels to denote the end of a range

and corresponding changes to algorithm return types where necessary.
(1.4)

— The addition of new concepts describing range and view abstractions; that is, objects with a begin

iterator and an end sentinel.
(1.5)
— New algorithm overloads that take range objects.
(1.6)

— Support of callable objects (as opposed to function objects) passed as arguments to the algorithms.

(1.7)

— The addition of optional projection arguments to the algorithms to permit on-the-fly data transforma-

tions.
(1.8)

— Analogues of the iterator primitives and new primitives in support of the addition of sentinels to the

library.
(1.9)

— Constrained analogues of the standard iterator adaptors and stream iterators that satisfy the new

iterator concepts.
(1.10)

— New iterator adaptors (counted_iterator and common_iterator) and sentinels (unreachable).

Changes to the core language include:
(2.1)

— the extension of the range-based for statement to support the new iterator range requirements (10.4).

This document does not specify constrained analogues of other parts of the Standard Library (e.g., the

numeric algorithms), nor does it add range support to all the places that could benefit from it (e.g., the

containers).

This document does not specify any new range views, actions, or facade or adaptor utilities; all are left as

future work.
2 Normative references [intro.refs]

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:2014, Programming Languages - C
(1.2) ++
— ISO/IEC TS 19217:2015, Programming Languages - C Extensions for Concepts

ISO/IEC 14882:2014 is herein called the C Standard and ISO/IEC TS 19217:2015 is called the Concepts

TS.
3 Terms and definitions [intro.defs]

For the purposes of this document, the terms and definitions given in ISO/IEC 14882:2014, ISO/IEC TS

19217:2015, and the following apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at http://www.iso.org/obp
© ISO/IEC 2017 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC TS 21425:2017(E)
— IEC Electropedia: available at http://www.electropedia.org/
3.1 [defns.expr.equiv]
expression-equivalent
relationship that exists between two expressions E1 and E2 such that
— E1 and E2 have the same effects,
— noexcept(E1) == noexcept(E2), and

— E1 is a constant subexpression — an expression whose evaluation as subexpression of a conditional-

expression CE (ISO/IEC 14882:2014 §5.16) would not prevent CE from being a core constant expres-

sion (ISO/IEC 14882:2014 §5.19) — if and only if E2 is a constant subexpression
3.2 [defns.projection]
projection

〈function object argument〉 transformation which an algorithm applies before inspecting the values of elements

[Example:
std::pair pairs[] = {{2, "foo"}, {1, "bar"}, {0, "baz"}};
ranges::sort(pairs, std::less<>{}, [](auto const& p) { return p.first; });
sorts the pairs in increasing order of their first members:
{{0, "baz"}, {1, "bar"}, {2, "foo"}}
—end example]
4 General principles [intro]
4.1 Implementation compliance [intro.compliance]

Conformance requirements for this specification are the same as those defined in ISO/IEC 14882:2014 §1.4.

[Note: Conformance is defined in terms of the behavior of programs. —end note]
4.2 Namespaces, headers, and modifications to standard classes [intro.namespaces]
1 ++

Since the extensions described in this document are experimental and not part of the C standard library,

they should not be declared directly within namespace std. Unless otherwise specified, all components

described in this document either:
(1.1)
— modify an existing interface in the C Standard Library in-place,
(1.2)
— are declared in namespace std::experimental::ranges::v1.

The International Standard, ISO/IEC 14882, together with ISO/IEC TS 19217:2015 (the Concepts TS),

provide important context and specification for this document. In places, this document suggests changes

to be made to components in namespace std in-place. In other places, entire chapters and sections are

copied from ISO/IEC 14882 and modified so as to define similar but different components in namespace

std::experimental::ranges::v1.

Instructions to modify or add paragraphs are written as explicit instructions. Modifications made to existing

text from the International Standard use underlining to represent added text and strikethrough to represent

deleted text.

This document assumes that the contents of the std::experimental::ranges::v1 namespace will become

a new constrained version of the C Standard Library that will be delivered alongside the existing

unconstrained version.

Unless otherwise specified, references to other entities described in this document are assumed to be qualified

with std::experimental::ranges::, and references to entities described in the International Standard are

assumed to be qualified with std::.

New header names are prefixed with experimental/ranges/. Where the final element of a new header

name is the same as an existing standard header name (e.g., ), the new

header shall include the standard header as if by
© ISO/IEC 2017 – All rights reserved
---------------------- Page: 7 ----------------------
#include
5 Statements [stmt]
5.1 Iteration statements [stmt.iter]
5.1.1 The range-based for statement [stmt.ranged]

[Note: This clause is presented as a set of differences to apply to ISO/IEC 14882:2014 §6.5.4 to allow

differently typed begin and end iterators, as in C++17. —end note]
For a range-based for statement of the form
for ( for-range-declaration : expression ) statement
let range-init be equivalent to the expression surrounded by parentheses
( expression )
and for a range-based for statement of the form
for ( for-range-declaration : braced-init-list ) statement

let range-init be equivalent to the braced-init-list. In each case, a range-based for statement is

equivalent to
auto && __range = range-init;
for ( auto __begin = begin-expr,
__end = end-expr;
__begin != __end;
++__begin ) {
for-range-declaration = *__begin;
statement
The range-based for statement
for ( for-range-declaration : for-range-initializer ) statement
is equivalent to
auto &&__range = for-range-initializer;
auto __begin = begin-expr;
auto __end = end-expr;
for ( ; __begin != __end; ++__begin ) {
for-range-declaration = *__begin;
statement
where
(2.1)

— if the for-range-initializer is an expression, it is regarded as if it were surrounded by

parentheses (so that a comma operator cannot be reinterpreted as delimiting two init-

declarators);
(2.2)

— __range, __begin, and __end are variables defined for exposition only; and _RangeT is the

type of the expression, and begin-expr and end-expr are determined as follows:
(2.3)
— begin-expr and end-expr are determined as follows:
(2.3.1)

— if _RangeTthe for-range-initializer is an expression of array type R, begin-expr and end-

expr are __range and __range + __bound, respectively, where __bound is the array

bound. If _RangeTR is an array of unknown sizebound or an array of incomplete type,

the program is ill-formed;
© ISO/IEC 2017 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TS 21425:2017(E)
(2.3.2)

— if _RangeTthe for-range-initializer is aan expression of class type C, the unqualified-ids

begin and end are looked up in the scope of class _RangeTC as if by class member access

lookup (3.4.5), and if either (or both) finds at least one declaration, begin-expr and

end-expr are __range.begin() and __range.end(), respectively;
(2.3.3)

— otherwise, begin-expr andend-expr arebegin(__range)andend(__range), respectively,

wherebeginandendarelookedupintheassociatednamespaces(3.4.2). [Note: Ordinary
unqualified lookup (3.4.1) is not performed. —end note]
[Example:
int array[5] = { 1, 2, 3, 4, 5 };
for (int& x : array)
x *= 2;
—end example]

In the decl-specifier-seq of a for-range-declaration, each decl-specifier shall be either a type-specifier

or constexpr. The decl-specifier-seq shall not define a class or enumeration.
6 Library introduction [library]
6.1 General [library.general]
1 ++

This Clause describes the contents of the Ranges library, how a well-formed C program makes use of the

library, and how a conforming implementation may provide the entities in the library.

Clause 6.3, Clauses 7 through 12, and Annex Annex A specify the contents of the library, as well as library

requirements and constraints on both well-formed C programs and conforming implementations.

Detailed specifications for each of the components in the library are in Clauses 7–12, as shown in Table 1.

Table 1 — Library categories
Clause Category
7 Concepts library
8 General utilities library
9 Iterators library
10 Ranges library
11 Algorithms library
12 Numerics library

The concepts library (Clause 7) describes library components that C programs may use to perform

compile-time validation of template parameters and perform function dispatch based on properties of types.

The general utilities library (Clause 8) includes components used by other library elements and components

used as infrastructure in C programs, such as function objects.
6 ++

The iterators library (Clause 9) describes components that C programs may use to perform iterations over

containers (Clause ISO/IEC 14882:2014 §23), streams (ISO/IEC 14882:2014 §27.7), stream buffers (ISO/IEC

14882:2014 §27.6), and ranges (10).

The ranges library (Clause 10) describes components for dealing with ranges of elements.

The algorithms library (Clause 11) describes components that C programs may use to perform algorithmic

operations on containers (Clause ISO/IEC 14882:2014 §23) and other sequences.

The numerics library (Clause 12) provides concepts that are useful to constrain numeric algorithms.

6.2 Method of description (Informative) [description]

This subclause describes the conventions used to specify the Ranges library. 6.2.1 describes the structure of

the normative Clauses 7 through 12 and Annex Annex A. 6.2.2 describes other editorial conventions.

© ISO/IEC 2017 – All rights reserved
---------------------- Page: 9 ----------------------
6.2.1 Structure of each clause [structure]
6.2.1.1 Elements [structure.elements]
Each library clause contains the following elements, as applicable:
(1.1)
— Summary
(1.2)
— Requirements
(1.3)
— Detailed specifications
6.2.1.2 Summary [structure.summary]

The Summary provides a synopsis of the category, and introduces the first-level subclauses. Each subclause

also provides a summary, listing the headers specified in the subclause and the library entities provided in

each header.

Paragraphs labeled “Note(s):” or “Example(s):” are informative, other paragraphs are normative.

The contents of the summary and the detailed specifications include:
(3.1)
— macros
(3.2)
— values
(3.3)
— types
(3.4)
— classes and class templates
(3.5)
— functions and function templates
(3.6)
— objects
(3.7)
— concepts
6.2.1.3 Requirements [structure.requirements]

Requirements describe constraints that shall be met by a C program that extends the Ranges library.

Such extensions are generally one of the following:
(1.1)
— Template arguments
(1.2)
— Derived classes
(1.3)

— Containers, iterators, and algorithms that meet an interface convention or satisfy a concept

Interface convention requirements are stated as generally as possible. Instead of stating “class X has to define

a member function operator++(),” the interface requires “for any object x of class X, ++x is defined.” That

is, whether the operator is a member is unspecified.

Requirements are stated in terms of concepts (Concepts TS [dcl.spec.concept]). Concepts are stated in

terms of well-defined expressions that define valid terms of the types that satisfy the concept. For every set

of well-defined expression requirements there is a named concept that specifies an initial set of the valid

expressions and their semantics. Any generic algorithm (Clause 11) that uses the well-defined expression

requirements is described in terms of the valid expressions for its formal type parameters.

Template argument requirements are sometimes referenced by name. See ISO/IEC 14882:2014 §17.5.2.1.

In some cases the semantic requirements are presented as C code. Such code is intended as a specification of

equivalenceofaconstructtoanotherconstruct, notnecessarilyasthewaytheconstructmustbeimplemented.

Required operations of any concept defined in this document need not be total functions; that is, some

arguments to a required operation may result in the required semantics failing to be satisfied. [Example: The

required < operator of the StrictTotallyOrdered concept (7.4.4) does not meet the semantic requirements

of that concept when operating on NaNs.—end example] This does not affect whether a type satisfies the

concept.

A declaration may explicitly impose requirements through its associated constraints (Concepts TS [temp.

constr.decl]). When the associated constraints refer to a concept (Concepts TS [dcl.spec.concept]), additional

semantic requirements are imposed on the use of the declaration.

1) To save space, items that do not apply to a Clause are omitted. For example, if a Clause does not specify any requirements,

there will be no “Requirements” subclause.

2) Although in some cases the code given is unambiguously the optimum implementation.

© ISO/IEC 2017 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TS 21425:2017(E)
6.2.1.4 Detailed specifications [structure.specifications]

The detailed specifications of each entity defined in Clauses 7–12 follow the conventions established by

ISO/IEC 14882:2014 §17.5.1.4.
6.2.2 Other conventions [conventions]

This subclause describes several editorial conventions used to describe the contents of the Ranges library.

These conventions are for describing member functions (6.2.2.1), and private members (6.2.2.2).

6.2.2.1 Functions within classes [functions.within.classes]

This document follows the same conventions as specified in ISO/IEC 14882:2014 §17.5.2.2.

6.2.2.2 Private members [objects.within.classes]

This document follows the same conventions as specified in ISO/IEC 14882:2014 §17.5.2.3.

6.3 Library-wide requirements [requirements]

This subclause specifies requirements that apply to the entire Ranges library. Clauses 7 through 12 and

Annex Annex A specify the requirements of individual entities within the library.

Requirements specified in terms of interactions between threads do not apply to programs having only a

single thread of execution.

Within this subclause, 6.3.1 describes the library’s contents and organization, 6.3.3 describes how well-formed

++ ++

C programs gain access to library entities, 6.3.4 describes constraints on well-formed C programs, and

6.3.5 describes constraints on conforming implementations.
6.3.1 Library contents and organization [organization]
6.3.1.1 describes the entities and macros defined in the Ranges library.
6.3.1.1 Library contents [contents]

The Ranges library provides definitions for the entities and macros specified in the Ranges library head-

ers (6.3.2).

All library entities are defined within an inline namespace v1 within the namespace std::experimental::

ranges or namespaces nested within namespace std::experimental::ranges::v1. It is unspecified whether

names declared in a specific namespace are declared directly in that namespace or in an inline namespace

inside that namespace.
6.3.2 Headers [headers]

Each element of the Ranges library is declared or defined (as appropriate) in a header.

The Ranges library provides the Ranges library headers, shown in Table 2.
Table 2 — Ranges TS library headers





6.3.3 Using the library [using]
6.3.3.1 Overview [using.overview]

This section describes how a C program gains access to the facilities of the Ranges library. 6.3.3.2 describes

effects during translation phase 4, while 6.3.3.3 describes effects during phase 8 (ISO/IEC 14882:2014 §2.2).

6.3.3.2 Headers [using.headers]

The entities in the Ranges library are defined in headers, the use of which is governed by the same requirements

as specified in ISO/IEC 14882:2014 §17.6.2.2.
© ISO/IEC 2017 – All rights reserved
---------------------- Page: 11 ----------------------
6.3.3.3 Linkage [using.linkage]
1 ++

Entities in the C standard library have external linkage (ISO/IEC 14882:2014 §3.5). Unless otherwise

specified, objects and functions have the default extern "C++" linkage (ISO/IEC 14882:2014 §7.5).

6.3.4 Constraints on programs [constraints]
6.3.4.1 Overview [constraints.overview]
1 ++

This section describes restrictions on C programs that use the facilities of the Ranges library. The following

subclauses specify constraints on the program’s use of Ranges library classes as base classes (6.3.4.2) and

other constraints.
6.3.4.2 Derived classes [derived.classes]

Virtual member function signatures defined for a base class in the Ranges library may be overridden in a

derived class defined in the program (ISO/IEC 14882:2014 §10.3).
6.3.4.3 Other functions [res.on.functions]

In certain cases (operations on types used to instantiate Ranges library template components), the Ranges

library depends on components supplied by a C program. If these components do not meet their

requirements, this document places no requirements on the implementation.

In particular, the effects are undefined if an incomplete type (ISO/IEC 14882:2014 §3.9) is used as a template

argument when instantiating a template component or evaluating a concept, unless specifically allowed for

that component.
6.3.4.4 Function arguments [res.on.arguments]

The constraints on arguments passed to C standard library function as specified in ISO/IEC 14882:2014

§17.6.4.9 also apply to arguments passed to functions in the Ranges library.
6.3.4.5 Library object access [res.on.objects]

The constraints on object access by C standard library functions as specified in ISO/IEC 14882:2014

§17.6.4.10 also apply to object access by functions in the Ranges library.
6.3.4.6 Requires paragraph [res.on.required]

Violation of the preconditions specified in a function’s Requires: paragraph results in undefined behavior

unless the function’s Throws: paragraph specifies throwing an exception when the precondition is violated.

6.3.4.7 Semantic requirements [res.on.requirements]

If the semantic requirements of a declaration’s constraints (6.2.1.3) are not satisfied at the point of use, the

program is ill-formed, no diagnostic required.
6.3.5 Conforming implementations [conforming]

The constraints upon, and latitude of, implementations of the Ranges library follow the same constraints and

latitudes for implementations of the C standard library as specified in ISO/IEC 14882:2014 §17.6.5.

6.3.5.1 Customization Point Objects [customization.point.object]

A customization point object is a function object (8.3) with a literal class type that interacts with user-defined

types while enforcing semantic requirements on that interaction.
The type of a customization point object shall satisfy Semiregular (7.5.3).

All instances of a specific customization point object type shall be equal (7.1.1).

The type of a customization point object T shall satisfy Invocable (7.6.2) when the

types of Args... meet the requirements specified in that customization point object’s definition. Otherwise,

T shall not have a function call operator that participates in overload resolution.

Each customization point object type constrains its return type to satisfy a particular concept.

The library defines several named customization point objects. In every translation unit where such a name

is defined, it shall refer to the same instance of the customization point object.

[Note: Many of the customization point objects in the library evaluate function call expressions with an

unqualified name which results in a call to a user-defined function found by argument dependent name

© ISO/IEC 2017 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC TS 21425:2017(E)

lookup (ISO/IEC 14882:2014 §3.4.2). To preclude such an expression resulting in a call to unconstrained

functions with the same name in namespace std, cust
...

Questions, Comments and Discussion

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