Proposed resolution:

This wording is relative to N3485.

1. Edit [container.requirements.general] paragraph 7:

   Unless otherwise specified, all containers defined in this clause obtain memory using an allocator (see [allocator.requirements]). Copy constructors for these container types obtain an allocator by calling allocator_traits<allocator_type>::select_on_container_copy_construction on their first parameters. Move constructors obtain an allocator by move construction from the allocator belonging to the container being moved. Such move construction of the allocator shall not exit via an exception. All other constructors for these container types take an Allocator& argument ([allocator.requirements]), an allocator whose value type is the same as the container's value typea const allocator_type& argument. [Note: If an invocation of a constructor uses the default value of an optional allocator argument, then the Allocator type must support value initialization. — end note] A copy of this allocator is used for any memory allocation performed, by these constructors and by all member functions, during the lifetime of each container object or until the allocator is replaced. […]

[ 2013-04-20 Bristol ]

[ 2013-03-15 Issues Teleconference ]

Moved to Tentatively Ready.

[container.requirements.general]/7 says:

All other constructors for these container types take an Allocator& argument ([allocator.requirements]), an allocator whose value type is the same as the container's value type.

This is a strange place to state the requirement on the allocator's value_type, because the allocator is a property (and template parameter) of the container type not of some of its constructors. It's also unclear whether "Allocator&" refers to the concept (as implied by the cross-reference to the allocator requirements in Clause 17) or to the container's template parameter (as implied by the fact it's shown as an lvalue-reference type.) I believe the latter is intended, because those constructors can't take any model of the allocator concept, they can only take the container's allocator_type.

I think it would be clearer to remove the value type requirement earlier in the paragraph (Table 99 already imposes that requirement) and to make it clear the constructor arguments are the container's allocator_type. There is already a cross-reference to the allocator requirements earlier in the paragraph, so it doesn't need to be repeated in another place where it causes confusion.