<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 1075: Scoped allocators are too complex</title>
<meta property="og:title" content="Issue 1075: Scoped allocators are too complex">
<meta property="og:description" content="C++ library issue. Status: Resolved">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue1075.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#Resolved">Resolved</a> status.</em></p>
<h3 id="1075"><a href="lwg-defects.html#1075">1075</a>. Scoped allocators are too complex</h3>
<p><b>Section:</b> 22 <a href="https://wg21.link/utilities">[utilities]</a>, 23 <a href="https://wg21.link/containers">[containers]</a> <b>Status:</b> <a href="lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#utilities">issues</a> in [utilities].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US 65 and US 74.1 [CD1]</b></p>

<p>US 65:</p>

<blockquote><p>
Scoped allocators and allocator propagation traits add a small amount of
utility at the cost of a great deal of machinery. The machinery is user
visible, and it extends to library components that don't have any
obvious connection to allocators, including basic concepts and simple
components like <code>pair</code> and <code>tuple</code>.
</p>

<p>Suggested resolution:</p>

<p>
Sketch of proposed resolution: Eliminate scoped allocators, replace
allocator propagation traits with a simple uniform rule (e.g. always
propagate on copy and move), remove all mention of allocators from
components that don't explicitly allocate memory (e.g. pair), and adjust
container interfaces to reflect this simplification.
</p>
<p>
Components that I propose eliminating include <code>HasAllocatorType</code>,
<code>is_scoped_allocator</code>, <code>allocator_propagation_map</code>, <code>scoped_allocator_adaptor</code>,
and <code>ConstructibleAsElement</code>.
</p>
</blockquote>

<p>US 74.1:</p>

<blockquote>
<p>
Scoped allocators represent a poor trade-off for standardization, since
(1) scoped-allocator--aware containers can be implemented outside the
C++ standard library but used with its algorithms, (2) scoped
allocators only benefit a tiny proportion of the C++ community
(since few C++ programmers even use today's allocators), and (3) all C++
users, especially the vast majority of the C++ community that won't ever
use scoped allocators are forced to cope with the interface complexity
introduced by scoped allocators.
</p>
<p>
In essence, the larger community will suffer to support a very small
subset of the community who can already implement their own
data structures outside of the standard library. Therefore, scoped
allocators should be removed from the working paper.
</p>
<p>
Some evidence of the complexity introduced by scoped allocators:
</p>
<blockquote>
<p>
22.3 <a href="https://wg21.link/pairs">[pairs]</a>, 22.4 <a href="https://wg21.link/tuple">[tuple]</a>: Large increase in the
number of pair and tuple constructors.
</p>
<p>
23 <a href="https://wg21.link/containers">[containers]</a>: Confusing "AllocatableElement" requirements throughout.
</p>
</blockquote>
<p>Suggested resolution:</p>

<p>
Remove support for scoped allocators from the working paper. This
includes at least the following changes:
</p>

<blockquote>
<p>
Remove 99 [allocator.element.concepts]
</p>
<p>
Remove 20.6 <a href="https://wg21.link/allocator.adaptor">[allocator.adaptor]</a>
</p>
<p>
Remove  [construct.element]
</p>
<p>
In Clause 23 <a href="https://wg21.link/containers">[containers]</a>: replace requirements naming the
<code>AllocatableElement</code> concept with requirements naming <code>CopyConstructible</code>,
<code>MoveConstructible</code>, <code>DefaultConstructible</code>, or <code>Constructible</code>, as
appropriate.
</p>
</blockquote>

</blockquote>

<p><i>[
Post Summit Alan moved from NAD to Open.
]</i></p>


<p><i>[
2009-05-15 Ganesh adds:
]</i></p>


<blockquote>
<p>
The requirement <code>AllocatableElement</code> should not be replaced with
<code>Constructible</code> on the <code>emplace_xxx()</code> functions as suggested. In the
one-parameter case the <code>Constructible</code> requirement is not satisfied when
the constructor is explicit (as per  [concept.map.fct], twelfth
bullet) but we do want to allow explicit constructors in emplace, as the
following example shows:
</p>

<blockquote><pre>
vector&lt;shared_ptr&lt;int&gt;&gt; v;
v.emplace_back(new int); <span style="color:#C80000">// should be allowed</span>
</pre></blockquote>

<p>
If the issue is accepted and scoped allocators are removed, I suggest to
add a new pair of concepts to  [concept.construct], namely:
</p>

<blockquote><pre>
auto concept HasExplicitConstructor&lt;typename T, typename... Args&gt; {
 explicit T::T(Args...);
}

auto concept ExplicitConstructible&lt;typename T, typename... Args&gt;
 : HasExplicitConstructor&lt;T, Args...&gt;, NothrowDestructible&lt;T&gt;
{ }
</pre></blockquote>

<p>
We should then use <code>ExplicitConstructible</code> as the requirement for all
<code>emplace_xxx()</code> member functions.
</p>
<p>
For coherence and consistency with the similar concepts
<code>Convertible/ExplicitlyConvertible</code>, we might also consider changing
<code>Constructible</code> to:
</p>

<blockquote><pre>
auto concept Constructible&lt;typename T, typename... Args&gt;
 : HasConstructor&lt;T, Args...&gt;, ExplicitConstructible&lt;T, Args...&gt;
{ }
</pre></blockquote>

<p>
Moreover, all emplace-related concepts in  [container.concepts]
should also use <code>ExplicitConstructible</code> instead of <code>Constructible</code> in the
definitions of their axioms. In fact the concepts in  [container.concepts] should be
corrected even if the issue is not accepted.
</p>
<p>
On the other hand, if the issue is not accepted, the scoped allocator
adaptors should be fixed because the following code:
</p>

<blockquote><pre>
template &lt;typename T&gt; using scoped_allocator = scoped_allocator_adaptor&lt;allocator&lt;T&gt;&gt;;

vector&lt;shared_ptr&lt;int&gt;, scoped_allocator&lt;shared_ptr&lt;int&gt;&gt;&gt; v;
v.emplace_back(new int); <span style="color:#C80000">// ops! doesn't compile</span>
</pre></blockquote>

<p>
doesn't compile, as the member function <code>construct()</code> of the scoped
allocator requires non-explicit constructors through concept
<code>ConstructibleWithAllocator</code>. Fixing that is not difficult but probably
more work than it's worth and is therefore, IMHO, one more reason in
support of the complete removal of scoped allocators.
</p>
</blockquote>

<p><i>[
2009-06-09 Alan adds:
]</i></p>


<blockquote>
<p>
I reopened this issue because I did not think that these National Body
comments were adequately addressed by marking them NAD. My understanding
is that something can be marked NAD if it is clearly a misunderstanding
or trivial, but a substantive issue that has any technical merit
requires a disposition that addresses the concerns.
</p>
<p>
The notes in the NB comment list (US 65 &amp; US 74.1) say that:
</p>
<ol style="list-style-type:lower-alpha">
<li>
this issue has not introduced any new arguments not previously discussed,
</li>
<li>
the vote (4-9-3) was not a consensus for removing scoped allocators,
</li>
<li>
the issue is resolved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>.
</li>
</ol>
<p>
My opinion is:
</p>
<ol style="list-style-type:lower-alpha">
<li>
there are new arguments in both comments regarding concepts (which were
not present in the library when the scoped allocator proposal was voted
in),
</li>
<li>
the vote was clearly not a consensus for removal, but just saying there
was a vote does not provide a rationale,
</li>
<li>
I do not believe that N2840 addresses these comments (although it does
many other things and was voted in with strong approval).
</li>
</ol>

<p>
My motivation to open the issue was to ensure that the NB comments were
adequately addressed in a way that would not risk a "no" vote on our
FCD. If there are responses to the technical concerns raised, then
perhaps they should be recorded. If the members of the NB who authored
the comments are satisfied with N2840 and the other disposition remarks
in the comment list, then I am sure they will say so. In either case,
this issue can be closed very quickly in Frankfurt, and hopefully will
have helped make us more confident of approval with little effort. If in
fact there is controversy, my thought is that it is better to know now
rather than later so there is more time to deal with it.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote><p>
<del>NAD Editorial</del><ins>Resolved</ins>.  Addressed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
</p></blockquote>



<p id="res-1075"><b>Proposed resolution:</b></p>


<p><b>Rationale:</b></p>
<p>
Scoped allocators have been revised significantly.
</p>





</body>
</html>
