This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
allocator
, polymorphic_allocator
, and containers should forbid cv-qualified typesSection: 20.2.10 [default.allocator], 20.4.3.1 [mem.poly.allocator.class.general], 24.2 [container.requirements] Status: New Submitter: Stephan T. Lavavej Opened: 2023-04-02 Last modified: 2023-05-24
Priority: 3
View other active issues in [default.allocator].
View all other issues in [default.allocator].
View all issues with New status.
Discussion:
LWG 2447(i) adjusted what is now N4944 16.4.4.6.1 [allocator.requirements.general]/2.1 so that the Cpp17Allocator requirements are specified for cv-unqualified object types only.
However, nothing in 20.2.10 [default.allocator] restricts whatT
in allocator<T>
can be,
except where 20.2.10.2 [allocator.members]/2 and /6 require it to be complete for allocate()
and
allocate_at_least()
(and by implication, for deallocate()
). (Long ago, allocator
had member functions
whose signatures implied that const
-qualified types were forbidden, but those signatures were deprecated and
removed. This explains the phrasing of an MSVC static assertion.)
20.4.3.1 [mem.poly.allocator.class.general] says a bit more about Tp
in polymorphic_allocator<Tp>
but doesn't forbid anything. It says that if Tp
is a cv-unqualified object type, then
polymorphic_allocator<Tp>
meets the Cpp17Allocator requirements and allocator completeness requirements,
but that's all.
There's some implementation variation here. libstdc++ and MSVC reject allocator<const int>
. libc++
(as of LLVM 16) accepts it but this appears to have been an extension that they're trying to get rid of (their maintainers
may be able to comment further; see
llvm-project/commit/a54d028895c91da356a4aaf30e27a5a5b90dd313).
These 3 implementations all reject allocator<volatile int>
, polymorphic_allocator<const int>
,
and polymorphic_allocator<volatile int>
with varying messages.
The Standard should provide clarity here, by mandating that only cv-unqualified object types be given to allocator
,
polymorphic_allocator
, and containers. (allocator<void>
must also be allowed, of course. I forget
if polymorphic_allocator
is supposed to accept void
.) This would simply Standardize existing/desired practice.
While it may seem arcane, attempting to form vector<const T>
is a common novice mistake — so common that
MSVC had to add a static_assert
to emit a clear error message.
[2023-05-24; Reflector poll]
Set priority to 3 after reflector poll.
Proposed resolution: