[structure.requirements]

The string and iostream 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 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 35) 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.

For example, destructible ([concept.destructible]) is such a named requirement.

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.125

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.

[Example 1:

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.

125)125)

Although in some cases the code given is unambiguously the optimum implementation.