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.
If the diagnostic is to be emitted only after the function
has been selected by overload resolution,
an implementation might express such a condition
via a constraint-expression
and also define the function as deleted.
Whenever the Effects element specifies that the semantics of some function
F are Equivalent to some code sequence, then the various elements are
interpreted as follows.
If F's semantics specifies any Constraints or Mandates elements,
then those requirements are logically imposed prior to the equivalent-to semantics.
Next, the semantics of the code sequence are determined by the
Constraints, Mandates, Preconditions, Effects,
Synchronization, Postconditions, Returns, Throws,
Complexity, Remarks, and Error conditions
specified for the function invocations contained in the code sequence.
The value returned from F is specified by F's Returns element,
or if F has no Returns element,
a non-void return from F is specified by the
return statements ([stmt.return]) in the code sequence.
If F's semantics contains a Throws,
Postconditions, or Complexity element,
then that supersedes any occurrences of that element in the code sequence.
For non-reserved replacement and handler functions,
[support] specifies two behaviors for the functions in question:
their required and default behavior.
The default behavior
describes a function definition provided by the implementation.
The required behavior
describes the semantics of a function definition provided by
either the implementation or a C++ program.
Where no distinction is explicitly made in the description, the
behavior described is the required behavior.
Complexity requirements specified in the library clauses are upper bounds,
and implementations that provide better complexity guarantees meet
the requirements.