<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 96: Vector&lt;bool&gt; is not a container</title>
<meta property="og:title" content="Issue 96: Vector&lt;bool&gt; is not a container">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue96.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#NAD">NAD</a> status.</em></p>
<h3 id="96"><a href="lwg-closed.html#96">96</a>. Vector&lt;bool&gt; is not a container</h3>
<p><b>Section:</b> 23.3.13 <a href="https://wg21.link/vector">[vector]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <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#vector">issues</a> in [vector].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p><code>vector&lt;bool&gt;</code> is not a container as its reference and
pointer types are not references and pointers. </p>

<p>Also it forces everyone to have a space optimization instead of a
speed one.</p>

<p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
Nonconforming, Forces Optimization Choice.</p>

<p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>


<p><i>[In Dublin many present felt that failure to meet Container
requirements was a defect. There was disagreement as to whether
or not the optimization requirements constituted a defect.]</i></p>


<p><i>[The LWG looked at the following resolutions in some detail:
<br/>
&nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br/>
&nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
Container requirements.<br/>
&nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br/>
&nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
vector&lt;bool&gt; would meet.<br/>
&nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br/>
<br/>
No alternative had strong, wide-spread, support and every alternative
had at least one &quot;over my dead body&quot; response.<br/>
<br/>
There was also mention of a transition scheme something like (1) add
vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
Remove vector&lt;bool&gt; in the following standard.]</i></p>


<p><i>[Modifying container requirements to permit returning proxies
(thus allowing container requirements conforming vector&lt;bool&gt;)
was also discussed.]</i></p>


<p><i>[It was also noted that there is a partial but ugly workaround in
that vector&lt;bool&gt; may be further specialized with a customer
allocator.]</i></p>


<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
<code>vector&lt;bool&gt;</code>: More Problems, Better Solutions. Much discussion
of a two step approach: a) deprecate, b) provide replacement under a
new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
my dead body.  This resolution was mentioned in the LWG report to the
full committee, where several additional committee members indicated
over-my-dead-body positions.]</i></p>


<p>Discussed at Lillehammer.  General agreement that we should
  deprecate <code>vector&lt;bool&gt;</code> and introduce this functionality under
  a different name, e.g. <code>bit_vector</code>.  This might make it possible to
  remove the <code>vector&lt;bool&gt;</code> specialization in the standard that comes
  after C++0x. There was also a suggestion that
  in C++0x we could additional say that it's implementation defined
  whether <code>vector&lt;bool&gt;</code> refers to the specialization or to the
  primary template, but there wasn't general agreement that this was a
  good idea.</p>

<p>We need a paper for the new <code>bit_vector</code> class.</p>

<p><i>[
Batavia:
]</i></p>

<blockquote><p>
The LWG feels we need something closer to SGI's <code>bitvector</code> to ease migration
from <code>vector&lt;bool&gt;</code>.  Although some of the funcitonality from
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
could well be used in such a template.  The concern is easing the API migration for those
users who want to continue using a bit-packed container.  Alan and Beman to work.
</p></blockquote>

<p><i>[
Post Summit Alisdair adds:
]</i></p>


<blockquote>
<p>
<code>vector&lt;bool&gt;</code> is now a conforming container under the revised terms of C++0x,
which supports containers of proxies.
</p>
<p>
Recommend NAD.
</p>
<p>
Two issues remain:
</p>
<p>
i/ premature optimization in the specification.
There is still some sentiment that deprecation is the correct way to go,
although it is still not clear what it would mean to deprecate a single
specialization of a template.
</p>
<p>
Recommend: Create a new issue for the discussion, leave as Open.
</p>
<p>
ii/ Request for a new bitvector class to guarantee the optimization, perhaps
with a better tuned interface.
</p>
<p>
This is a clear extension request that may be handled via a future TR.
</p>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote><p>
We note that most of this issue has become moot over time,
and agree with Alisdair's recommendations.
Move to NAD Future for reconsideration of part (ii).
</p></blockquote>

<p><i>[
2009-07-29 Alisdair reopens:
]</i></p>


<blockquote>
<p>
This infamous issue was closed as NAD Future when concepts introduced
support for proxy iterators, so the only remaining requirement was to
provide a better type to support bitsets of dynamic length.  I fear we
must re-open this issue until the post-concept form of iterators is
available, and hopefully will support the necessary proxy functionality
to allow us to close this issue as NAD.
</p>

<p>
I recommend we spawn a separate issue (<a href="lwg-closed.html#1184" title="Feature request: dynamic bitset (Status: NAD)">1184</a><sup><a href="https://cplusplus.github.io/LWG/issue1184" title="Latest snapshot">(i)</a></sup>) requesting a dynamic length bitset
and pre-emptively file it as NAD Future.  It is difficult to resolve #96
when it effectively contains two separate sub-issues.
</p>
</blockquote>

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


<blockquote><p>
Mark as NAD, and give rationale.
</p></blockquote>



<p id="res-96"><b>Proposed resolution:</b></p>
<p>
We now have:
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
</p>



<p><b>Rationale:</b></p>
<p>
We want to support proxy iterators but that is going to be separate
work. Don't want to see this issue come back in these kinds of terms.
We're interested in a separate container, and proxy iterators, but both
of those are separate issues.
</p>
<p>
We've looked at a lot of ways to fix this that would be close to this,
but those things would break existing code. Attempts to fix this
directly have not been tractable, and removing it has not been
tractable. Therefore we are closing.
</p>





</body>
</html>
