Requirements are stated in terms of well-defined expressions that define valid terms of
the types that meet the requirements.
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.
Any generic algorithm ([algorithms]) that uses the
well-defined expression requirements is described in terms of the valid expressions for
its template type parameters.
The library specification uses a typographical convention for naming
requirements.
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.
For example, Cpp17Destructible (Table 32) is such a named
requirement.
Names in constant width type refer to library concepts
which are presented as a concept definition ([temp]), possibly with additional
prose semantic requirements.
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.152
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.
The required < operator of the totally_ordered
concept ([concept.totallyordered]) does not meet the
semantic requirements of that concept when operating on NaNs.
— end example
]
This does not affect whether a type models the concept.
A declaration may explicitly impose requirements through its associated
constraints ([temp.constr.decl]).
When the associated constraints refer to a
concept ([temp.concept]), the semantic constraints specified for that concept
are additionally imposed on the use of the declaration.