[ 2025-10-16; Reflector poll ]

Set priority to 4 after reflector poll.

"NAD. 'If X is not allocator-aware' is equivalent to 'if X is not an allocate-aware container type'. Note that [container.alloc.reqmts]/2 is not defining the requirements on an allocator-aware container; it's defining the related Cpp17Meow requirements. The allocator-aware container requirements are defined in paragraphs 3 and later, so this isn't a recursive definition."

Trying to interpret the specification for allocator-aware containers, [container.alloc.reqmts].

P1 establishes that std::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, [container.reqmts] p1).