Document number:       N2618=08-0128
Date:                            2008-05-13
Project:                        Programming Language C++, Library Working Group
Reply-to:                      Beman Dawes <bdawes at acm.org>
                                    Douglas Gregor <dgregor at cs.indiana.edu>

Concepts for the C++0x Standard Library: Chapter 17 -Introduction (Revision 1)

Douglas Gregor, Jeremiah Willcock, and Andrew Lumsdaine
Open Systems Laboratory
Indiana University
Bloomington, IN 47405

Beman Dawes
Software Libraries
Onancock, VA 23417-0400

Introduction

This document proposes changes to Chapter 17 of the C++ Standard Library to enable full use of concepts[1] throughout the library clauses.

This document is formatted in the same manner as the working draft of the C++ standard. Future versions of this document will track the working draft and the concepts proposal as they evolve. Proposed changes to the working paper provide enough current text to supply context, but only red current text with strikethrough is to be deleted, and only blue-green text with underscore is to be added, unless editorial comments state otherwise. All editorial comments will have a gray background.

The proposed changes involve adding wording to enable library components to be specified in terms of the concepts features of the language, and removing wording that enabled library components to be specified in pre-concepts terms. In the event that application of concepts to all components of the standard library does not occur at a single committee meeting, both forms of specification must coexist. The required changes are therefore specified in two phases, so they can be voted into the working paper at separate meetings if need be.

Note well: This proposal does not reflect changes to clause 17 that will be required if concepts are applied to clause 27, Input/output library. Such changes are deferred until an actual proposal for applying concepts to clause 27 is available.

Revision history

This proposal is a revision of N2037. Major changes include:

Phase I Proposed Wording - Enabling Concept based Specifications

17.1.14 [defns.narrow.iostream] narrow-oriented iostream classes

the instantiations of the iostream class templates on the character container class char and the default value of the traits parameterany other parameters. The traditional iostream classes are regarded as the narrow-oriented iostream classes (27.3.1).

17.1.22 [defns.wide.iostream] wide-oriented iostream classes

the instantiations of the iostream class templates on the character container class wchar_t and the default value of the traits parameter (27.3.2)any other parameters.

17.3.1.2 Requirements [structure.requirements]

The library can be extended by a C++ program. Each clause, as applicable, describes the requirements that such extensions must meet. Such extensions are generally one of the following:

— Template arguments
— Derived classes
— Containers, iterators, and/or algorithms that meet an interface convention

The string and iostreams components use an explicit representation of operations required of template arguments. They use a class template char_traits to define these constraints.

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 well-defined expressions, which define valid terms of the types that satisfy the requirements or concepts, which define capabilities of the types that satisfy the requirements. For every set of well-defined expression requirements there is a table that specifies an initial set of the valid expressions and their semantics (20.1.2, 23.1, 24.1). For every set of concept requirements there is a concept that specifies the requirements and their semantics (20.1.2, 23.1, 24.1). Any generic algorithm (clause 25) that uses the well-defined expression requirements is described in terms of the valid expressions for its formal type parameters. Any generic algorithm (clause 25) that uses concepts places requirements on its formal type parameters.

Template argument requirements are sometimes referenced by name. See 17.3.2.1.

In some cases the semantic requirements are presented as C++ code. Such code is intended as a specification of equivalence of a construct to another construct, not necessarily as the way the construct must be implemented.150)

17.3.1 Structure of each subclause [structure]

The elements of the C++ Standard Library are declared or defined (as appropriate) in a header.167)

The C++ Standard Library provides 4346 C++ headers, as shown in Table 13.

17.3.1 Structure of each subclause [structure], to Table 13: C++ Library Headers, add:

<concepts>
<iterator_concepts>
<numeric_concepts>

17.4.1.1 Library contents [lib.contents]

The C++ Standard Library provides definitions for the following types of entities: Macros, Values, Types, Concepts, Concept maps, Templates, Classes, Functions, Objects.

17.4.3.1 Namespace std [namespace.std]

The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a concept map for any standard library concept or a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type of external linkage and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.

Phase II Proposed Wording - Disabling Pre-Concepts Specifications

17.3.1.2 Requirements [structure.requirements]

The library can be extended by a C++ program. Each clause, as applicable, describes the requirements that such extensions must meet. Such extensions are generally one of the following:

— Template arguments
— Derived classes
— Containers, iterators, and/or algorithms that meet an interface convention

The string and iostreams components use an explicit representation of operations required of template arguments. They use a class template char_traits to define these constraints.

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 well-defined expressions, which define valid terms of the types that satisfy the requirements or concepts, which define capabilities of the types that satisfy the requirements. For every set of well-defined expression requirements there is a table that specifies an initial set of the valid expressions and their semantics. For every set of concept requirements there is a concept that specifies the requirements and their semantics (20.1.2, 23.1, 24.1). Any generic algorithm (clause 25) that uses the well-defined expression requirements is described in terms of the valid expressions for its formal type parameters. Any generic algorithm (clause 25) that uses concepts places requirements on its formal type parameters.

Template argument requirements are sometimes referenced by name. See 17.3.2.1.

In some cases the semantic requirements are presented as C++ code. Such code is intended as a specification of equivalence of a construct to another construct, not necessarily as the way the construct must be implemented.150)

17.3.2.1 Type descriptions [type.descriptions]

The Requirements subclauses may describe names that are used to specify constraints on template arguments.154) These names are used in library clauses to describe the types that may be supplied as arguments by a C++ program when instantiating template components from the library.

154) Examples from 20.1 include: EqualityComparable, LessThanComparable, CopyConstructable, etc. Examples from 24.1 include: InputIterator, ForwardIterator, Function, Predicate, etc.

Bibliography

[1] D. Gregor, B. Stroustrup, J. Siek, J. Widman. Proposed Wording for Concepts (Revision 5). Technical Report N2617=08-0127, ISO/IEC JTC 1, Information Technology, Subcommittee SC 22, Programming Language C++, May 2008.