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: 23.2.2.5 [container.alloc.reqmts] Status: New Submitter: Alisdair Meredith Opened: 2023-08-14 Last modified: 2023-09-17
Priority: Not Prioritized
View all other issues in [container.alloc.reqmts].
View all issues with New status.
Discussion:
Trying to interpret the specification for allocator-aware containers, 23.2.2.5 [container.alloc.reqmts].
P1 establishes thatstd::array is not an allocator-aware container, but all other containers in
the standard are.
P2 then adds vocabulary, with ruling that if a container type X is not allocator-aware then
the specification is as-if the allocator were std::allocator<T>. I cannot find a specification
for allocator-aware, and do not believe we should treat this as a recursive definition, as
the only standard container that would be affected would be std::array, which absolutely
does not want to apply all the terms in this subclause.
It looks like we might mean types that do not have everything specified by the first
sentence, such as an allocator_type member. Perhaps we want to say a container
type X is allocator-aware using allocator A if […], and then that basic_string and
containers that are not otherwise allocator aware are are treated as-if they were
allocator-aware using std::allocator<typename X::value_type> (where value_type
is already guaranteed to exist by the container requirements, 23.2.2.2 [container.reqmts] p1).
Proposed resolution: