Init

2025-10-25 03:02:53 +03:00
commit 043225d523
3416 changed files with 681196 additions and 0 deletions
--- a/cppdraft/structure/requirements.md
+++ b/cppdraft/structure/requirements.md
@@ -0,0 +1,140 @@
+[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)