[structure.requirements]

# 16 Library introduction [[library]](./#library)

## 16.3 Method of description [[description]](description#structure.requirements)

### 16.3.2 Structure of each clause [[structure]](structure#requirements)

#### 16.3.2.3 Requirements [structure.requirements]

[1](#1)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L227)

Requirements describe constraints that shall be met by a C++ program that extends the standard library[.](#1.sentence-1)

Such extensions are generally one of the following:

- [(1.1)](#1.1)

Template arguments

- [(1.2)](#1.2)

Derived classes

- [(1.3)](#1.3)

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

[2](#2)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L238)

The string and iostream components use an explicit representation of operations
required of template arguments[.](#2.sentence-1)

They use a class template char_traits to
define these constraints[.](#2.sentence-2)

[3](#3)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L243)

Interface convention requirements are stated as generally as possible[.](#3.sentence-1)

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”[.](#3.sentence-2)

That is, whether the operator is a member is unspecified[.](#3.sentence-3)

[4](#4)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L249)

Requirements are stated in terms of well-defined expressions that define valid terms of
the types that meet the requirements[.](#4.sentence-1)

For every set of well-defined expression
requirements there is either a named concept or a table that specifies an initial set of the valid expressions and
their semantics[.](#4.sentence-2)

Any generic algorithm ([[algorithms]](algorithms "26 Algorithms library")) that uses the
well-defined expression requirements is described in terms of the valid expressions for
its template type parameters[.](#4.sentence-3)

[5](#5)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L257)

The library specification uses a typographical convention for naming
requirements[.](#5.sentence-1)

Names in *italic* type that begin with the prefix*Cpp17* refer to sets of well-defined expression requirements typically
presented in tabular form, possibly with additional prose semantic requirements[.](#5.sentence-2)

For example, *Cpp17Destructible* (Table [35](utility.arg.requirements#tab:cpp17.destructible "Table 35: Cpp17Destructible requirements")) is such a named
requirement[.](#5.sentence-3)

Names in constant width type refer to library concepts
which are presented as a concept definition ([[temp]](temp "13 Templates")), possibly with additional
prose semantic requirements[.](#5.sentence-4)

For example,[destructible](concept.destructible#concept:destructible "18.4.10 Concept destructible [concept.destructible]") ([[concept.destructible]](concept.destructible "18.4.10 Concept destructible"))
is such a named requirement[.](#5.sentence-5)

[6](#6)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L269)

Template argument requirements are sometimes referenced by name[.](#6.sentence-1)

See [[type.descriptions]](type.descriptions "16.3.3.3 Type descriptions")[.](#6.sentence-2)

[7](#7)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L273)

In some cases the semantic requirements are presented as C++ code[.](#7.sentence-1)

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[.](#7.sentence-2)[133](#footnote-133 "Although in some cases the code given is unambiguously the optimum implementation.")

[8](#8)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L284)

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 met[.](#8.sentence-1)

[*Example [1](#example-1)*:

The required < operator of the [totally_ordered](concept.totallyordered#concept:totally_ordered "18.5.5 Concept totally_­ordered [concept.totallyordered]") concept ([[concept.totallyordered]](concept.totallyordered "18.5.5 Concept totally_­ordered")) does not meet the
semantic requirements of that concept when operating on NaNs[.](#8.sentence-2)

— *end example*]

This does not affect whether a type models the concept[.](#8.sentence-3)

[9](#9)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L295)

A declaration may explicitly impose requirements through its associated
constraints ([[temp.constr.decl]](temp.constr.decl "13.5.3 Constrained declarations"))[.](#9.sentence-1)

When the associated constraints refer to a
concept ([[temp.concept]](temp.concept "13.7.9 Concept definitions")), the semantic constraints specified for that concept
are additionally imposed on the use of the declaration[.](#9.sentence-2)

[133)](#footnote-133)[133)](#footnoteref-133)

Although in some cases the code given is
unambiguously the optimum implementation[.](#footnote-133.sentence-1)