Proposed resolution:

This wording is relative to N4431.

1. Change [allocator.requirements], Table 27 — "Descriptive variable definitions", as indicated:

   Table 27 — Descriptive variable definitions

   Variable	Definition
   T, U, C	any non-constcv-unqualified object type (3.9)
   …

[ 2015-05-06 Lenexa: Move to Ready ]

[ 2015-04-01 Daniel comments ]

The less controversial part of the issue related to constraints imposed on destroy has be handed over to the new issue 2470.

[ 2015-02 Cologne ]

GR: It makes me nervous that someone at some point decided to not add "non-volatile".
AM: That was over ten years ago. It was a deliberate, minuted choice to support volatile. We are now reversing that decision. It would be good to poll our vendors, none of which are in the room. This is a bit more work than we expect of a P0 issue.
VV: libstdc++ and libc++ seem to support volatile template parameters for the standard allocator.
AM: To clarify, the proposed resolution here would remove the requirement to support volatile. Implementations could still choose to support volatile.
DK: I'm happy to drop this and open a new issue in regard to the destroy member specification.
AM: I just think this is harder than a P0. Let's reprioritize.

[ 2014-11, Urbana ]

JW: say "cv-unqualified" instead?
JW: very nervous about allowing construct on const-types, because of the cast to (non-const) void*
MA: should we just make the minimal fix?
STL: don't break C out for special treatment
New proposed resolution: just change "non-const" to "cv-unqualified". Keep addition of destroy later.

According to Table 27 — "Descriptive variable definitions" which is used to define the symbols used in the allocator requirements table within [allocator.requirements] we have the following constraints for the types T, U, C:

any non-const object type (3.9)

This wording can be read to allow instead a volatile-qualified value type such as volatile int.

The nearest-by way of fixing this would be to add "non-volatile" as additional constraint to this table row.

Another choice would be to think of requiring that allocators must be capable to handle any cv-qualified value types. This would make all currently existing allocators non-conforming that can't handle cv-qualified value types, so I'm not suggesting to follow that route.

A less radical step would be to allow cv-qualified types just for C (which is used to specify the functions construct and destroy and where does not even exist any requirement that C actually is related to the value type of the allocator at all). This seemingly extension would be harmless because as of p8 of the same sub-clause "An allocator may constrain the types on which it can be instantiated and the arguments for which its construct member may be called."

This differs from the requirements imposed on the types T and U which both refer to value types of allocators.

The proposed wording attempts to separate the two classes of requirements.

Previous resolution [SUPERSEDED]:

This wording is relative to N4140.

1. Change [allocator.requirements], Table 27 — "Descriptive variable definitions", as indicated:

   Table 27 — Descriptive variable definitions

   Variable	Definition
   T, U, C	any non-constconst and non-volatile object type (3.9)
   C	any object type
   …

2. Change [allocator.requirements] p8 as indicated: (This wording change is intended to fix an obvious asymmetry between construct and destroy which I believe is not intended)

   -8- An allocator may constrain the types on which it can be instantiated and the arguments for which its construct or destroy members may be called. If a type cannot be used with a particular allocator, the allocator class or the call to construct or destroy may fail to instantiate.