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.
Section: 16.4.4.6.1 [allocator.requirements.general] Status: New Submitter: Jiang An Opened: 2025-05-05 Last modified: 2025-10-14
Priority: 4
View other active issues in [allocator.requirements.general].
View all other issues in [allocator.requirements.general].
View all issues with New status.
Discussion:
It seems assumed that a size_t value can be passed to an allocator's allocate member
function per the simple-allocator exposition-only concept in
16.4.4.6.1 [allocator.requirements.general] and the minimal constraints for
allocator types in 23.2.2.2 [container.reqmts].
size_t values, because only allocator_traits<A>::size_type,
which is possibly not size_t, is required to be usable with the allocator.
Do we want to change these constraints, or change the Cpp17Allocator requirements to
require accepting size_t values?
[2025-10-14; Reflector poll]
Set priority to 4 after reflector poll.
"The wording technically allows you to write
allocate(same_as<size_type> auto)
and reject any other type."
"I imagine lots of code relies on std::size_t being accepted.
That's surely a general design issue that's much broader than just the
Cpp17Allocator requirement,
and making the requirement stricter seems evolutionary."
Proposed resolution: