This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 99 [library] Status: CD1 Submitter: Beman Dawes Opened: 2000-04-26 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [library].
View all other issues in [library].
View all issues with CD1 status.
Discussion:
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, 28.5.3 [rand.req].
Proposed resolution:
In 24.2 [container.requirements] table 65 for value_type: change "T is Assignable" to "T is CopyConstructible and Assignable"
In 24.2.7 [associative.reqmts] table 69 X::key_type; change
"Key is Assignable" to "Key is
CopyConstructible and Assignable"
In 25.3.5.4 [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:
[Post-Tokyo: Beman Dawes submitted this issue at the request of the LWG. He asks that the 27.7.5 [alg.replace] and 27.7.6 [alg.fill] changes be studied carefully, as it is not clear that CopyConstructible is really a requirement and may be overspecification.]
[Portions of the resolution for issue 230 have been superceded by the resolution of issue 276.]
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.