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

### 2447. Allocators and `volatile`-qualified value types

Section: 16.4.4.6 [allocator.requirements] Status: C++17 Submitter: Daniel Krügler Opened: 2014-10-16 Last modified: 2017-07-30

Priority: 4

View other active issues in [allocator.requirements].

View all other issues in [allocator.requirements].

View all issues with C++17 status.

Discussion:

According to Table 27 — "Descriptive variable definitions" which is used to define the symbols used in the allocator requirements table within 16.4.4.6 [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 16.4.4.6 [allocator.requirements], Table 27 — "Descriptive variable definitions", as indicated:

>    > Table 27 — Descriptive variable definitions
>    > Variable | Definition
>    > --- | ---
>    > `T, U, C` | any non-const `const` and non-`volatile` object type (3.9)
>    > `C` | any object type
>    > `…`

> 2. Change 16.4.4.6 [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.

[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.

[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.

[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-05-06 Lenexa: Move to Ready]

Proposed resolution:

This wording is relative to N4431.

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

   > Table 27 — Descriptive variable definitions
   > Variable | Definition
   > --- | ---
   > `T, U, C` | any non-const cv-unqualified object type (3.9)
   > `…`