New issue from Alisdair: "What does it mean for a type to be "allocat…

…or aware"?"

xml/issue3976.xml

@@ -0,0 +1,36 @@
+<?xml version='1.0' encoding='utf-8' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
+
+<issue num="3976" status="New">
+<title>What does it mean for a type to be "allocator aware"?</title>
+<section><sref ref="[container.alloc.reqmts]"/></section>
+<submitter>Alisdair Meredith</submitter>
+<date>14 Aug 2023</date>
+<priority>99</priority>
+
+<discussion>
+<p>
+Trying to interpret the specification for <i>allocator-aware container</i>s, <sref ref="[container.alloc.reqmts]"/>.
+<p/>
+P1 establishes that <tt>std::array</tt> is <em>not</em> an allocator-aware container, but all other containers in
+the standard are.
+<p/>
+P2 then adds vocabulary, with ruling that if a container type <tt>X</tt> is not allocator-aware then
+the specification is as-if the allocator were <tt>std::allocator&lt;T&gt;</tt>. 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 <tt>std::array</tt>, which absolutely
+does not want to apply all the terms in this subclause.
+<p/>
+It looks like we might mean types that do not have everything specified by the first
+sentence, such as an <tt>allocator_type</tt> member. Perhaps we want to say a container
+type <tt>X</tt> is allocator-aware using allocator <tt>A</tt> if [&hellip;], and then that <tt>basic_string</tt> and
+containers that are not otherwise allocator aware are are treated as-if they were
+allocator-aware using <tt>std::allocator&lt;typename X::value_type&gt;</tt> (where <tt>value_type</tt>
+is already guaranteed to exist by the basic container requirements).
+</p>
+</discussion>
+
+<resolution>
+</resolution>
+
+</issue>