<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 3917: Validity of allocator&lt;void&gt; and possibly polymorphic_allocator&lt;void&gt; should be clarified</title>
<meta property="og:title" content="Issue 3917: Validity of allocator&lt;void&gt; and possibly polymorphic_allocator&lt;void&gt; should be clarified">
<meta property="og:description" content="C++ library issue. Status: New">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue3917.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#New">New</a> status.</em></p>
<h3 id="3917"><a href="lwg-active.html#3917">3917</a>. Validity of <code>allocator&lt;void&gt;</code> and possibly <code>polymorphic_allocator&lt;void&gt;</code> should be clarified</h3>
<p><b>Section:</b> 20.2.10 <a href="https://wg21.link/default.allocator">[default.allocator]</a>, 20.5.3 <a href="https://wg21.link/mem.poly.allocator.class">[mem.poly.allocator.class]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2023-04-08 <b>Last modified:</b> 2023-05-24</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#default.allocator">active issues</a> in [default.allocator].</p>
<p><b>View all other</b> <a href="lwg-index.html#default.allocator">issues</a> in [default.allocator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Before <a href="https://wg21.link/P0174" title=" Deprecating Vestigial Library Parts in C++17">P0174</a> had been approved for the working paper, the validity of using <code>void</code> as template argument for
<code>std::allocator</code> was obvious due to the existing specification of the explicit specialization <code>allocator&lt;void&gt;</code>.
<p/>
This specialization was first moved to Annex D ([depr.default.allocator]) and later completely eradicated from the working paper via
adoption of <a href="https://wg21.link/P0619" title=" Reviewing Deprecated Facilities of C++17 for C++20">P0619</a>.
<p/>
The problem is that, since then, we have no explicit wording for <code>std::allocator</code> to support <code>void</code> as template argument 
any more. We fall now under the constraints for template "components" specified in 16.4.5.8 <a href="https://wg21.link/res.on.functions">[res.on.functions]</a> bullet 2.5.
</p>
<blockquote><p>
-2- In particular, the behavior is undefined in the following cases:
</p>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(2.5) &mdash; If an incomplete type (6.9.1 <a href="https://wg21.link/basic.types.general">[basic.types.general]</a>) is used as a template argument when instantiating a 
template component or evaluating a concept, unless specifically allowed for that component.</p></li>
</ol>
</blockquote>
<p>
But no such allowance wording exists for <code>allocator&lt;void&gt;</code> nor for <code>polymorphic_allocator&lt;void&gt;</code>, more
to the contrary, 16.4.4.6.1 <a href="https://wg21.link/allocator.requirements.general">[allocator.requirements.general]</a> only refers to <i>cv</i>-unqualified object types as value types
and <code>void</code> is not an object type.
<p/>
Now we could argue that the wording is clear that instantiations of these are invalid, but there exists at least some indication
that the instantiations are intended to be allowed.
<p/>
As of 25.8.5 <a href="https://wg21.link/coro.generator.promise">[coro.generator.promise]</a> bullet (17.3) the static <code>operator new</code> members of <code>std::generator</code>
mention a fall-back of using <code>allocator&lt;void&gt;</code>.
<p/>
20.2.10.1 <a href="https://wg21.link/default.allocator.general">[default.allocator.general]</a> says that all specializations of the default allocator meet the allocator completeness 
requirements (16.4.4.6.2 <a href="https://wg21.link/allocator.requirements.completeness">[allocator.requirements.completeness]</a>), but albeit this specification does not specifically exclude 
the existence of an incomplete value type, the wording here does also not provide a definite statement, that it is valid (The 
wording originally was provided when we started adding support for (yet) incomplete value types that at some point later will become
complete, but <code>void</code> can never be completed), since it is mostly focused on the completeness requirement for the allocator
type itself.
<p/>
The situation is similar (albeit maybe not that strong) for <code>polymorphic_allocator&lt;void&gt;</code>, since
20.5.3 <a href="https://wg21.link/mem.poly.allocator.class">[mem.poly.allocator.class]</a> p1 has some unusual wording form that says
</p>
<blockquote><p>
-1- A specialization of class template <code>pmr::polymorphic_allocator</code> meets the <i>Cpp17Allocator</i> requirements
(16.4.4.6.1 <a href="https://wg21.link/allocator.requirements.general">[allocator.requirements.general]</a>) if its template argument is a <i>cv</i>-unqualified object type.
</p></blockquote>
<p>
and says then in p2:
</p>
<blockquote><p>
-2- A specialization of class template <code>pmr::polymorphic_allocator</code> meets the allocator completeness requirements
(16.4.4.6.2 <a href="https://wg21.link/allocator.requirements.completeness">[allocator.requirements.completeness]</a>) if its template argument is a <i>cv</i>-unqualified object type.
</p></blockquote>
<p>
Again, this wording is not conclusive, whether <code>void</code> is intended to be supported, it is certainly not completely ruled
out, but that is not strong enough to counterpart 16.4.5.8 <a href="https://wg21.link/res.on.functions">[res.on.functions]</a> (2.5). It is maybe worth pointing out that
for a while we were considering to use <code>void</code> as default template argument for <code>pmr::polymorphic_allocator</code>,
see e.g. <a href="https://wg21.link/P0339R0" title=" polymorphic_allocator<void> as a vocabulary type">P0339R0</a>, but that thought was later replaced by deciding for <code>std::byte</code> instead, which
is a complete object type.
<p/>
I assume that at least the intention exists that <code>std::allocator</code> is intended to support incomplete types, maybe also
for <code>polymorphic_allocator</code>. If <code>polymorphic_allocator</code> is intended to support incomplete types as well,
we should also amend 20.5.3.3 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> p1 and p8 with a <i>Mandates:</i> element similarly as we did 
for <code>std::allocator</code> via LWG <a href="lwg-defects.html#3307" title="std::allocator&lt;void&gt;().allocate(n) (Status: C++20)">3307</a><sup><a href="https://cplusplus.github.io/LWG/issue3307" title="Latest snapshot">(i)</a></sup>.
</p>

<p><i>[2023-05-24; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll.
</p>



<p id="res-3917"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4944" title=" Working Draft, Standard for Programming Language C++">N4944</a>.
</p>

<ol>
<li>
<p>Add the following new paragraph at the end of 20.2.10.1 <a href="https://wg21.link/default.allocator.general">[default.allocator.general]</a> as indicated:</p>

<blockquote>
<p>
-2- <code>allocator_traits&lt;allocator&lt;T&gt;&gt;::is_always_equal::value</code> is <code>true</code> for any <code>T</code>.
<p/>
<ins>-?- The template parameter <code>T</code> of <code>allocator</code> may be an incomplete type.</ins>
</p>
</blockquote>
</li>

<li>
<p>Add the following new paragraph at the end of 20.5.3.1 <a href="https://wg21.link/mem.poly.allocator.class.general">[mem.poly.allocator.class.general]</a> (possibly just after
the class template synopsis) as indicated:</p>

<blockquote>
<p>
<ins>-?- The template parameter <code>Tp</code> of <code>polymorphic_allocator</code> may be an incomplete type.</ins>
</p>
</blockquote>
</li>

<li>
<p>Modify 20.5.3.3 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The reference to <code>sizeof(Tp)</code> gives indirect evidence that we want to exclude incomplete types
here, but we cannot rely on the "equivalent to" magic formula, because that is defined conditionally]
</p>
</blockquote>

<blockquote>
<pre>
[[nodiscard]] Tp* allocate(size_t n);
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <code>Tp</code> is not an incomplete type (6.9.1 <a href="https://wg21.link/basic.types.general">[basic.types.general]</a>).</ins>
<p/>
-1- <i>Effects:</i> If <code>numeric_limits&lt;size_t&gt;::max() / sizeof(Tp) &lt; n</code>, throws <code>bad_array_new_length</code>.
Otherwise equivalent to:
</p>
<blockquote><pre>
return static_cast&lt;Tp*&gt;(memory_rsrc-&gt;allocate(n * sizeof(Tp), alignof(Tp)));
</pre></blockquote>
</blockquote>

<blockquote class="note">
<p>
[<i>Drafting note:</i> We don't need extra wording for the member templates <code>allocate_object</code>, <code>deallocate_object</code>,
<code>new_object</code>, <code>delete_object</code>, or <code>construct</code>, because their semantics does not depend on template parameter
<code>Tp</code> and the general wording of 16.4.5.8 <a href="https://wg21.link/res.on.functions">[res.on.functions]</a> (2.5) again requires the completeness of <code>T</code> here.
<p/>
For <code>deallocate</code> we also omit the completeness requirement (as we did so for <code>allocator::deallocate</code>), because 
this is indirectly implied by the existing precondition. ]
</p>
</blockquote>

</blockquote>
</li>
</ol>





</body>
</html>
