Issue 1330: Move container requirements into requirements tables

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

1330. Move container requirements into requirements tables

Section: 24.2 [container.requirements] Status: NAD Submitter: Nicolai Josuttis Opened: 2010-03-10 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [container.requirements].

View all issues with NAD status.

Discussion:

Abstract:

In general, it seems that in a couple of places container behavior is not described in requirement tables although it is a general behavior.

History:

Issue 676 added move semantics to unordered containers. For the added insert functions the Editor requested to put their semantic description into a requirements table rather than describing them for each container individually. The text however was taken from the associative containers, where we also have the semantics for each container described. Also, 1034 is to some extend requesting a clarification of the requirement tables and it turned out that in other places we have the same problem (e.g. we have no general requirement for type pointer and const_pointer although each container has them with issue 1306).

From my personal list of functions in requirement tables and containers, the following types/functions are missing in requirement tables:

pointer, const_pointer in Table 91 (container requirements)
all copy constructors, copy constructors with allocator, assignment operators, and insert operators with move semantics for associative and unordered containers
```
ContType c1(c2&&)
ContType c1(c2&&,alloc)
c1 = c2&&
c.insert(val&&)
c.insert(pos,val&&)
```

As a special case, we lack the following requirements for all sequence containers BUT array (so special wording or a new container category is required):

constructor with only a size argument
```
ContType c(num)
```
copy constructor with allocator and move semantics
```
ContType c1(c2&&,alloc)
```

all constructors that insert multiple elements with additional allocator

ContType c(num, val,alloc)
ContType c(beg, end,alloc)
ContType c(initlist,alloc)

all resize functiuons:
```
c.resize(num)
c.resize(num,val)
```

Note that we also might have to add additional requirements on other places for sequence containers because having an allocator requires additional statements for the treatment of the allocators. E.g. swap for containers with allocators is not specified in any requirement table.

And finally, if we have the requirements in the requirements tables, we can remove the corresponding descriptions for the individual container. However, note that sequence container requirements have NO complexity column, so that we still need container specific descriptions for the functions listed there.

[ 2010 Batavia ]

While there is consensus that further cleaning up the container requirement tables would be a good thing, there is no feeling that this must be done in time for 0x. The issue remains open, but Deferred.

[ 2011 Bloomington ]

Closes as NAD. There are a number of deficiencies in the way the container requirements tables are presented, and the LWG welcomes further papers that will help clear up this presentation.

Proposed resolution: