Rationale:

Scoped allocators have been revised significantly.

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Addressed by N2982.

[ 2009-06-09 Alan adds: ]

I reopened this issue because I did not think that these National Body comments were adequately addressed by marking them NAD. My understanding is that something can be marked NAD if it is clearly a misunderstanding or trivial, but a substantive issue that has any technical merit requires a disposition that addresses the concerns.

The notes in the NB comment list (US 65 & US 74.1) say that:

1. this issue has not introduced any new arguments not previously discussed,
2. the vote (4-9-3) was not a consensus for removing scoped allocators,
3. the issue is resolved by N2840.

My opinion is:

1. there are new arguments in both comments regarding concepts (which were not present in the library when the scoped allocator proposal was voted in),
2. the vote was clearly not a consensus for removal, but just saying there was a vote does not provide a rationale,
3. I do not believe that N2840 addresses these comments (although it does many other things and was voted in with strong approval).

My motivation to open the issue was to ensure that the NB comments were adequately addressed in a way that would not risk a "no" vote on our FCD. If there are responses to the technical concerns raised, then perhaps they should be recorded. If the members of the NB who authored the comments are satisfied with N2840 and the other disposition remarks in the comment list, then I am sure they will say so. In either case, this issue can be closed very quickly in Frankfurt, and hopefully will have helped make us more confident of approval with little effort. If in fact there is controversy, my thought is that it is better to know now rather than later so there is more time to deal with it.

[ 2009-05-15 Ganesh adds: ]

The requirement AllocatableElement should not be replaced with Constructible on the emplace_xxx() functions as suggested. In the one-parameter case the Constructible requirement is not satisfied when the constructor is explicit (as per [concept.map.fct], twelfth bullet) but we do want to allow explicit constructors in emplace, as the following example shows:

vector<shared_ptr<int>> v;
v.emplace_back(new int); // should be allowed

If the issue is accepted and scoped allocators are removed, I suggest to add a new pair of concepts to [concept.construct], namely:

auto concept HasExplicitConstructor<typename T, typename... Args> {
 explicit T::T(Args...);
}

auto concept ExplicitConstructible<typename T, typename... Args>
 : HasExplicitConstructor<T, Args...>, NothrowDestructible<T>
{ }

We should then use ExplicitConstructible as the requirement for all emplace_xxx() member functions.

For coherence and consistency with the similar concepts Convertible/ExplicitlyConvertible, we might also consider changing Constructible to:

auto concept Constructible<typename T, typename... Args>
 : HasConstructor<T, Args...>, ExplicitConstructible<T, Args...>
{ }

Moreover, all emplace-related concepts in [container.concepts] should also use ExplicitConstructible instead of Constructible in the definitions of their axioms. In fact the concepts in [container.concepts] should be corrected even if the issue is not accepted.

On the other hand, if the issue is not accepted, the scoped allocator adaptors should be fixed because the following code:

template <typename T> using scoped_allocator = scoped_allocator_adaptor<allocator<T>>;

vector<shared_ptr<int>, scoped_allocator<shared_ptr<int>>> v;
v.emplace_back(new int); // ops! doesn't compile

doesn't compile, as the member function construct() of the scoped allocator requires non-explicit constructors through concept ConstructibleWithAllocator. Fixing that is not difficult but probably more work than it's worth and is therefore, IMHO, one more reason in support of the complete removal of scoped allocators.

[ Post Summit Alan moved from NAD to Open. ]

Addresses US 65 and US 74.1 [CD1]

US 65:

Scoped allocators and allocator propagation traits add a small amount of utility at the cost of a great deal of machinery. The machinery is user visible, and it extends to library components that don't have any obvious connection to allocators, including basic concepts and simple components like pair and tuple.

Suggested resolution:

Sketch of proposed resolution: Eliminate scoped allocators, replace allocator propagation traits with a simple uniform rule (e.g. always propagate on copy and move), remove all mention of allocators from components that don't explicitly allocate memory (e.g. pair), and adjust container interfaces to reflect this simplification.

Components that I propose eliminating include HasAllocatorType, is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor, and ConstructibleAsElement.

US 74.1:

Scoped allocators represent a poor trade-off for standardization, since (1) scoped-allocator--aware containers can be implemented outside the C++ standard library but used with its algorithms, (2) scoped allocators only benefit a tiny proportion of the C++ community (since few C++ programmers even use today's allocators), and (3) all C++ users, especially the vast majority of the C++ community that won't ever use scoped allocators are forced to cope with the interface complexity introduced by scoped allocators.

In essence, the larger community will suffer to support a very small subset of the community who can already implement their own data structures outside of the standard library. Therefore, scoped allocators should be removed from the working paper.

Some evidence of the complexity introduced by scoped allocators:

[pairs], [tuple]: Large increase in the number of pair and tuple constructors.

[containers]: Confusing "AllocatableElement" requirements throughout.

Suggested resolution:

Remove support for scoped allocators from the working paper. This includes at least the following changes:

Remove [allocator.element.concepts]

Remove [allocator.adaptor]

Remove [construct.element]

In Clause [containers]: replace requirements naming the AllocatableElement concept with requirements naming CopyConstructible, MoveConstructible, DefaultConstructible, or Constructible, as appropriate.