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.

4258. Size type mismatch in constraints involving Cpp17Allocator

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

However, it is not exactly required that a type meeting the Cpp17Allocator requirements can be used with 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: