Rationale:

The original proposed resolution also included changes to input iterator, fill, and replace. The LWG believes that those changes are not necessary. The LWG considered some blanket statement, where an Assignable type was also required to be Copy Constructible, but decided against this because fill and replace really don't require the Copy Constructible property.

[ Portions of the resolution for issue 230 have been superceded by the resolution of issue 276. ]

[ Post-Tokyo: Beman Dawes submitted this issue at the request of the LWG. He asks that the [alg.replace] and [alg.fill] changes be studied carefully, as it is not clear that CopyConstructible is really a requirement and may be overspecification. ]

Proposed resolution:

In [container.requirements] table 65 for value_type: change "T is Assignable" to "T is CopyConstructible and Assignable"

In [associative.reqmts] table 69 X::key_type; change "Key is Assignable" to "Key is CopyConstructible and Assignable"

In [output.iterators] paragraph 1, change:

A class or a built-in type X satisfies the requirements of an output iterator if X is an Assignable type (23.1) and also the following expressions are valid, as shown in Table 73:

to:

A class or a built-in type X satisfies the requirements of an output iterator if X is a CopyConstructible (20.1.3) and Assignable type (23.1) and also the following expressions are valid, as shown in Table 73:

Issue 227 identified an instance (std::swap) where Assignable was specified without also specifying CopyConstructible. The LWG asked that the standard be searched to determine if the same defect existed elsewhere.

There are a number of places (see proposed resolution below) where Assignable is specified without also specifying CopyConstructible. There are also several cases where both are specified. For example, [rand.req].