This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 23.2[container.requirements]Status:CD1Submitter: Peter DimovOpened: 2000-11-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [container.requirements].
View all issues withCD1 status.
Discussion:
23.1/3 states that the objects stored in a container must beAssignable. 23.4.3[map], paragraph 2,states that map satisfies all requirements for a container, while inthe same time defining value_type as pair<const Key, T> - a typethat is not Assignable.
It should be noted that there exists a valid and non-contradictoryinterpretation of the current text. The wording in 23.1/3 avoids mentioning value_type, referring instead to "objects stored in acontainer." One might argue that map does not store objects oftype map::value_type, but of map::mapped_type instead, and that theAssignable requirement applies to map::mapped_type, notmap::value_type.
However, this makes map a special case (other containers store objects oftype value_type) and the Assignable requirement is needlessly restrictive ingeneral.
For example, the proposed resolution of active library issue103(i) is to make set::iterator a constant iterator; thismeans that no set operations can exploit the fact that the storedobjects are Assignable.
This is related to, but slightly broader than, closed issue140(i).
Proposed resolution:
23.1/3: Strike the trailing part of the sentence:
, and the additional requirements of Assignable types from 23.1/3
so that it reads:
-3- The type of objects stored in these components must meet the requirements of CopyConstructible types (lib.copyconstructible).
23.1/4: Modify to make clear that this requirement is not for all containers. Change to:
-4- Table 64 defines the Assignable requirement. Some containers require this property of the types to be stored in the container. T is the type used to instantiate the container. t is a value of T, and u is a value of (possibly const) T.
23.1, Table 65: in the first row, change "T is Assignable" to "T isCopyConstructible".
23.2.1/2: Add sentence for Assignable requirement. Change to:
-2- A deque satisfies all of the requirements of a container and of a reversible container (given in tables in lib.container.requirements) and of a sequence, including the optional sequence requirements (lib.sequence.reqmts). In addition to the requirements on the stored object described in 23.1[lib.container.requirements], the stored object must also meet the requirements of Assignable. Descriptions are provided here only for operations on deque that are not described in one of these tables or for operations where there is additional semantic information.
23.2.2/2: Add Assignable requirement to specific methods of list. Change to:
-2- A list satisfies all of the requirements of a container and of a reversible container (given in two tables in lib.container.requirements) and of a sequence, including most of the the optional sequence requirements (lib.sequence.reqmts). The exceptions are the operator[] and at member functions, which are not provided. [Footnote: These member functions are only provided by containers whose iterators are random access iterators. --- end foonote]
list does not require the stored type T to be Assignable unless the following methods are instantiated:[Footnote: Implementors are permitted but not required to take advantage of T's Assignable properties for these methods. -- end foonote]
list<T,Allocator>& operator=(const list<T,Allocator>& x ); template <class InputIterator> void assign(InputIterator first, InputIterator last); void assign(size_type n, const T& t);Descriptions are provided here only for operations on list that are not described in one of these tables or for operations where there is additional semantic information.
23.2.4/2: Add sentence for Assignable requirement. Change to:
-2- A vector satisfies all of the requirements of a container and of a reversible container (given in two tables in lib.container.requirements) and of a sequence, including most of the optional sequence requirements (lib.sequence.reqmts). The exceptions are the push_front and pop_front member functions, which are not provided. In addition to the requirements on the stored object described in 23.1[lib.container.requirements], the stored object must also meet the requirements of Assignable. Descriptions are provided here only for operations on vector that are not described in one of these tables or for operations where there is additional semantic information.
Rationale:
list, set, multiset, map, multimap are able to store non-Assignables.However, there is some concern aboutlist<T>:although in general there's no reason for T to be Assignable, someimplementations of the member functionsoperator= andassign do rely on that requirement. The LWG does not wantto forbid such implementations.
Note that the type stored in a standard container must still satisfythe requirements of the container's allocator; this rules out, forexample, such types as "const int". See issue274(i)for more details.
In principle we could also relax the "Assignable" requirement forindividualvector member functions, such aspush_back. However, the LWG did not see great value in suchselective relaxation. Doing so would remove implementors' freedom toimplementvector::push_back in terms ofvector::insert.