This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.
allocate_at_leastSection: 17.3.2 [version.syn] Status: WP Submitter: Alisdair Meredith Opened: 2023-02-14 Last modified: 2023-11-22
Priority: Not Prioritized
View other active issues in [version.syn].
View all other issues in [version.syn].
View all issues with WP status.
Discussion:
In Issaquah, we just adopted P2652R0, forbidding user specialization of allocator_traits.
allocate_at_least, which is covered by the macro
__cpp_lib_allocate_at_least.
I believe we should have updated that macro for this significant change in how that function is accessed
(from free function to a member of allocator_traits). Unfortunately, there are no more meetings
to process a comment to that effect, and I suspect this rises beyond the purview of an editorial change,
although I live in hope (as the original paper left the value of the macro to the editor, although we
approved existing working papers where that macro does have a value, i.e., status quo).
[2023-03-22; Reflector poll]
Set status to Tentatively Ready after seven votes in favour during reflector poll. But "if we don’t get the editors to do it for C++23 there doesn’t seem to be any point doing it."
[2023-06-17 Approved at June 2023 meeting in Varna. Status changed: Voting → WP.]
Proposed resolution:
This wording is relative to N4928.
Modify 17.3.2 [version.syn], header <version> synopsis, as indicated and replace
the placeholder YYYYMM by the year and month of adoption of P2652R0:
[…] #define __cpp_lib_algorithm_iterator_requirements 202207L // also in <algorithm>, <numeric>, <memory> #define __cpp_lib_allocate_at_least202106YYYYMML // also in <memory> #define __cpp_lib_allocator_traits_is_always_equal 201411L // also in […] […]