Section: 16.4.4.6 [allocator.requirements] Status: CD1 Submitter: Martin Sebor Opened: 2000-11-02 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with CD1 status.
Discussion:
I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of any type. But the synopsis in 20.4.1 calls for allocator<>::address() to be overloaded on reference and const_reference, which is ill-formed for all T = const U. In other words, this won't work:
template class std::allocator<const int>;
The obvious solution is to disallow specializations of allocators on const types. However, while containers' elements are required to be assignable (which rules out specializations on const T's), I think that allocators might perhaps be potentially useful for const values in other contexts. So if allocators are to allow const types a partial specialization of std::allocator<const T> would probably have to be provided.
Proposed resolution:
Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from
any type
to
any non-const, non-reference type
[Redmond: previous proposed resolution was "any non-const, non-volatile, non-reference type". Got rid of the "non-volatile".]
Rationale:
Two resolutions were originally proposed: one that partially specialized std::allocator for const types, and one that said an allocator's value type may not be const. The LWG chose the second. The first wouldn't be appropriate, because allocators are intended for use by containers, and const value types don't work in containers. Encouraging the use of allocators with const value types would only lead to unsafe code.
The original text for proposed resolution 2 was modified so that it also forbids volatile types and reference types.
[Curaçao: LWG double checked and believes volatile is correctly excluded from the PR.]