<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Library Issues Resolved Directly In [INSERT CURRENT MEETING HERE]</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  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}
</style>
</head>
<body>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">N3930</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left">2014-02-14</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Programming Language C++</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table> 
<h2>Immediate Issues</h2>
<hr>
<h3><a name="1450"></a>1450. Contradiction in <tt>regex_constants</tt></h3>
<p><b>Section:</b> 28.5.2 [re.matchflag] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2014-02-13</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-127</b></p>

<p>
The Bitmask Type requirements in 17.5.2.1.3 [bitmask.types] p.3 say that
all elements on a bitmask type have distinct values, but
28.5.2 [re.matchflag] defines <tt>regex_constants::match_default</tt> and
<tt>regex_constants::format_default</tt> as elements of the
bitmask type <tt>regex_constants::match_flag_type</tt>, both with
value 0. This is a contradiction.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote><p>
One of the bitmask elements should be removed
from the declaration and should be defined
separately, in the same manner as
<tt>ios_base::adjustfield</tt>, <tt>ios_base::basefield</tt> and
<tt>ios_base::floatfield</tt> are defined by 27.5.3.1.2 [ios::fmtflags] p.2
and Table 120. These are constants of a bitmask
type, but are not distinct elements, they have
more than one value set in the bitmask.
<tt>regex_constants::format_default</tt> should be
specified as a constant with the same value as
<tt>regex_constants::match_default</tt>.
</p></blockquote>

<p><i>[
2010-10-31 Daniel comments:
]</i></p>

<p>
Strictly speaking, a bitmask type cannot have any element of value 0 at all, because
any such value would contradict the requirement expressed in 17.5.2.1.3 [bitmask.types] p. 3:
</p>
<blockquote><p>
for any pair <em>Ci</em> and <em>Cj</em>, <em>Ci</em> &amp; <em>Ci</em> is nonzero
</p></blockquote>
<p>
So, actually <em>both</em> <tt>regex_constants::match_default</tt> and
<tt>regex_constants::format_default</tt> are only constants of the type
<tt>regex_constants::match_flag_type</tt>, and no bitmask elements.
</p>

<p><i>[
2010-11-03 Daniel comments and provides a proposed resolution:
]</i></p>


<p>The proposed resolution is written against N3126 and considered as a further improvement
of the fixes suggested by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>.
</p>

<blockquote>
<p>
Add the following sentence to 28.5.2 [re.matchflag]  paragraph 1:
</p>
<blockquote><p>
1 The type <tt>regex_constants::match_flag_type</tt> is an implementation-defined bitmask type (17.5.2.1.3).
Matching a regular expression against a sequence of characters [first,last) proceeds according to the
rules of the grammar specified for the regular expression object, modified according to the effects listed in
Table 136 for any bitmask elements set. <ins>Type <tt>regex_constants::match_flag_type</tt> also defines the 
constants <tt>regex_constants::match_default</tt> and <tt>regex_constants::format_default</tt>.</ins>
</p></blockquote>
</blockquote>

<p><i>[
2011 Bloomington
]</i></p>


<p>
It appears the key problem is the phrasing of the bitmask requirements.  Jeremiah supplies updated wording.
</p>

<p>
Pete Becker has also provided an alternative resolution.
</p>

<p>
Ammend 17.5.2.1.3 [bitmask.types]:
</p>
<p>
Change the list of values for "enum bit mask" in p2 from
</p>
<p>
<tt><i>V0</i> = 1 &lt;&lt; 0, <i>V1</i> = 1 &lt;&lt; 1, <i>V2</i> = 1 &lt;&lt; 2, <i>V3</i> = 1 &lt;&lt; 3, ...</tt>.
</p>
<p>
to
</p>
<p>
<tt><i>V0</i> = 0, <i>V1</i> = 1 &lt;&lt; 0, <i>V2</i> = 1 &lt;&lt; 1, <i>V3</i> = 1 &lt;&lt; 2,  ...</tt>.
</p>
<p>
Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
bitmask type. All such <ins>non-zero</ins> elements have distinct values such that, for any pair
<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i></ins>, <del><i>Ci &amp; Ci</i> is nonzero
and</del> <i>Ci &amp; Cj</i> is zero.
</p>
<p>
Change bullet 3 of paragraph 4:
</p>
<p>
<del>The</del><ins>A non-zero</ins> value Y is set in the object X if the expression X &amp; Y is nonzero.
</p>

<p><i>[2014-02-13 Issaquah:]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Ammend 17.5.2.1.3 [bitmask.types] p3:
</p>
<p>
Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
bitmask type. All such elements have distinct<ins>, nonzero</ins> values such that, for any pair
<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i>,</ins> <i>Ci &amp; Ci</i> is nonzero
and <i>Ci &amp; Cj</i> is zero. <ins>Additionally, the value 0 is used to represent an
<i>empty bitmask</i>, in which no bitmask elements are set.</ins>
</p>

<p>
Add the following sentence to 28.5.2 [re.matchflag]  paragraph 1:
</p>
<blockquote><p>
1 The type <tt>regex_constants::match_flag_type</tt> is an implementation-defined bitmask type (17.5.2.1.3).
<ins>The constants of that type, except for <tt>match_default</tt> and <tt>format_default</tt>, are bitmask
elements. The <tt>match_default</tt> and <tt>format_default</tt> constants are empty bitmasks.</ins> Matching
a regular expression against a sequence of characters [first,last) proceeds according to the rules of the
grammar specified for the regular expression object, modified according to the effects listed in Table 136
for any bitmask elements set.
</p></blockquote>





<hr>
<h3><a name="2003"></a>2003. String exception inconsistency in erase.</h3>
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jos&eacute; Daniel Garc&iacute;a S&aacute;nchez <b>Opened:</b> 2010-10-21 <b>Last modified:</b> 2014-02-14</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.require">active issues</a> in [string.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#string.require">issues</a> in [string.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Clause 21.4.1 [string.require]p3 states:
</p>
<blockquote><p>
No <tt>erase()</tt> or <tt>pop_back()</tt> member function shall throw
any exceptions.
</p></blockquote>
<p>
However in 21.4.6.5 [string::erase] p2 the first version of <tt>erase</tt> has
</p>
<blockquote><p>
<i>Throws</i>: <tt>out_of_range</tt> if <tt>pos > size()</tt>.
</p></blockquote>

<p><i>[2011-03-24 Madrid meeting]</i></p>


<p>
Beman: Don't want to just change this, can we just say "unless otherwise specified"?
<p/>
Alisdair: Leave open, but update proposed resolution to say something like "unless otherwise specified".
<p/>
General agreement that it should be corrected but not a stop-ship.
<p/>
Action: Update proposed wording for issue 2003 as above, but leave Open. 
</p>

<p><i>[2014-02-12 Issaquah meeting]</i></p>


<p>
Jeffrey: Madrid meeting's proposed wording wasn't applied, and it's better than the original proposed wording.
However, this sentence is only doing 3 functions' worth of work, unlike the similar paragraphs in 23.2.1 [container.requirements.general].
Suggest just putting "<i>Throws:</i> Nothing" on the 3 functions.
</p>

<p><i>[2014-02-13 Issaquah meeting]</i></p>

<p>
Move as Immmediate
</p>



<p><b>Proposed resolution:</b></p>
<p>
Remove [string.require]p/3:
</p>
<blockquote><p>
<del>3 No <tt>erase()</tt> or <tt>pop_back()</tt> member function shall throw any exceptions.</del>
</p></blockquote>

<p>
Add to the specifications of <tt>iterator erase(const_iterator p);</tt>, <tt>iterator erase(const_iterator first, const_iterator last);</tt>,
 and <tt>void pop_back();</tt> in 21.4.6.5 [string::erase]:
</p>
<blockquote><p><ins><i>Throws:</i> Nothing</ins></p></blockquote>





<hr>
<h3><a name="2104"></a>2104. <tt>unique_lock</tt> move-assignment should not be <tt>noexcept</tt></h3>
<p><b>Section:</b> 30.4.2.2 [thread.lock.unique] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2011-11-27 <b>Last modified:</b> 2014-02-14</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
I just noticed that the <tt>unique_lock</tt> move-assignment operator is declared <tt>noexcept</tt>. This 
function may call <tt>unlock()</tt> on the wrapped mutex, which may throw.
<p/>
Suggested change: remove the <tt>noexcept</tt> specification from <tt>unique_lock::operator=(unique_lock&amp;&amp;)</tt> 
in 30.4.2.2 [thread.lock.unique] and 30.4.2.2.1 [thread.lock.unique.cons]. 
<p/>
Daniel:
<p/>
I think the situation is actually a bit more complex as it initially looks.
<p/>
First, the effects of the move-assignment operator are (emphasize mine):
</p>
<blockquote><p>
<i>Effects</i>: <strong>If</strong> <tt>owns</tt> calls <tt>pm->unlock()</tt>.
</p></blockquote>
<p>
Now according to the <tt>BasicLockable</tt> requirements:
</p>
<blockquote><p>
<tt>m.unlock()</tt>
<p/>
3 <i>Requires</i>: The current execution agent shall hold a lock on <tt>m</tt>.
<p/>
4 <i>Effects</i>: Releases a lock on <tt>m</tt> held by the current execution agent.
<p/>
<i>Throws</i>: Nothing.
</p></blockquote>
<p>
This shows that unlock itself is a function with narrow contract and for 
this reasons no unlock function of a mutex or lock itself does have a noexcept 
specifier according to our mental model.
<p/>
Now the move-assignment operator <strong>attempts</strong> to satisfy these
requirement of the function and calls it only when it assumes that the conditions 
are ok, so from the view-point of the caller of the move-assignment operator it 
looks as if the move-assignment operator would in total a function with a
wide contract.
<p/>
The problem with this analysis so far is, that it depends on the assumed 
correctness of the state "owns".
<p/>
Looking at the construction or state-changing functions, there do exist several 
ones that depend on caller-code satisfying the requirements and there is one 
guy, who looks most suspicious:
</p>
<blockquote><p>
<tt>unique_lock(mutex_type&amp; m, adopt_lock_t);</tt>
<p/>
11 <i>Requires</i>: The calling thread own the mutex.<br/>
[&hellip;]<br/>
13 <i>Postconditions</i>: <tt>pm == &amp;m</tt> and <tt>owns == true</tt>.<br/>
</p></blockquote>
<p>
because this function does not even call <tt>lock()</tt> (which may, but is not 
required to throw an exception if the calling thread does already own the mutex). 
So we have in fact still a move-assignment operator that might throw an exception, 
if the mutex was either constructed or used (call of lock) incorrectly.
<p/>
The correct fix seems to me to also add a "<i>Throws</i>: Nothing" element to
the move-assignment operator, because using it correctly shall not throw an
exception.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate after SG1 review]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li>
<p>Change 30.4.2.2 [thread.lock.unique], class template <tt>unique_lock</tt> synopsis as indicated:</p>

<blockquote><pre>
namespace std {
  template &lt;class Mutex&gt;
  class unique_lock {
  public:
    typedef Mutex mutex_type;
    [&hellip;]
    unique_lock(unique_lock&amp;&amp; u) noexcept;
    unique_lock&amp; operator=(unique_lock&amp;&amp; u) <del>noexcept</del>;
    [&hellip;]
  };
}
</pre></blockquote>
</li>

<li>
<p>Change 30.4.2.2.1 [thread.lock.unique.cons] around p22 as indicated:</p>

<blockquote><pre>
unique_lock&amp; operator=(unique_lock&amp;&amp; u) <del>noexcept</del>;
</pre><blockquote>
<p>
-22- <i>Effects</i>: If <tt>owns</tt> calls <tt>pm->unlock()</tt>.
<p/>
-23- <i>Postconditions</i>: <tt>pm == u_p.pm</tt> and <tt>owns == u_p.owns</tt> (where <tt>u_p</tt> 
is the state of <tt>u</tt> just prior to this construction), <tt>u.pm == 0</tt> and <tt>u.owns == false</tt>.
<p/>
-24- [<i>Note</i>: With a recursive mutex it is possible for both <tt>*this</tt> and <tt>u</tt> to own 
the same mutex before the assignment. In this case, <tt>*this</tt> will own the mutex after the assignment 
and <tt>u</tt> will not. &mdash; <i>end note</i>]
</p>
<ins>-??- <i>Throws</i>: Nothing.</ins>
<p/>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2112"></a>2112. User-defined classes that cannot be derived from</h3>
<p><b>Section:</b> 17.6.5 [conforming], 20.7.8 [allocator.traits], 20.13.1 [allocator.adaptor.syn] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-11-30 <b>Last modified:</b> 2014-02-14</p>
<p><b>View all other</b> <a href="lwg-index.html#conforming">issues</a> in [conforming].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
It is a very established technique for implementations to derive internally from user-defined class types that are
used to customize some library component, e.g. deleters and allocators are typical candidates. The advantage of this
approach is to possibly take advantage of the empty-base-class optimization (EBCO).
<p/>
Whether or whether not libraries did take advantage of such a detail didn't much matter in C++03. Even though there
did exist a portable idiom to prevent that a class type could be derived from, this idiom has never reached great
popularity: The <a href="http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Final_Class">technique</a> required
to introduce a virtual base class and it did not really prevent the derivation, but only any construction of
such a type. Further, such types are not <em>empty</em> as defined by the <tt>std::is_empty</tt> trait, so
could easily be detected by implementations from TR1 on.
<p/>
With the new C++11 feature of final classes and final member functions it is now very easy to define an empty,
but not derivable from class type. From the point of the user it is quite natural to use this feature for
types that he or she did not foresee to be derivable from.
<p/>
On the other hand, most library implementations (including third-party libraries) often take advantage of EBCO 
applied to user-defined types used to instantiate library templates internally. As the time of submitting this 
issue the following program failed to compile on all tested library implementations:
</p>
<blockquote><pre>
#include &lt;memory&gt;

struct Noop <span style="color:#C80000;font-weight:bold">final</span> {
 template&lt;class Ptr&gt;
 void operator()(Ptr) const {}
};

std::unique_ptr&lt;int, Noop&gt; up;
</pre></blockquote>
<p>
In addition, many <tt>std::tuple</tt> implementations with empty, final classes as element types failed as well, 
due to a popular inheritance-based implementation technique. EBCO has also a long tradition to be 
used in library containers to efficiently store potentially stateless, empty allocators.
<p/>
It seems that both user and library did the best they could: None of the affected types did impose explicit
requirements on the corresponding user-defined types to be derivable from (This capability was not part of
the required operations), and libraries did apply EBCO whereever possible to the convenience of the customer.
<p/>
Nonetheless given the existence of non-derivable-from class types in C++11, libraries have to cope with
failing derivations. How should that problem be solved?
<p/>
It would certainly be possible to add weazel wording to the allocator requirements similar to what we had
in C++03, but restricted to derivation-from requirements. I consider this as the bad solution, because it
would add new requirements that never had existed before in this explicit form onto types like allocators.
<p/>
Existing libraries presumably will need internal traits like <tt>__is_final</tt> or <tt>__is_derivable</tt>
to make EBCO possible in the current form but excluding non-derivable class types. As of this writing this
seems to happen already. Problem is that without a <tt>std::is_derivable</tt> trait, third-party libraries
have no portable means to do the same thing as standard library implementations. This should be a good 
reason to make such a trait public available soon, but seems not essential to have now. Further, this issue
should also be considered as a chance to recognice that EBCO has always been a very special corner case
(There exist parallels to the previously existing odd core language rule that did make the interplay 
between <tt>std::auto_ptr</tt> and <tt>std::auto_ptr_ref</tt> possible) and that it would be better to
provide explicit means for space-efficient storage, not necessarily restricted to inheritance relations, 
e.g. by marking data members with a special attribute.
<p/>
At least two descriptions in the current standard should be fixed now for better clarification:
</p>
<ol>
<li><p>As mentioned by Ganesh, 20.7.8 [allocator.traits] p1 currently contains a (non-normative) note
"Thus, it is always possible to create a derived class from an allocator." which should be removed.
</p>
</li>
<li><p>As pointed out by Howard, the specification of <tt>scoped_allocator_adaptor</tt> as of
20.13.1 [allocator.adaptor.syn] already requires derivation from <tt>OuterAlloc</tt>, but 
only implies indirectly the same for the inner allocators due to the <em>exposition-only</em> 
description of member <tt>inner</tt>. This indirect implication should be normatively required for 
all participating allocators.
</p></li>
</ol>


<p><i>[2012, Kona]</i></p>

<p>
What we really need is a type trait to indicate if a type can be derived from.  Howard reports
Clang and libc++ have had success with this approach.
</p>
<p>
Howard to provide wording, and AJM to alert Core that we may be wanting to add a new trait
that requires compiler support.
</p>

<p><i>[2014-02, Issaquah: Howard and Daniel comment and provide wording]</i></p>


<p>
Several existing C++11 compilers do already provide an internal <tt>__is_final</tt> intrinsic (e.g. clang and gcc) and therefore 
we believe that this is evidence enough that this feature is implementable today.
<p/>
We believe that both a simple and clear definition of the <tt>is_final</tt> query should result in a true outcome 
if and only if the current existing language definition holds that a complete class type (either union or non-union) 
has been marked with the <i>class-virt-specifier</i> <code>final</code> &mdash; nothing more.
<p/>
The following guidelines lead to the design decision and the wording choice given below:
<p/>
It has been expressed several times that a high-level trait such as "<tt>is_derivable</tt>" would be preferred and
would be more useful for non-experts. One problem with that request is that it is astonishingly hard to find a common denominator 
for what the <em>precise</em> definition of this trait should be, especially regarding corner-cases. Another example of getting very 
differing points of view is to ask a bunch of C++ experts what the best definition of the <tt>is_empty</tt> trait
should be (which can be considered as a kind of higher-level trait).
<p/>
Once we have a fundamental trait like <tt>is_final</tt> available, we can easily define higher-level traits in the future
on top of this by a proper logical combination of the low-level traits.
<p/>
A critical question is whether providing such a low-level compile-time introspection might be considered as disadvantageous,
because it could constrain the freedom of existing implementations even further and whether a high-level trait would solve
this dilemma. We assert that since C++11 the static introspection capabilities are already very large and we believe that
making the presence or absence of the <tt>final</tt> keyword testable does not make the current situation worse.
<p/>
Below code example demonstrates the intention and the implementability of this feature:
</p>
<blockquote><pre>
#include &lt;type_traits&gt;

namespace std
{

template &lt;class T&gt;
struct is_final
  : public integral_constant&lt;bool, __is_final(T)&gt;
{};

}  // std

// test it

union FinalUnion <span style="color:#009900;font-weight:bolder">final</span> { };

union NonFinalUnion { };

class FinalClass <span style="color:#009900;font-weight:bolder">final</span> { };

struct NonFinalClass { };

class Incomplete;

int main()
{
  using std::is_final;
  static_assert( is_final&lt;const volatile FinalUnion&gt;{}, "");
  static_assert(!is_final&lt;FinalUnion[]&gt;{}, "");
  static_assert(!is_final&lt;FinalUnion[1]&gt;{}, "");
  static_assert(!is_final&lt;NonFinalUnion>{}, "");
  static_assert( is_final&lt;FinalClass&gt;{}, "");
  static_assert(!is_final&lt;FinalClass&amp;&gt;{}, "");
  static_assert(!is_final&lt;FinalClass*&gt;{}, "");
  static_assert(!is_final&lt;NonFinalClass&gt;{}, "");
  static_assert(!is_final&lt;void&gt;{}, "");
  static_assert(!is_final&lt;int&gt;{}, "");
  static_assert(!is_final&lt;Incomplete&gt;{}, ""); // <span style="color:#C80000;font-weight:bolder">error incomplete type 'Incomplete' used in type trait expression</span>
}
</pre></blockquote>

<p><i>[2014-02-14, Issaquah: Move to Immediate]</i></p>

<p>
This is an important issue, that we really want to solve for C++14.
</p>

<p>
Move to Immediate after polling LEWG, and then the NB heads of delegation.
</p>



<p><b>Proposed resolution:</b></p>

<p>This wording is relative to N3797.</p>

<ol>
<li><p>Change 20.10.2 [meta.type.synop], header <tt>&lt;type_traits&gt;</tt> synopsis, as indicated</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  <i>// 20.10.4.3, type properties:</i>
  [&hellip;]
  template &lt;class T&gt; struct is_empty;
  template &lt;class T&gt; struct is_polymorphic;
  template &lt;class T&gt; struct is_abstract;
  <ins>template &lt;class T&gt; struct is_final;</ins>

  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 20.10.4.3 [meta.unary.prop], Table 49 &mdash; Type property predicates, as indicated</p>

<table border="1">
<caption>Table 49 &mdash; Type property predicates</caption>
<tr>
<th>Template</th>
<th>Condition</th>
<th>Preconditions</th>
</tr> 
<tr>
<td>
<tt>template &lt;class T&gt;</tt><br/>
<tt>struct is_abstract;</tt>
</td>
<td>
[&hellip;]
</td>
<td>
[&hellip;]
</td>
</tr>

<tr>
<td>
<ins><tt>template &lt;class T&gt;</tt><br/>
<tt>struct is_final;</tt></ins>
</td>
<td>
<ins><code>T</code> is a class type marked with the <i>class-virt-specifier</i> <code>final</code> (9 [class]).<br/> 
[<i>Note:</i> A union is a class type that can be marked with <code>final</code>. &mdash; <i>end note</i>]</ins>
</td>
<td>
<ins>If <tt>T</tt> is a class type, <tt>T</tt> shall be a complete type</ins>
</td>
</tr>

</table>

</li>

<li><p>After 20.10.4.3 [meta.unary.prop] p5 add one further example as indicated:</p>

<blockquote><p>
<ins>[<i>Example</i>:</ins>
</p>
<blockquote><pre>
<ins><i>// Given:</i>
struct P final { };
union U1 { };
union U2 final { };

<i>// the following assertions hold:</i>
static_assert(!is_final&lt;int&gt;::value, "Error!");
static_assert( is_final&lt;P&gt;::value, "Error!");
static_assert(!is_final&lt;U1&gt;::value, "Error!");
static_assert( is_final&lt;U2&gt;::value, "Error!");</ins>
</pre></blockquote>
<p>
<ins>&mdash; <i>end example</i>]</ins>
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2132"></a>2132. <tt>std::function</tt> ambiguity</h3>
<p><b>Section:</b> 20.9.11.2.1 [func.wrap.func.con] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2012-02-28 <b>Last modified:</b> 2014-02-14</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following:
</p>
<blockquote><pre>
#include &lt;functional&gt;

void f(std::function&lt;void()&gt;) {}
void f(std::function&lt;void(int)&gt;) {}

int main() {
  f([]{});
  f([](int){});
}
</pre></blockquote>
<p>
The calls to <tt>f</tt> in <tt>main</tt> are ambiguous. Apparently because the
conversion sequences to <tt>std::function</tt> from the lambdas are identical. 
The standard specifies that the function object given to <tt>std::function</tt>
"shall be <em>Callable</em> (20.8.11.2) for argument types <tt>ArgTypes</tt> and 
return type <tt>R</tt>." It doesn't say that if this is not the case, the 
constructor isn't part of the overload set.
<p/>
Daniel: During the preparation of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3123.html">N3123</a>
it turned out that there are no longer reasons to refer to <em>INVOKE</em> as a
conceptually entity alone, its real implementation as a function template <tt>invoke</tt>
is possible but was deferred for a later point in time. Defining a type trait for
the <em>Callable</em> requirement would also be possible, so there seem to be no technical
reasons why the template constructor of <tt>std::function</tt> should not be
constrained. The below suggested wording does this without introducing a special
trait for this. This corresponds to the way that has been used to specify the
<tt>result_of</tt> trait. Note that the definition of the <em>Callable</em>
requirement is perfectly suitable for this, because it is a pure syntactically
based requirement and can be directly transformed into a constrained template.
<p/>
The suggested resolution also applies such wording to the "perfectly forwarding"
assignment operator
</p>
<blockquote><pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp;);
</pre></blockquote>
<p>
The positive side-effect of this is that it automatically implements a solution to
a problem similar to that mentioned in issue <a href="lwg-defects.html#1234">1234</a>.
<p/>
It would be possible to apply similar constraints to the member signatures
</p>
<blockquote><pre>
template&lt;class F&gt; function&amp; operator=(reference_wrapper&lt;F&gt;);

template&lt;class F, class A&gt; void assign(F&amp;&amp;, const A&amp;);
</pre></blockquote>
<p>
as well. At this point there does not seem to be a pestering reason to do so.
</p>

<p><i>[2012-10 Portland: Move to Review]</i></p>

<p>
STL: This is a real issue, but does not like a resolution relying on a SFINAEable metafunction
that is not specified and available to the users.
</p>

<p>
<tt>packaged_task</tt> has the same issue.
</p>

<p>
STL strongly wants to see an <tt>is_callable</tt> type trait to clarify the proposed wording.
</p>

<p>
Jeremiah concerned about holding up what appears to be a correct resolution for a hypothetical
better one later - the issue is real.
</p>

<p>
Why must <tt>f</tt> by CopyConstructible?  Surely MoveConstructible would be sufficient?
</p>

<p>
Answer: because <tt>function</tt> is CopyConstructible, and the bound functor is type-erased
so must support all the properties of <tt>function</tt> itself.
</p>

<p>
Replace various applications of <tt>declval</tt> in the proposed resolution with simply using
the passed functor object, <tt>f</tt>.
</p>

<p>
Alisdair to apply similar changes to <tt>packaged_task</tt>.
</p>

<p><i>[2012-11-09, Vicente J. Botet Escriba provides another example]</i></p>


<p>
Consider the following:
</p>
<blockquote><pre>
class AThreadWrapper {
public:
  explicit operator std::thread();
  ...
};
std::thread th = std::thread(AThreadWrapper); // call to conversion operator intended
</pre></blockquote>
<p>
The call to the conversion operator is overloaded with the thread constructor. But thread constructor requirement 
makes it fail as <tt>AThreadWrapper</tt> is not a Callable and the compiler tries to instantiate the thread 
constructor and fails.
</p>

<p><i>[2014-02-14 Issaquah meeting: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change the following paragraphs in 20.9.11.2.1 [func.wrap.func.con]:
[<em>Editorial comment</em>: The removal of the seemingly additional no-throw
requirements of copy constructor and destructor of <tt>A</tt> is recommended,
because they are already part of the Allocator requirements. Similar clean-up
has been suggested by <a href="lwg-active.html#2070">2070</a> &mdash; <em>end comment</em>]</p>

<blockquote>
<pre>
template&lt;class F> function(F f);
template&lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>
-7- <i>Requires</i>: <tt>F</tt> shall be <tt>CopyConstructible</tt>. <del><tt>f</tt> shall be Callable 
(20.9.11.2 [func.wrap.func]) for argument types <tt>ArgTypes</tt> and return type <tt>R</tt>. 
The copy constructor and destructor of <tt>A</tt> shall not throw exceptions.</del>
<p/>
<ins>-?- <i>Remarks</i>: These constructors shall not participate in overload resolution unless
<tt>f</tt> is Callable (20.9.11.2 [func.wrap.func]) for argument types
<tt>ArgTypes...</tt> and return type <tt>R</tt>.</ins>
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;class F> function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
-18- <i>Effects</i>: <tt>function(std::forward&lt;F&gt;(f)).swap(*this);</tt>
<p/>
-19- <i>Returns</i>: <tt>*this</tt>
<p/>
<ins>-?- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless
<tt>declval&lt;typename decay&lt;F&gt;::type&amp;&gt;()</tt> is Callable (20.9.11.2 [func.wrap.func]) 
for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2182"></a>2182. <tt>Container::[const_]reference</tt> types are misleadingly specified</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-20 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to Table 96 (Container requirements) the return type of <tt>X::reference</tt> and
<tt>X::const_reference</tt> is "lvalue of <tt>T</tt>" and "<tt>const</tt> lvalue of <tt>T</tt>",
respectively. This does not make much sense, because an lvalue is an expression category, not a type.
It could also refer to an expression that has a type, but this doesn't make sense either in this
context, because obviously <tt>X::[const_]reference</tt> are intended to refer to types. 
<p/>
Given the fact that <tt>vector&lt;bool&gt;</tt> has no real reference type for <tt>X::[const_]reference</tt> 
and this definition presumably is intended to cover such situations as well, one might think that the wording is
just a sloppy form of "type that represents a [const] lvalue of <tt>T</tt>". But this is also problematic,
because basically all proxy reference expressions are rvalues.
<p/>
It is unclear what the intention is. A straightward way of fixing this wording could make
<tt>X::[const_]reference</tt> identical to <tt>[const] T&amp;</tt>. This holds for all Library containers
except for <tt>vector&lt;bool&gt;</tt>.
<p/>
Another way of solving this definition problem would be to impose a requirement that holds for both
references and reference-like proxies. Both <tt>X::reference</tt> and <tt>X::const_reference</tt>
would need to be convertible to <tt>const T&amp;</tt>. Additionally <tt>X::reference</tt> would need to
support for a mutable container an assignment expression of the form 
<tt>declval&lt;X::reference&gt;() = declval&lt;T&gt;()</tt> (this presentation intentionally does not require 
<tt>declval&lt;X::reference<span style="color:#C80000;font-weight:bold">&amp;</span>&gt;() = declval&lt;T&gt;()</tt>).
<p/>
Further, the Table 96 does not impose any relations between <tt>X::reference</tt> and <tt>X::const_reference</tt>.
It seems that at least <tt>X::reference</tt> needs to be convertible to <tt>X::const_reference</tt>.
<p/>
A related question is whether <tt>X::reference</tt> is supposed to be a mutable reference-like type,
irrespective of whether the container is an immutable container or not. The way, type <tt>match_results</tt>
defines <tt>reference</tt> identical to <tt>const_reference</tt> indicates one specific interpretation (similarly,
the <tt>initializer_list</tt> template also defines member type <tt>reference</tt> equal to <tt>const value_type&amp;</tt>).
Note that this can be a different decision as that for <tt>iterator</tt> and <tt>const_iterator</tt>,
e.g. for sets the type <tt>X::reference</tt> still is a mutable reference, even though <tt>iterator</tt>
is described as constant iterator.
<p/>
The proposed resolution is incomplete in regard to the last question.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Review.
</p>
<p>
Alisdair notes that this looks like wording in the right direction.  Wonders about congruence of these
typedefs and the similar ones for iterators.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
Moved to Ready.
</p>
<p>
Consensus that the requirements should require real references, just like iterators, as containers are
required to support at least ForwardIterators, which have the same restriction on references.
</p>

<p>
Matt will file a new issue for some additional concerns with regex <tt>match_results</tt>.
</p>

<p><i>[2014-02-10, Daniel comments]</i></p>


<p>
The new issue opened by Matt is LWG <a href="lwg-active.html#2306">2306</a>.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>

<p>
Issue should have been Ready in pre-meeting mailing.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change Table 96 &mdash; "Container requirements" as indicated:</p>

<table border="1">
<caption>Table p6 &mdash; Container requirements</caption>

<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational<br/>Semantics</th>
<th>Assertion/note<br/>pre-/post-condition</th>
<th>Complexity</th>
</tr> 

<tr>
<td>
<tt>X::reference</tt>
</td>
<td>
<del>lvalue of </del><tt>T<ins>&amp;</ins></tt>
</td>
<td>
&nbsp;
</td>
<td>
</td>
<td>
compile time
</td>
</tr>

<tr>
<td>
<tt>X::const_reference</tt>
</td>
<td>
<del>const lvalue of</del><ins><tt>const</tt></ins> <tt>T<ins>&amp;</ins></tt>
</td>
<td>
&nbsp;
</td>
<td>
</td>
<td>
compile time
</td>
</tr>

</table>

</li>
</ol>





<hr>
<h3><a name="2186"></a>2186. Incomplete action on <tt>async/launch::deferred</tt></h3>
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Vicente J. Botet Escriba <b>Opened:</b> 2012-09-20 <b>Last modified:</b> 2014-02-14</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.async">active issues</a> in [futures.async].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The description of the effects of <tt>async</tt> when the launch policy is <tt>launch::deferred</tt> doesn't 
state what is done with the result of the deferred function invocation and the possible exceptions as it is done 
for the asynchronous function when the policy is <tt>launch::async</tt>.
</p>

<p><i>[2012, Portland: move to Open]</i></p>

<p>
Detlef: agree with the problem but not with the resolution. The wording should be applied to all launch policies
        rather than having to be separately specified for each one.
</p>
<p>
Hans: we should redraft to factor out the proposed text outside the two bullets. Needs to be carefully worded to
      be compatible with the resolution of <a href="lwg-defects.html#2120">2120</a> (see above).
</p>
<p>
Moved to open
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate after SG1 review]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>[This wording is relative to N3376.]</i></p>


<ol>
<li><p>Change 30.6.8 [futures.async] p3 bullet 2 as indicated:</p>
<blockquote><pre>
template &lt;class F, class... Args&gt;
future&lt;typename result_of&lt;typename decay&lt;F&gt;::type(typename decay&lt;Args>::type...)&gt;::type&gt;
async(F&amp;&amp; f, Args&amp;&amp;... args);
template &lt;class F, class... Args&gt;
future&lt;typename result_of&lt;typename decay&lt;F&gt;::type(typename decay&lt;Args&gt;::type...)&gt;::type&gt;
async(launch policy, F&amp;&amp; f, Args&amp;&amp;... args);
</pre><blockquote><p>
-2- <i>Requires</i>: [&hellip;]
<p/>
-3- <i>Effects:</i>: The first function behaves the same as a call to the second function with a <tt>policy</tt> argument of
<tt>launch::async | launch::deferred</tt> and the same arguments for <tt>F</tt> and <tt>Args</tt>. [&hellip;] The further 
behavior of the second function depends on the <tt>policy</tt> argument as follows (if more than one of these conditions
applies, the implementation may choose any of the corresponding policies):
</p>
<ul>
<li><p>if <tt>policy &amp; launch::async</tt> is non-zero [&hellip;]</p></li>
<li><p>if <tt>policy &amp; launch::deferred</tt> is non-zero &mdash; Stores <tt><i>DECAY_COPY</i>(std::forward&lt;F&gt;(f))</tt> 
and <tt><i>DECAY_COPY</i>(std::forward&lt;Args>(args))...</tt> in the shared state. These copies of <tt>f</tt> and <tt>args</tt>
constitute a <em>deferred function</em>. Invocation of the deferred function evaluates <tt><i>INVOKE</i>(std::move(g), std::move(xyz))</tt> 
where <tt>g</tt> is the stored value of <tt><i>DECAY_COPY</i>(std::forward&lt;F>(f))</tt> and <tt>xyz</tt> is
the stored copy of <tt><i>DECAY_COPY</i>(std::forward&lt;Args>(args))...</tt>. <ins>Any return value is stored as the 
result in the shared state. Any exception propagated from the execution of the deferred function is stored as the 
exceptional result in the shared state.</ins> The shared state is not made ready until the function has completed. 
The first call to a non-timed waiting function (30.6.4 [futures.state]) on an asynchronous return object referring 
to this shared state shall invoke the deferred function in the thread that called the waiting function. Once evaluation 
of <tt><i>INVOKE</i>(std::move(g), std::move(xyz))</tt> begins, the function is no longer considered deferred. 
[<i>Note</i>: If this policy is specified together with other policies, such as when using a policy value of 
<tt>launch::async | launch::deferred</tt>, implementations should defer invocation or the selection of the <tt>policy</tt> 
when no more concurrency can be effectively exploited. &mdash; <i>end note</i>]
</p></li>
</ul>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2188"></a>2188. Reverse iterator does not fully support targets that overload <tt>operator&amp;</tt></h3>
<p><b>Section:</b> 24.5.1.3.5 [reverse.iter.opref] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2014-02-14</p>
<p><b>View all other</b> <a href="lwg-index.html#reverse.iter.opref">issues</a> in [reverse.iter.opref].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specification for <tt>reverse_iterator::operator-></tt>
returns the address of the object yielded by dereferencing
with <tt>operator*</tt>, but does not have the usual
wording about returning the true address of the object.  As
<tt>reverse_iterator</tt> requires the adapted iterator have
at least the bidirectional iterator category, we know that
the returned reference is a true reference, and not a proxy,
hence we can use <tt>std::addressof</tt> on the reference
to get the right answer.
</p>
<p>
This will most likely show itself as an issue with a <tt>list</tt>
or <tt>vector</tt> of a type with such an overloaded operator,
where algorithms are likely to work with a forward iteration, but
not with reverse iteration.
</p>

<p><i>[2013-04-20, Bristol]</i></p>


<p>
Resolution: Goes to open now and move to review as soon as Daniel proposes a new wording.
</p>

<p><i>[2014-02-12 Issaquah meeting]</i></p>

<p>
Use <tt>std::addressof</tt> as the library uses elsewhere, then move as Immediate.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Revise 24.5.1.3.5 [reverse.iter.opref] p1, as indicated:
</p>
<p>
<i>Returns:</i> <tt><ins>addressof</ins><del>&amp;(</del>operator*()<del>)</del></tt>.
</p>





<hr>
<h3><a name="2193"></a>2193. Default constructors for standard library containers are explicit</h3>
<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2012-10-04 <b>Last modified:</b> 2014-02-14</p>
<p><b>View other</b> <a href="lwg-index-open.html#containers">active issues</a> in [containers].</p>
<p><b>View all other</b> <a href="lwg-index.html#containers">issues</a> in [containers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Most (all?) of the standard library containers have explicit default constructors. Consequently:
</p>
<blockquote><pre>
std::set&lt;int&gt; s1 = { 1, 2 }; // ok
std::set&lt;int&gt; s2 = { 1 }; // ok
std::set&lt;int&gt; s3 = {}; // ill-formed, copy-list-initialization selected an explicit constructor
</pre></blockquote>
<p>
Note that Clang + libc++ rejects the declaration of <tt>s3</tt> for this reason. This cannot possibly match the intent.
</p>
<p>
Suggested fix: apply this transformation throughout the standard library:
</p>
<blockquote><pre>
<ins>set() : set(Compare()) {}</ins>
explicit set(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>

<p><i>[
2012-10-06: Daniel adds concrete wording.
]</i></p>


<p><i>[2012, Portland: Move to Open]</i></p>

<p>
This may be an issue better solved by a core language tweak.  Throw the issue over to EWG and see whether they
believe the issue is better resolved in Core or Library.
</p>

<p>
AJM suggest we spawn a new status of 'EWG' to handle such issues - and will move this issue appropriately when
the software can record such resolutions.
</p>

<p><i>[2013-08-27, Joaqu&iacute;n M L&oacute;pez Mu&ntilde;oz comments:]</i></p>


<p>
For the record, I'd like to point out that the resolution proposed by the submitter, namely replacing
</p>

<blockquote><pre>
explicit basic_string(const Allocator&amp; a = Allocator());
</pre></blockquote>

<p>
by
</p>

<blockquote><pre>
basic_string() : basic_string(Allocator()) {}
explicit basic_string(const Allocator&amp; a);
</pre></blockquote>

<p>
(and similarly for other container and container-like classes) might introduce a potential
backwards-compatibility problem related with explicit instantiation. Consider for instance
</p>

<blockquote><pre>
struct my_allocator
{
  my_allocator(...); // no default ctor
  ...
};

template class std::basic_string&lt;char, std::char_traits&lt;char&gt;, my_allocator&lt;char&gt;&gt;;
</pre></blockquote>

<p>
This (which I understand is currently a valid explicit instantiation of <tt>std::basic_string</tt>) will break if
<tt>std::basic_string</tt> ctors are modified as proposed by this issue, since <tt>my_allocator</tt> doesn't have
a default ctor.
</p>

<p><i>[2013-10-06, Daniel comments:]</i></p>


<p>
Issue <a href="lwg-active.html#2303">2303</a> describes the more general problem related to explicit instantiation requests in the current
library and may help to solve this problem here as well.
</p>

<p><i>[2014-02-13, Issaquah, Jonathan revises wording]</i></p>


<p><strong>Previous resolution from Daniel [SUPERSEDED]:</strong></p>

<blockquote class="note">

<p>This wording is relative to N3376.</p>

<p>The more general criterion for performing the suggested transformation was: Any type with an initializer-list 
constructor that also has an explicit default constructor.</p>

<ol>
<li><p>Change class template <tt>basic_string</tt> synopsis, 21.4 [basic.string] p5 as indicated:</p>
<blockquote><pre>
<ins>basic_string() : basic_string(Allocator()) {}</ins>
explicit basic_string(const Allocator&amp; a<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 21.4.2 [string.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit basic_string(const Allocator&amp; a<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>deque</tt> synopsis, 23.3.3.1 [deque.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>deque() : deque(Allocator()) {}</ins>
explicit deque(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 23.3.3.2 [deque.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit deque(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>forward_list</tt> synopsis, 23.3.4.1 [forwardlist.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>forward_list() : forward_list(Allocator()) {}</ins>
explicit forward_list(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 23.3.4.2 [forwardlist.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit forward_list(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>list</tt> synopsis, 23.3.5.1 [list.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>list() : list(Allocator()) {}</ins>
explicit list(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 23.3.5.2 [list.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit list(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>vector</tt> synopsis, 23.3.6.1 [vector.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>vector() : vector(Allocator()) {}</ins>
explicit vector(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 23.3.6.2 [vector.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit vector(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template specialization <tt>vector&lt;bool&gt;</tt> synopsis, 23.3.7 [vector.bool] p1 as indicated:</p>
<blockquote><pre>
<ins>vector() : vector(Allocator()) {}</ins>
explicit vector(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>map</tt> synopsis, 23.4.4.1 [map.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>map() : map(Compare()) {}</ins>
explicit map(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change 23.4.4.2 [map.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit map(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change class template <tt>multimap</tt> synopsis, 23.4.5.1 [multimap.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>multimap() : multimap(Compare()) {}</ins>
explicit multimap(const Compare&amp; comp<del> = Compare()</del>,
                  const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change 23.4.5.2 [multimap.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit multimap(const Compare&amp; comp<del> = Compare()</del>,
                  const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change class template <tt>set</tt> synopsis, 23.4.6.1 [set.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>set() : set(Compare()) {}</ins>
explicit set(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change 23.4.6.2 [set.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit set(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change class template <tt>multiset</tt> synopsis, 23.4.7.1 [multiset.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>multiset() : multiset(Compare()) {}</ins>
explicit multiset(const Compare&amp; comp<del> = Compare()</del>,
                  const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change 23.4.7.2 [multiset.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit multiset(const Compare&amp; comp<del> = Compare()</del>,
                  const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change class template <tt>unordered_map</tt> synopsis, 23.5.4.1 [unord.map.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>unordered_map() : unordered_map(<i>see below</i>) {}</ins>
explicit unordered_map(size_type n<del> = <i>see below</i></del>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change 23.5.4.2 [unord.map.cnstr] before p1 as indicated:</p>
<blockquote><pre>
<ins>unordered_map() : unordered_map(<i>see below</i>) {}</ins>
explicit unordered_map(size_type n<del> = <i>see below</i></del>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change class template <tt>unordered_multimap</tt> synopsis, 23.5.5.1 [unord.multimap.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>unordered_multimap() : unordered_multimap(<i>see below</i>) {}</ins>
explicit unordered_multimap(size_type n<del> = <i>see below</i></del>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change 23.5.5.2 [unord.multimap.cnstr] before p1 as indicated:</p>
<blockquote><pre>
<ins>unordered_multimap() : unordered_multimap(<i>see below</i>) {}</ins>
explicit unordered_multimap(size_type n<del> = <i>see below</i></del>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change class template <tt>unordered_set</tt> synopsis, 23.5.6.1 [unord.set.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>unordered_set() : unordered_set(<i>see below</i>) {}</ins>
explicit unordered_set(size_type n<del> = <i>see below</i></del>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change 23.5.6.2 [unord.set.cnstr] before p1 as indicated:</p>
<blockquote><pre>
<ins>unordered_set() : unordered_set(<i>see below</i>) {}</ins>
explicit unordered_set(size_type n<del> = <i>see below</i></del>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change class template <tt>unordered_multiset</tt> synopsis, 23.5.7.1 [unord.multiset.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>unordered_multiset() : unordered_multiset(<i>see below</i>) {}</ins>
explicit unordered_multiset(size_type n<del> = <i>see below</i></del>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change 23.5.7.2 [unord.multiset.cnstr] before p1 as indicated:</p>
<blockquote><pre>
<ins>unordered_multiset() : unordered_multiset(<i>see below</i>) {}</ins>
explicit unordered_multiset(size_type n<del> = <i>see below</i></del>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>
</ol>

</blockquote>

<p><i>[Issaquah 20014-10-11: Move to Immediate after final review]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<p>The more general criterion for performing the suggested transformation was: Any type with an initializer-list 
constructor that also has an explicit default constructor.</p>

<ol>
<li><p>Change class template <tt>basic_string</tt> synopsis, 21.4 [basic.string] p5 as indicated:</p>
<blockquote><pre>
<ins>basic_string() : basic_string(Allocator()) { }</ins>
explicit basic_string(const Allocator&amp; a<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 21.4.2 [string.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit basic_string(const Allocator&amp; a<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>deque</tt> synopsis, 23.3.3.1 [deque.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>deque() : deque(Allocator()) { }</ins>
explicit deque(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 23.3.3.2 [deque.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit deque(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>forward_list</tt> synopsis, 23.3.4.1 [forwardlist.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>forward_list() : forward_list(Allocator()) { }</ins>
explicit forward_list(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 23.3.4.2 [forwardlist.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit forward_list(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>list</tt> synopsis, 23.3.5.1 [list.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>list() : list(Allocator()) { }</ins>
explicit list(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 23.3.5.2 [list.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit list(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>vector</tt> synopsis, 23.3.6.1 [vector.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>vector() : vector(Allocator()) { }</ins>
explicit vector(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change 23.3.6.2 [vector.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit vector(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template specialization <tt>vector&lt;bool&gt;</tt> synopsis, 23.3.7 [vector.bool] p1 as indicated:</p>
<blockquote><pre>
<ins>vector() : vector(Allocator()) { }</ins>
explicit vector(const Allocator&amp;<del> = Allocator()</del>);
</pre></blockquote>
</li>

<li><p>Change class template <tt>map</tt> synopsis, 23.4.4.1 [map.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>map() : map(Compare()) { }</ins>
explicit map(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change 23.4.4.2 [map.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit map(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change class template <tt>multimap</tt> synopsis, 23.4.5.1 [multimap.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>multimap() : multimap(Compare()) { }</ins>
explicit multimap(const Compare&amp; comp<del> = Compare()</del>,
                  const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change 23.4.5.2 [multimap.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit multimap(const Compare&amp; comp<del> = Compare()</del>,
                  const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change class template <tt>set</tt> synopsis, 23.4.6.1 [set.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>set() : set(Compare()) { }</ins>
explicit set(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change 23.4.6.2 [set.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit set(const Compare&amp; comp<del> = Compare()</del>,
             const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change class template <tt>multiset</tt> synopsis, 23.4.7.1 [multiset.overview] p2 as indicated:</p>
<blockquote><pre>
<ins>multiset() : multiset(Compare()) { }</ins>
explicit multiset(const Compare&amp; comp<del> = Compare()</del>,
                  const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change 23.4.7.2 [multiset.cons] before p1 as indicated:</p>
<blockquote><pre>
explicit multiset(const Compare&amp; comp<del> = Compare()</del>,
                  const Allocator&amp; = Allocator());
</pre></blockquote>
</li>

<li><p>Change class template <tt>unordered_map</tt> synopsis, 23.5.4.1 [unord.map.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>unordered_map();</ins>
explicit unordered_map(size_type n<del> = <i>see below</i></del>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change 23.5.4.2 [unord.map.cnstr] before p1 as indicated:</p>
<blockquote><pre>
<ins>unordered_map() : unordered_map(size_type(<i>see below</i>)) { }</ins>
explicit unordered_map(size_type n<del> = <i>see below</i></del>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre>

-1- <i>Effects:</i> Constructs an empty <code>unordered_map</code> using the specified hash function, key equality func-<br />
tion, and allocator, and using at least <i>n</i> buckets. <del>If <i>n</i> is not provided,</del> <ins>For the default constructor</ins><br />
the number of buckets is implementation-defined. <code>max_load_factor()</code> returns 1.0.
</blockquote>

</li>

<li><p>Change class template <tt>unordered_multimap</tt> synopsis, 23.5.5.1 [unord.multimap.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>unordered_multimap();</ins>
explicit unordered_multimap(size_type n<del> = <i>see below</i></del>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change 23.5.5.2 [unord.multimap.cnstr] before p1 as indicated:</p>
<blockquote><pre>
<ins>unordered_multimap() : unordered_multimap(size_type(<i>see below</i>)) { }</ins>
explicit unordered_multimap(size_type n<del> = <i>see below</i></del>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre>

-1- <i>Effects:</i> Constructs an empty <code>unordered_multimap</code> using the specified hash function, key equality<br />
function, and allocator, and using at least <i>n</i> buckets. <del>If <i>n</i> is not provided,</del> <ins>For the default constructor</ins><br />
the number of buckets is implementation-defined. <code>max_load_factor()</code> returns 1.0.

</blockquote>
</li>

<li><p>Change class template <tt>unordered_set</tt> synopsis, 23.5.6.1 [unord.set.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>unordered_set();</ins>
explicit unordered_set(size_type n<del> = <i>see below</i></del>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change 23.5.6.2 [unord.set.cnstr] before p1 as indicated:</p>
<blockquote><pre>
<ins>unordered_set() : unordered_set(size_type(<i>see below</i>)) { }</ins>
explicit unordered_set(size_type n<del> = <i>see below</i></del>,
                       const hasher&amp; hf = hasher(),
                       const key_equal&amp; eql = key_equal(),
                       const allocator_type&amp; a = allocator_type());
</pre>

-1- <i>Effects:</i> Constructs an empty <code>unordered_set</code> using the specified hash function, key equality func-<br />
tion, and allocator, and using at least <i>n</i> buckets. <del>If <i>n</i> is not provided,</del> <ins>For the default constructor</ins><br />
the number of buckets is implementation-defined. <code>max_load_factor()</code> returns 1.0.

</blockquote>
</li>

<li><p>Change class template <tt>unordered_multiset</tt> synopsis, 23.5.7.1 [unord.multiset.overview] p3 as indicated:</p>
<blockquote><pre>
<ins>unordered_multiset();</ins>
explicit unordered_multiset(size_type n<del> = <i>see below</i></del>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre></blockquote>
</li>

<li><p>Change 23.5.7.2 [unord.multiset.cnstr] before p1 as indicated:</p>
<blockquote><pre>
<ins>unordered_multiset() : unordered_multiset(size_type(<i>see below</i>)) { }</ins>
explicit unordered_multiset(size_type n<del> = <i>see below</i></del>,
                            const hasher&amp; hf = hasher(),
                            const key_equal&amp; eql = key_equal(),
                            const allocator_type&amp; a = allocator_type());
</pre>

-1- <i>Effects:</i> Constructs an empty <code>unordered_multiset</code> using the specified hash function, key equality<br />
function, and allocator, and using at least <i>n</i> buckets. <del>If <i>n</i> is not provided,</del> <ins>For the default constructor</ins><br />
the number of buckets is implementation-defined. <code>max_load_factor()</code> returns 1.0.

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






<hr>
<h3><a name="2205"></a>2205. Problematic postconditions of <tt>regex_match</tt> and <tt>regex_search</tt></h3>
<p><b>Section:</b> 28.11.2 [re.alg.match], 28.11.3 [re.alg.search] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-10-24 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.alg.match">active issues</a> in [re.alg.match].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.alg.match">issues</a> in [re.alg.match].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Table 142 lists post-conditions on the <tt>match_results</tt> object when a call to <tt>regex_match</tt> succeeds. 
<tt>regex_match</tt> is required to match the entire target sequence. The post-condition for <tt>m[0].matched</tt> 
is "true if a full match was found." Since these are conditions for a successful search which is, by definition, 
a full match, the post-condition should be simply "true".
</p>
<p>
There's an analogous probem in Table 143: the condition for <tt>m[0].matched</tt> is "true if a match was found, 
false otherwise." But Table 143 gives post-conditions for a successful match, so the condition should be simply 
"true".
</p>
<p>
Furthermore, they have explicit requirements for <tt>m[0].first</tt>, <tt>m[0].second</tt>, and <tt>m[0].matched</tt>. 
They also have requirements for the other elements of <tt>m</tt>, described as <tt>m[n].first</tt>, <tt>m[n].second</tt>, 
and <tt>m[n].matched</tt>, in each case qualifying the value of <tt>n</tt> as "for <tt>n &lt; m.size()</tt>". Since 
there is an explicit description for <tt>n == 0</tt>, this qualification should be "for <tt>0 &lt; n &lt; m.size()</tt>" 
in all 6 places.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change Table 142 as indicated:</p>

<table border="1">
<caption>Table 142 &mdash; Effects of <tt>regex_match</tt> algorithm</caption>
<tr>
<th>Element</th>
<th>Value</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>m[0].first</tt>
</td>
<td>
<tt>first</tt>
</td>
</tr>

<tr>
<td>
<tt>m[0].second</tt>
</td>
<td>
<tt>last</tt>
</td>
</tr>

<tr>
<td>
<tt>m[0].matched</tt>
</td>
<td>
<tt>true</tt> <del>if a full match was found.</del>
</td>
</tr>

<tr>
<td>
<tt>m[n].first</tt>
</td>
<td>
For all integers <tt><ins>0 &lt;</ins> n &lt; m.size()</tt>, the start of the sequence
that matched sub-expression <tt>n</tt>.<br/> 
Alternatively, if subexpression <tt>n</tt> did not participate in the match, then <tt>last</tt>.
</td>
</tr>

<tr>
<td>
<tt>m[n].second</tt>
</td>
<td>
For all integers <tt><ins>0 &lt;</ins> n &lt; m.size()</tt>, the end of the sequence that
matched sub-expression <tt>n</tt>.<br/> 
Alternatively, if sub-expression <tt>n</tt> did not participate in the match, then <tt>last</tt>.
</td>
</tr>

<tr>
<td>
<tt>m[n].matched</tt>
</td>
<td>
For all integers <tt><ins>0 &lt;</ins> n &lt; m.size()</tt>, <tt>true</tt> if sub-expression 
<tt>n</tt> participated in the match, <tt>false</tt> otherwise.
</td>
</tr>

</table>
</li>

<li><p>Change Table 143 as indicated:</p>

<table border="1">
<caption>Table 143 &mdash; Effects of <tt>regex_search</tt> algorithm</caption>
<tr>
<th>Element</th>
<th>Value</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>m[0].first</tt>
</td>
<td>
The start of the sequence of characters that matched the regular expression
</td>
</tr>

<tr>
<td>
<tt>m[0].second</tt>
</td>
<td>
The end of the sequence of characters that matched the regular expression
</td>
</tr>

<tr>
<td>
<tt>m[0].matched</tt>
</td>
<td>
<tt>true</tt> <del>if a match was found, and false otherwise.</del>
</td>
</tr>

<tr>
<td>
<tt>m[n].first</tt>
</td>
<td>
For all integers <tt><ins>0 &lt;</ins> n &lt; m.size()</tt>, the start of the sequence
that matched sub-expression <tt>n</tt>.<br/> 
Alternatively, if subexpression <tt>n</tt> did not participate in the match, then <tt>last</tt>.
</td>
</tr>

<tr>
<td>
<tt>m[n].second</tt>
</td>
<td>
For all integers <tt><ins>0 &lt;</ins> n &lt; m.size()</tt>, the end of the sequence that
matched sub-expression <tt>n</tt>.<br/> 
Alternatively, if sub-expression <tt>n</tt> did not participate in the match, then <tt>last</tt>.
</td>
</tr>

<tr>
<td>
<tt>m[n].matched</tt>
</td>
<td>
For all integers <tt><ins>0 &lt;</ins> n &lt; m.size()</tt>, <tt>true</tt> if sub-expression 
<tt>n</tt> participated in the match, <tt>false</tt> otherwise.
</td>
</tr>

</table>
</li>

</ol>





<hr>
<h3><a name="2213"></a>2213. Return value of <tt>std::regex_replace</tt></h3>
<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2012-11-08 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 28.11.4 [re.alg.replace], the first two variants of <tt>std::regex_replace</tt> take an output iterator named 
"out" as their first argument. Paragraph 2 of that section says that the functions return "out". When I first implemented 
this, many years ago, I wrote it to return the value of the output iterator after all the insertions (cf. <tt>std::copy</tt>), 
which seems like the most useful behavior. But looking at the requirement now, it like the functions should return the 
original value of "out" (i.e. they have to keep a copy of the iterator for no reason except to return it). Is that 
really what was intended?
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>

<ol>
<li><p>Edit 28.11.4 [re.alg.replace] as indicated:</p>
<blockquote><pre>
template &lt;class OutputIterator, class BidirectionalIterator,
  class traits, class charT, class ST, class SA&gt;
OutputIterator
regex_replace(OutputIterator out, BidirectionalIterator first, BidirectionalIterator last,
  const basic_regex&lt;charT, traits&gt;&amp; e, const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
  regex_constants::match_flag_type flags = regex_constants::match_default);
template &lt;class OutputIterator, class BidirectionalIterator,
  class traits, class charT&gt;
OutputIterator
regex_replace(OutputIterator out, BidirectionalIterator first, BidirectionalIterator last,
  const basic_regex&lt;charT, traits&gt;&amp; e, const charT* fmt,
  regex_constants::match_flag_type flags = regex_constants::match_default);
</pre><blockquote>
<p>
-1- <i>Effects</i>: Constructs a <tt>regex_iterator</tt> object <tt>i</tt> as if by 
<tt>regex_iterator&lt;BidirectionalIterator, charT, traits&gt; i(first, last, e, flags)</tt>, 
and uses <tt>i</tt> to enumerate through all of the matches <tt>m</tt> of type 
<tt>match_results&lt;BidirectionalIterator&gt;</tt> that occur within the sequence <tt>[first, last)</tt>. 
If no such matches are found and <tt>!(flags &amp; regex_constants ::format_no_copy)</tt> then calls
<tt><ins>out = </ins>std::copy(first, last, out)</tt>. If any matches are found then, for each such match, if 
<tt>!(flags &amp; regex_constants::format_no_copy)</tt>, calls <tt><ins>out = </ins>std::copy(m.prefix().first, 
m.prefix().second, out)</tt>, and then calls <tt><ins>out = </ins>m.format(out, fmt, flags)</tt> 
for the first form of the function and <tt><ins>out = </ins>m.format(out, fmt, fmt + 
char_traits&lt;charT&gt;::length(fmt), flags)</tt> for the second. Finally, if such a match is found 
and <tt>!(flags &amp; regex_constants ::format_no_copy)</tt>, calls 
<tt><ins>out = </ins>std::copy(last_m.suffix().first, last_m.suffix().second, out)</tt> where 
<tt>last_m</tt> is a copy of the last match found. If <tt>flags &amp; regex_constants::format_first_only</tt> 
is non-zero then only the first match found is replaced.
<p/>
-2- <i>Returns</i>: <tt>out</tt>.
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2258"></a>2258. <tt>a.erase(q1, q2)</tt> unable to directly return <tt>q2</tt></h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Geoff Alexander <b>Opened:</b> 2013-05-11 <b>Last modified:</b> 2014-02-14</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 23.2.4 [associative.reqmts], Table 102, page 743 of the C++ 2011 Standard states that <tt>a.erase(q1, q2)</tt> 
returns <tt>q2</tt>. The problem is that <tt>a.erase(q1, q2)</tt> cannot directly return <tt>q2</tt> as the return type, 
<tt>iterator</tt>, differs from that of <tt>q2</tt>, <tt>const_iterator</tt>. 
</p>

<p><i>[2013-09 Chicago (evening issues group)]</i></p>

<p>
The wording looks good, but is worded slightly differently to how we say the same for sequence containers, and for unordered
associative containers.  We should apply consistent wording in all three cases.
</p>
<p>
Alisdair to provide the wording.
</p>

<p><i>[2014-02-12 Issaquah meeting]</i></p>

<p>
Move a Immediate.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li><p>In the specification of <tt>a.erase(q1, q2)</tt> in sub-clause 23.2.4 [associative.reqmts], Table 102 change as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 102 &mdash; Associative container requirements (in addition to container) (continued)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a.erase(q1, q2)</tt>
</td>
<td>
<tt>iterator</tt>
</td>
<td>
erases all the elements in the range <tt>[q1,q2)</tt>. Returns <del><tt>q2</tt></del><ins>
an iterator pointing to the element pointed to by <tt>q2</tt> prior to any elements
being erased. If no such element exists, <tt>a.end()</tt> is returned</ins>.
</td>
<td>
<tt>log(a.size()) + N</tt> where <tt>N</tt> has the value <tt>distance(q1, q2)</tt>.
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2263"></a>2263. Comparing iterators and allocator pointers with different const-character</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements], 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2013-06-25 <b>Last modified:</b> 2014-02-14</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This ancient issue <a href="lwg-defects.html#179">179</a> says one ought to be able to compare iterators with <tt>const_iterators</tt> 
from any given container.  I'm having trouble finding words that guarantee this in C++11.  This impacts not only a 
container's iterators, but also the allocator requirements in  allocator.requirements] surrounding 
<tt>pointer</tt>, <tt>const_pointer</tt>, <tt>void_pointer</tt> and <tt>const_void_pointer</tt>.  E.g. can one 
compare a <tt>pointer</tt> with a <tt>const_pointer</tt>? 
<p/>
Since <tt>allocator::pointer</tt> and <tt>const_pointer</tt> are required to be random access iterators, one could 
expect that the <a href="lwg-defects.html#179">179</a> guarantees apply for them as well.
</p>

<p><i>[
Daniel comments:
]</i></p>


<p>
The wording for <a href="lwg-defects.html#179">179</a> was part of several working drafts (e.g. also in 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>) over some time and suddenly got lost
in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf">N3242</a>, presumably by accident. Whatever we
decide for allocator pointers, I expect that we need to restore the  <a href="lwg-defects.html#179">179</a> wording as part of the overall resolution:
</p>

<p>Reinsert after 23.2 [container.requirements] p6:</p>

<blockquote>
<p>
-6- <tt>begin()</tt> returns an iterator referring to the first element in the container. <tt>end()</tt> returns an iterator which
is the past-the-end value for the container. If the container is empty, then <tt>begin() == end()</tt>;
<p/>
<ins>-?- In the expressions</ins>
</p>
<blockquote><pre>
<ins>i == j
i != j
i &lt; j
i &lt;= j
i &gt;= j
i &gt; j
i - j</ins>
</pre></blockquote>
<p>
<ins>where <tt>i</tt> and <tt>j</tt> denote objects of a container's <tt>iterator</tt> type, either or both may be replaced by an object 
of the container's <tt>const_iterator</tt> type referring to the same element with no change in semantics.</ins>
</p>
</blockquote>

<p><i>[2014-02-13 Issaquah, Daniel comments and suggests wording]</i></p>


<p>
First, I didn't originally move the seemingly lost wording to the resolution section because I wanted to ensure that the 
committee double-checks the reason of this loss. 
<p/>
Second, albeit restoring this wording will restore the comparability of <tt>const_iterator</tt> and <tt>iterator</tt> of
containers specified in Clause 23, but this alone would <em>not</em> imply that this guarantee automatically extends to
<em>all other</em> iterators, simply because there is no fundamental relation between a mutable iterator and a constant
iterator by itself. This relation only exists under specific conditions, for example for containers which provide two such
<tt>typedefs</tt> of that kind. Thus the wording restoration would <em>not</em> ensure that allocator <tt>pointer</tt> and 
<tt>const_pointer</tt> would be comparable with each other. To realize that, we would need additional guarantees added
to the allocator requirements. In fact, it is crucial to separate these things, because allocators are <em>not</em> 
restricted to be used within containers, they have their own legitimate use for other places as well (albeit containers
presumably belong to the most important use-cases), and this is also stated in the introduction of 17.6.3.5 [allocator.requirements],
where it says:
</p>
<blockquote><p>
All of the string types (Clause 21), containers (Clause 23) (except array), string buffers and string streams (Clause 27), 
and <tt>match_results</tt> (Clause 28) are parameterized in terms of allocators.
</p></blockquote>

<p><i>[2014-02-12 Issaquah meeting]</i></p>

<p>
Move a Immediate.
</p>



<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Insert after 17.6.3.5 [allocator.requirements] p4 as indicated:</p>

<blockquote><p>
-4- An allocator type <tt>X</tt> shall satisfy the requirements of <tt>CopyConstructible</tt> (17.6.3.1). The <tt>X::pointer</tt>,
<tt>X::const_pointer</tt>, <tt>X::void_pointer</tt>, and <tt>X::const_void_pointer</tt> types shall satisfy the requirements
of <tt>NullablePointer</tt> (17.6.3.3). No constructor, comparison operator, copy operation, move operation, or
swap operation on these types shall exit via an exception. <tt>X::pointer</tt> and <tt>X::const_pointer</tt> shall also
satisfy the requirements for a random access iterator (24.2).
<p/>
<ins>-?- Let <tt>x1</tt> and <tt>x2</tt> denote objects of (possibly different) types <tt>X::void_pointer</tt>, 
<tt>X::const_void_pointer</tt>, <tt>X::pointer</tt>, or <tt>X::const_pointer</tt>. Then, <tt>x1</tt> and <tt>x2</tt>
are <em>equivalently-valued</em> pointer values, if and only if both <tt>x1</tt> and <tt>x2</tt> can be explicitly converted 
to the two corresponding objects <tt>px1</tt> and <tt>px2</tt> of type <tt>X::const_pointer</tt>, using a sequence of
<tt>static_cast</tt>s using only these four types, and the expression <tt>px1 == px2</tt> evaluates to <tt>true</tt>.</ins>
</p>
<blockquote class="note"><p>
<em>Drafting note:</em> This wording uses the seemingly complicated route via <tt>X::const_pointer</tt>, because these are (contrary to
<tt>X::const_void_pointer</tt>) random access iterators and we can rely here for dereferenceable values on the fundamental pointee
equivalence of 24.2.5 [forward.iterators] p6:
</p>
<blockquote><p>
If <tt>a</tt> and <tt>b</tt> are both dereferenceable, then <tt>a == b</tt> if and only if <tt>*a</tt> and <tt>*b</tt> are 
bound to the same object.
</p></blockquote>
<p>
while for null pointer values we can rely on the special equality relation induced by 17.6.3.3 [nullablepointer.requirements].
</p>
</blockquote>
<p>
<ins>-?- Let <tt>w1</tt> and <tt>w2</tt> denote objects of type <tt>X::void_pointer</tt>. Then for the expressions</ins>
</p>
<blockquote><pre>
<ins>w1 == w2
w1 != w2</ins>
</pre></blockquote>
<p>
<ins>either or both objects may be replaced by an equivalently-valued object of type <tt>X::const_void_pointer</tt> with no 
change in semantics.</ins>
<p/>
<ins>-?- Let <tt>p1</tt> and <tt>p2</tt> denote objects of type <tt>X::pointer</tt>. Then for the expressions</ins>
</p>
<blockquote><pre>
<ins>p1 == p2
p1 != p2
p1 &lt; p2
p1 &lt;= p2
p1 &gt;= p2
p1 &gt; p2
p1 - p2</ins>
</pre></blockquote>
<p>
<ins>either or both objects may be replaced by an equivalently-valued object of type <tt>X::const_pointer</tt> with no 
change in semantics.</ins>
</p>
</blockquote>
</li>
<li><p>Reinsert after 23.2 [container.requirements] p6:</p>

<blockquote><p>
-6- <tt>begin()</tt> returns an iterator referring to the first element in the container. <tt>end()</tt> returns an iterator which
is the past-the-end value for the container. If the container is empty, then <tt>begin() == end()</tt>;
<p/>
<ins>-?- In the expressions</ins>
</p>
<blockquote><pre>
<ins>i == j
i != j
i &lt; j
i &lt;= j
i &gt;= j
i &gt; j
i - j</ins>
</pre></blockquote>
<p>
<ins>where <tt>i</tt> and <tt>j</tt> denote objects of a container's <tt>iterator</tt> type, either or both may be replaced by an object 
of the container's <tt>const_iterator</tt> type referring to the same element with no change in semantics.</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2293"></a>2293. Wrong facet used by <tt>num_put::do_put</tt></h3>
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-09-04 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
At the end of 22.4.2.2.2 [facet.num.put.virtuals] (in p6), the return value is said to be obtained by calling 
<tt>truename</tt> or <tt>falsename</tt> on the wrong facet: <tt>ctype</tt> should be replaced by <tt>numpunct</tt>.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 22.4.2.2.2 [facet.num.put.virtuals] p6 as indicated:</p>

<blockquote><p>
-6- <i>Returns:</i> If <tt>(str.flags() &amp; ios_base::boolalpha) == 0</tt> returns <tt>do_put(out, str, fill, (int)val)</tt>, 
otherwise obtains a string <tt>s</tt> as if by
</p>
<blockquote><pre>
string_type s =
  val ? use_facet&lt;<del>ctype</del><ins>numpunct</ins>&lt;charT&gt; &gt;(loc).truename()
      : use_facet&lt;<del>ctype</del><ins>numpunct</ins>&lt;charT&gt; &gt;(loc).falsename();
</pre></blockquote>
<p>
and then inserts each character c of s into out via *out++ = c and returns out.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2299"></a>2299. [CD] Effects of inaccessible <tt>key_compare::is_transparent</tt> type are not clear</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-09-24 <b>Last modified:</b> 2014-02-13</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses ES 16</b></p>

<p>
The condition "<tt>X::key_compare::is_transparent</tt> exists" does not specify that the type be publicly accessible.     
<p/>
Consider the public accessibility of <tt>X::key_compare::is_transparent</tt> and whether its potential inaccessibility 
should be banned for a compliant <tt>key_compare</tt> type. 
</p>

<p><i>[2013-09-24 Daniel provides resolution suggestion]</i></p>


<p><i>[2013-09-25 Chicago]</i></p>

<p>
Daniel's wording is good, advance to Immediate to respond to NB comment.
</p>

<p><i>[2013-09-26 Chicago]</i></p>

<p>
Moved back to Review as Daniel would like another look at the words, and to confirm implementability.
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>

<li><p>Change 23.2.4 [associative.reqmts] p8 as indicated:</p>

<blockquote><p>
-8- In Table 102, <tt>X</tt> denotes an associative container class, <tt>a</tt> denotes a value of <tt>X</tt>, <tt>a_uniq</tt> 
denotes a value of <tt>X</tt> when <tt>X</tt> supports unique keys, <tt>a_eq</tt> denotes a value of <tt>X</tt> when <tt>X</tt> 
supports multiple keys, <tt>a_tran</tt> denotes a value of <tt>X</tt> when <del>the</del><ins>a publicly accessible</ins> type 
<tt>X::key_compare::is_transparent</tt> exists <ins>whose name is unambiguous and not hidden</ins>, 
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Change 23.2.4 [associative.reqmts] p13 as indicated:</p>

<blockquote><p>
The member function templates <tt>find</tt>, <tt>count</tt>, <tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt> shall not
participate in overload resolution unless <del>the</del><ins>a publicly accessible</ins> type 
<tt>Compare::is_transparent</tt> exists <ins>whose name is unambiguous and not hidden</ins>.
</p></blockquote>
</li>
</ol>

</blockquote>

<p><i>[2014-02-10 Daniel comments provides alternative wording]</i></p>


<p>
I could confirm that my previous concerns were unwarranted, because they turned out to be due to a compiler-bug.
Nonetheless I would suggest to replace the previously suggested replication of core-wording situations (access, ambiguity, hidden) 
by a single more robust phrase based on "valid type".
</p>


<p><i>[2014-02-12 Issaquah: Move to Immediate]</i></p>

<p>
STL: This uses &quot;valid type&quot;, which is a Phrase Of Power in Core, and Daniel has a citation for the term.
</p>
<p>
Jonathan: It's nice to rely on Core.
</p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>

<li><p>Change 23.2.4 [associative.reqmts] p8 as indicated:</p>

<blockquote><p>
-8- In Table 102, <tt>X</tt> denotes an associative container class, <tt>a</tt> denotes a value of <tt>X</tt>, <tt>a_uniq</tt> 
denotes a value of <tt>X</tt> when <tt>X</tt> supports unique keys, <tt>a_eq</tt> denotes a value of <tt>X</tt> when <tt>X</tt> 
supports multiple keys, <tt>a_tran</tt> denotes a value of <tt>X</tt> when the <del>type</del><ins>qualified-id</ins> 
<tt>X::key_compare::is_transparent</tt> <del>exists</del><ins>is valid and denotes a type (14.8.2 [temp.deduct])</ins>, 
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Change 23.2.4 [associative.reqmts] p13 as indicated:</p>

<blockquote><p>
The member function templates <tt>find</tt>, <tt>count</tt>, <tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt> shall not
participate in overload resolution unless the <del>type</del><ins>qualified-id</ins> 
<tt>Compare::is_transparent</tt> <del>exists</del><ins>is valid and denotes a type (14.8.2 [temp.deduct])</ins>.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2301"></a>2301. Why is <tt>std::tie</tt> not <tt>constexpr</tt>?</h3>
<p><b>Section:</b> 20.4.2.4 [tuple.creation] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Rein Halbersma <b>Opened:</b> 2013-09-11 <b>Last modified:</b> 2014-02-13</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.creation">issues</a> in [tuple.creation].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3471.html">N3471</a>, a bunch of routines from header 
<tt>&lt;tuple&gt;</tt> were made <tt>constexpr</tt>.
<p/>
<tt>make_tuple/tuple_cat/get&lt;&gt;(tuple)/</tt>relational operators &mdash; all these were "<tt>constexpr</tt>-ified".     
<p/>
But not <tt>tie</tt>. This is similar to Issue <a href="lwg-defects.html#2275">2275</a>, where the same observation was made about <tt>forward_as_tuple</tt>.
</p>

<p><i>[2014-02-13 Issaquah: Move as Immediate]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change the header <tt>&lt;tuple&gt;</tt> synopsis, 20.4.1 [tuple.general] p2 as indicated:</p>

<blockquote><pre>
template&lt;class... Types&gt;
  <ins>constexpr</ins> tuple&lt;Types&amp;...&gt; tie(Types&amp;...) noexcept;
</pre>
</blockquote>
</li>

<li><p>Change 20.4.2.4 [tuple.creation] around p7 as indicated:</p>

<blockquote><pre>
template&lt;class... Types&gt;
  <ins>constexpr</ins> tuple&lt;Types&amp;...&gt; tie(Types&amp;... t) noexcept;
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2304"></a>2304. Complexity of <tt>count</tt> in unordered associative containers</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Joaqu&iacute;n M L&oacute;pez Mu&ntilde;oz <b>Opened:</b> 2013-09-20 <b>Last modified:</b> 2014-02-13</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 103 in 23.2.5 [unord.req] states that the complexity of <tt>b.count(k)</tt> is average case &#x1d4aa;(<tt>1</tt>) rather 
than linear with the number of equivalent elements, which seems to be a typo as this requires holding an internal 
count of elements in each group of equivalent keys, something which hardly looks the intent of the standard and no 
(known by the submitter) stdlib implementation is currently doing.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change Table 103 as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 103 &mdash; Unordered associative container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>b.count(k)</tt>
</td>
<td>
<tt>size_type</tt>
</td>
<td>
Returns the number of elements with key equivalent to <tt>k</tt>.
</td>
<td>
Average case &#x1d4aa;(<tt><del>1</del><ins>b.count(k)</ins></tt>), worst case &#x1d4aa;(<tt>b.size()</tt>).
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2306"></a>2306. <tt>match_results::reference</tt> should be <tt>value_type&amp;</tt>, not <tt>const value_type&amp;</tt></h3>
<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2013-09-25 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.results">active issues</a> in [re.results].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.results">issues</a> in [re.results].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The match_results class synopsis has
</p>
<blockquote><pre>
typedef const value_type&amp; const_reference;
typedef const_reference reference;
</pre></blockquote>
<p>
We're getting too enthusiastic about types here by insisting that <tt>reference</tt> is a const reference, even 
though <tt>match_results</tt> is a read-only container. In the container requirements table (Table 96, in section 
23.2.1 [container.requirements.general] we say that <tt>Container::reference</tt> is "lvalue of <tt>T</tt>" and 
<tt>Container::const_reference</tt> is "const lvalue of <tt>T</tt>".
</p>
<p>
That phrasing in the container requirements table is admittedly a little fuzzy and ought to be clarified (as discussed in 
lwg issue <a href="lwg-active.html#2182">2182</a>), but in context it's clear that <tt>Container::reference</tt> ought to be a <tt>T&amp;</tt> 
even for constant containers. In the rest of Clause 23 we see that <tt>Container::reference</tt> is <tt>T&amp;</tt>, not 
<tt>const T&amp;</tt>, even for const-qualified containers and that it's <tt>T&amp;</tt>, not <tt>const T&amp;</tt>, even 
for containers like <tt>set</tt> and <tt>unordered_set</tt> that provide const iterators only.
<p/>
The way we handle const containers is just that in the case of a const-qualified container (including <tt>match_results</tt>) 
there are no operations that return <tt>Container::reference</tt>. That's already the case, so this issue is complaining 
about an unused typedef.
</p>

<p><i>[2013-10-17: Daniel comments]</i></p>

<p>
The <tt>std::initializer_list</tt> synopsis, 18.9 [support.initlist] shows a similar problem:
</p>
<blockquote><pre>
template&lt;class E&gt; class initializer_list {
public:
  typedef E value_type;
  typedef const E&amp; reference;
  typedef const E&amp; const_reference;
  [&hellip;]
}
</pre></blockquote>
<p>
Given the fact that <tt>std::initializer_list</tt> doesn't meet the container requirements anyway (and is such a core-language related
type) I recommend to stick with the current state.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change the class template <tt>match_results</tt> header synopsis, 28.10 [re.results] p4 as indicated:</p>

<blockquote><pre>
typedef const value_type&amp; const_reference;
typedef <del>const_reference</del><ins>value_type&amp;</ins> reference;
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="2308"></a>2308. Clarify container destructor requirements w.r.t. <tt>std::array</tt></h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-09-26 <b>Last modified:</b> 2014-02-13</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It has been suggested that Table 96 &mdash; "Container requirements" makes
confusing requirements for the destructor of <tt>std::array</tt>:
<p/>
"note: the destructor is applied to every element of <tt>a</tt>; all the memory is deallocated."
<p/>
Since <tt>std::array</tt> obtains no memory, there is none to deallocate,
arguably  making it unclear what the requirement means for <tt>std::array::~array()</tt>.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change in 23.2.1 [container.requirements.general], Table 96 &mdash; "Container requirements", 
the "Assertion/note/pre-/post-condition" for the expression "<tt>(&amp;a)-&gt;~X()</tt>" as indicated:</p>

<blockquote><p>
note: the destructor is applied to every element of <tt>a</tt>; <del>all the</del><ins>any</ins> memory 
<ins>obtained</ins> is deallocated.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2313"></a>2313. <tt>tuple_size</tt> should always derive from <tt>integral_constant&lt;size_t, N&gt;</tt></h3>
<p><b>Section:</b> 20.4.2.5 [tuple.helper] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 20.4.2.5 [tuple.helper], the "primary template" is depicted as:
</p>
<blockquote><pre>
template &lt;class... Types&gt;
class tuple_size&lt;tuple&lt;Types...&gt; &gt;
  : public integral_constant&lt;size_t, sizeof...(Types)&gt; { };
</pre></blockquote>
<p>
However, 20.3.4 [pair.astuple]/1-2 and 23.3.2.9 [array.tuple]/1-2 are underspecified, saying:
</p>
<blockquote><pre>
tuple_size&lt;pair&lt;T1, T2&gt; &gt;::value
</pre><blockquote>
<p>
<i>Returns:</i> Integral constant expression.
<p/>
<i>Value:</i> <tt>2</tt>.
</p></blockquote>
</blockquote>
<blockquote><pre>
tuple_size&lt;array&lt;T, N&gt; &gt;::value
</pre><blockquote>
<p>
<i>Return type:</i> integral constant expression.
<p/>
<i>Value:</i> <tt>N</tt>
</p></blockquote>
</blockquote>
<p>
They should be required to behave like the "primary template". This is more than a stylistic decision &mdash; it allows 
<tt>tuple_size</tt> to be passed to a function taking <tt>integral_constant</tt>.
<p/>
LWG <a href="lwg-defects.html#1118">1118</a> noticed this underspecification, but instead of correcting it, the resolution changed 
20.4.2.5 [tuple.helper]/3 to require <tt>tuple_size&lt;<i>cv</i> T&gt;</tt> to derive from 
<tt>integral_constant&lt;remove_cv&lt;decltype(TS::value)&gt;::type, TS::value&gt;</tt>. This is unnecessarily overgeneralized.  
<tt>tuple_size</tt> is primarily for tuples, where it is required to be <tt>size_t</tt>, and it has been extended to handle 
pairs and arrays, which (as explained above) should also be guaranteed to be <tt>size_t</tt>. <tt>tuple_size&lt;<i>cv</i> T&gt;</tt> 
works with <i>cv</i>-qualified tuples, pairs, arrays, and user-defined types that also want to participate in the <tt>tuple_size</tt> 
system. It would be far simpler and perfectly reasonable to expect that user-defined types supporting the "tuple-like protocol" 
should have <tt>tuple_sizes</tt> of <tt>size_t</tt>.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 20.3.4 [pair.astuple]/1-2 as indicated:</p>

<blockquote><pre>
<del>tuple_size&lt;pair&lt;T1, T2&gt; &gt;::value</del>
<ins>template &lt;class T1, class T2&gt;
struct tuple_size&lt;pair&lt;T1, T2&gt;&gt;
  : integral_constant&lt;size_t, 2&gt; { };</ins>
</pre><blockquote>
<p>
<del>-1- <i>Returns:</i> Integral constant expression.</del>
<p/>
<del>-2- <i>Value:</i> <tt>2</tt>.</del>
</p></blockquote>
</blockquote>
</li>

<li><p>Edit 23.3.2.9 [array.tuple]/1-2 as indicated:</p>

<blockquote><pre>
<del>tuple_size&lt;array&lt;T, N&gt; &gt;::value</del>
<ins>template &lt;class T, size_t N&gt;
struct tuple_size&lt;array&lt;T, N&gt;&gt;
  : integral_constant&lt;size_t, N&gt; { };</ins>
</pre><blockquote>
<p>
<del>-1- <i>Returns:</i> Integral constant expression.</del>
<p/>
<del>-2- <i>Value:</i> <tt>N</tt>.</del>
</p></blockquote>
</blockquote>
</li>

<li><p>Edit 20.4.2.5 [tuple.helper]/p1-p3 as indicated:</p>

<blockquote><pre>
<ins>template &lt;class T&gt; struct tuple_size;</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Remarks:</i> All specializations of <tt>tuple_size&lt;T&gt;</tt> shall meet the <tt>UnaryTypeTrait</tt> 
requirements (20.10.1 [meta.rqmts]) with a <tt>BaseCharacteristic</tt> of <tt>integral_constant&lt;size_t, N&gt;</tt> 
for some <tt>N</tt>.</ins>
</p>
</blockquote>
</blockquote>
<blockquote><pre>
template &lt;class... Types&gt;
struct tuple_size&lt;tuple&lt;Types...&gt; &gt;
  : integral_constant&lt;size_t, sizeof...(Types)&gt; { };
  
template &lt;size_t I, class... Types&gt;
class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
public:
  typedef TI type;
};
</pre><blockquote>
<p>
-1- <i>Requires:</i> <tt>I &lt; sizeof...(Types)</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.
<p/>
[&hellip;]
</p></blockquote>
</blockquote>
<blockquote><pre>
template &lt;class T&gt; class tuple_size&lt;const T&gt;;
template &lt;class T&gt; class tuple_size&lt;volatile T&gt;;
template &lt;class T&gt; class tuple_size&lt;const volatile T&gt;;
</pre><blockquote>
<p>
-3- Let <i>TS</i> denote <tt>tuple_size&lt;T&gt;</tt> of the <i>cv</i>-unqualified type <tt>T</tt>. Then each of the 
three templates shall meet the <tt>UnaryTypeTrait</tt> requirements (20.10.1 [meta.rqmts]) with a <tt>BaseCharacteristic</tt> of
</p>
<blockquote><pre>
integral_constant&lt;<del>remove_cv&lt;decltype(TS::value)&gt;::type</del><ins>size_t</ins>, TS::value&gt;
</pre></blockquote>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2314"></a>2314. <tt>apply()</tt> should return <tt>decltype(auto)</tt> and use <tt>decay_t</tt> before <tt>tuple_size</tt></h3>
<p><b>Section:</b> 20.5.1 [intseq.general] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The example in 20.5.1 [intseq.general]/2 depicts <tt>apply_impl()</tt> and <tt>apply()</tt> as returning <tt>auto</tt>.  
This is incorrect because it will trigger decay and will not preserve <tt>F</tt>'s return type. For example, if invoking the 
functor returns <tt>const int&amp;</tt>, <tt>apply_impl()</tt> and <tt>apply()</tt> will return <tt>int</tt>. <tt>decltype(auto)</tt> 
should be used for "perfect returning".
</p>
<p>
Additionally, this depicts <tt>apply()</tt> as taking <tt>Tuple&amp;&amp;</tt>, then saying "<tt>std::tuple_size&lt;Tuple&gt;::value</tt>". 
This is incorrect because when <tt>apply()</tt> is called with lvalue tuples, perfect forwarding will deduce <tt>Tuple</tt> to be <i>cv</i> 
<tt>tuple&amp;</tt>, but 20.4.2.5 [tuple.helper] says that <tt>tuple_size</tt> handles only <i>cv</i> <tt>tuple</tt>, not 
references to tuples.  Using <tt>remove_reference_t</tt> would avoid this problem, but so would <tt>decay_t</tt>, which has a 
significantly shorter name. (The additional transformations that <tt>decay_t</tt> does are neither beneficial nor harmful here.)
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit the example code in 20.5.1 [intseq.general]/2 as indicated:</p>

<blockquote><pre>
template&lt;class F, class Tuple, std::size_t... I&gt;
  <del>auto</del><ins>decltype(auto)</ins> apply_impl(F&amp;&amp; f, Tuple&amp;&amp; t, index_sequence&lt;I...&gt;) {
    return std::forward&lt;F&gt;(f)(std::get&lt;I&gt;(std::forward&lt;Tuple&gt;(t))...);
  }
template&lt;class F, class Tuple&gt;
  <del>auto</del><ins>decltype(auto)</ins> apply(F&amp;&amp; f, Tuple&amp;&amp; t) {
    using Indices = make_index_sequence&lt;std::tuple_size&lt;<ins>std::decay_t&lt;</ins>Tuple<ins>&gt;</ins>&gt;::value&gt;;
    return apply_impl(std::forward&lt;F&gt;(f), std::forward&lt;Tuple&gt;(t), Indices());
  }
</pre></blockquote>
</li>

</ol>





<hr>
<h3><a name="2315"></a>2315. <tt>weak_ptr</tt> should be movable</h3>
<p><b>Section:</b> 20.8.2.3 [util.smartptr.weak] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-13</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.weak">issues</a> in [util.smartptr.weak].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Like <tt>shared_ptr</tt>, <tt>weak_ptr</tt> should be movable to avoid unnecessary atomic increments/decrements of the weak refcount.
</p>

<p><i>[2014-02-13 Issaquah: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 20.8.2.3 [util.smartptr.weak]/1, class template <tt>weak_ptr</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  template&lt;class T&gt; class weak_ptr {
  public:
    typedef T element_type;

    <i>// 20.9.2.3.1, constructors</i>
    constexpr weak_ptr() noexcept;
    template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r) noexcept;
    weak_ptr(weak_ptr const&amp; r) noexcept;
    template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r) noexcept;
    <ins>weak_ptr(weak_ptr&amp;&amp; r) noexcept;
    template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt;&amp;&amp; r) noexcept;</ins>

    [&hellip;]

    <i>// 20.9.2.3.3, assignment</i>
    weak_ptr&amp; operator=(weak_ptr const&amp; r) noexcept;
    template&lt;class Y&gt; weak_ptr&amp; operator=(weak_ptr&lt;Y&gt; const&amp; r) noexcept;
    template&lt;class Y&gt; weak_ptr&amp; operator=(shared_ptr&lt;Y&gt; const&amp; r) noexcept;
    <ins>weak_ptr&amp; operator=(weak_ptr&amp;&amp; r) noexcept;
    template&lt;class Y&gt; weak_ptr&amp; operator=(weak_ptr&lt;Y&gt;&amp;&amp; r) noexcept;</ins>
  };
}
</pre></blockquote>
</li>

<li><p>Add the following new paragraphs at the end of sub-clause 20.8.2.3.1 [util.smartptr.weak.const]:</p>

<blockquote><pre>
<ins>weak_ptr(weak_ptr&amp;&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt;&amp;&amp; r) noexcept;</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Remark:</i> The second constructor shall not participate in overload resolution unless <tt>Y*</tt> is implicitly 
convertible to <tt>T*</tt>.</ins>
<p/>
<ins>-?- <i>Effects:</i> Move-constructs a <tt>weak_ptr</tt> instance from <tt>r</tt>.</ins>
<p/>
<ins>-?- <i>Postconditions:</i> <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt> shall be <em>empty</em>. 
<tt>r.use_count() == 0</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 20.8.2.3.3 [util.smartptr.weak.assign] as indicated:</p>

<blockquote><pre>
weak_ptr&amp; operator=(const weak_ptr&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr&amp; operator=(const weak_ptr&lt;Y&gt;&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr&amp; operator=(const shared_ptr&lt;Y&gt;&amp; r) noexcept;
</pre><blockquote>
<p>
-1- <i>Effects:</i> [&hellip;]
<p/>
-2- <i>Remarks:</i> [&hellip;]
<p/>
<ins>-?- <i>Returns:</i> <tt>*this</tt>.</ins>
</p>
</blockquote>
</blockquote>

<blockquote><pre>
<ins>weak_ptr&amp; operator=(weak_ptr&amp;&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr&amp; operator=(weak_ptr&lt;Y&gt;&amp;&amp; r) noexcept;</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Effects:</i> Equivalent to <tt>weak_ptr(std::move(r)).swap(*this)</tt>.</ins>
<p/>
<ins>-?- <i>Returns:</i> <tt>*this</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2316"></a>2316. <tt>weak_ptr::lock()</tt> should be atomic</h3>
<p><b>Section:</b> 20.8.2.3.5 [util.smartptr.weak.obs] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.weak.obs">issues</a> in [util.smartptr.weak.obs].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.8.2.2 [util.smartptr.shared]/4 says: "For purposes of determining the presence of a data race, member functions shall 
access and modify only the <tt>shared_ptr</tt> and <tt>weak_ptr</tt> objects themselves and not objects they refer to. Changes 
in <tt>use_count()</tt> do not reflect modifications that can introduce data races."  This requires <tt>shared_ptr/weak_ptr</tt> 
implementations to protect their strong and weak refcounts with atomic operations, without the Standardese having to say this 
elsewhere. However, 20.8.2.3.5 [util.smartptr.weak.obs]/5 describes <tt>weak_ptr::lock()</tt> with 
"<i>Returns:</i> <tt>expired() ? shared_ptr&lt;T&gt;() : shared_ptr&lt;T&gt;(*this)</tt>."  
Even after considering the blanket wording about 
data races, this specification is insufficient. If this conditional expression were literally implemented, the <tt>use_count()</tt> 
could change from nonzero to zero after testing <tt>expired()</tt>, causing <tt>shared_ptr&lt;T&gt;(*this)</tt> to throw 
<tt>bad_weak_ptr</tt> when the intention is for <tt>weak_ptr::lock()</tt> to return empty or nonempty without throwing &mdash; indeed, 
<tt>weak_ptr::lock()</tt> is marked as <tt>noexcept</tt>.</p>
<p>
We all know what <tt>weak_ptr::lock()</tt> should do, the Standardese just doesn't say it. 
<tt>shared_ptr(const weak_ptr&lt;Y&gt;&amp;)</tt>'s specification is not really affected because 
20.8.2.2.1 [util.smartptr.shared.const]/23-27 describes the behavior with English instead of code.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 20.8.2.3.5 [util.smartptr.weak.obs]/5 as indicated:</p>

<blockquote><pre>
shared_ptr&lt;T&gt; lock() const noexcept;
</pre>
<blockquote>
<p>
-5- <i>Returns:</i> <tt>expired() ? shared_ptr&lt;T&gt;() : shared_ptr&lt;T&gt;(*this)</tt><ins>, executed atomically</ins>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2317"></a>2317. The type property queries should be <tt>UnaryTypeTraits</tt> returning <tt>size_t</tt></h3>
<p><b>Section:</b> 20.10.5 [meta.unary.prop.query] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The sibling sections 20.10.4 [meta.unary], 20.10.6 [meta.rel], and 20.10.7 [meta.trans] respectively specify 
<tt>UnaryTypeTraits</tt>, <tt>BinaryTypeTraits</tt>, and <tt>TransformationTraits</tt>, as stated by each /2 paragraph.  However, 
20.10.5 [meta.unary.prop.query] is underspecified. <tt>alignment_of</tt>, <tt>rank</tt>, and <tt>extent</tt> are said to produce 
"Values", but the type of that Value is not specified, and the struct templates are not required to derive from <tt>integral_constant</tt>.  
Such derivation is more than stylistic &mdash; it allows the structs to be passed to functions taking <tt>integral_constant</tt>.
<p/>
<tt>alignment_of</tt> returns <tt>alignof(T)</tt> which is <tt>size_t</tt> (5.3.6 [expr.alignof]/2). <tt>extent</tt> returns 
an array bound, which is clearly <tt>size_t</tt>. <tt>rank</tt> returns "the number of dimensions" of an array, so any type could 
be chosen, with <tt>size_t</tt> being a reasonable choice. (Another choice would be <tt>unsigned int</tt>, to match <tt>extent</tt>'s 
template parameter <tt>I</tt>.)
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Following 20.10.5 [meta.unary.prop.query]/1 add a new paragraph as indicated:</p>

<blockquote><p>
<ins>Each of these templates shall be a <tt>UnaryTypeTrait</tt> (20.10.1 [meta.rqmts]) with a <tt>BaseCharacteristic</tt> of 
<tt>integral_constant&lt;size_t, Value&gt;</tt>.</ins>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2320"></a>2320. <tt>select_on_container_copy_construction()</tt> takes allocators, not containers</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-13</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.2.1 [container.requirements.general]/7 says "Copy constructors for these container types obtain an allocator by calling 
<tt>allocator_traits&lt;allocator_type&gt;::select_on_container_copy_construction</tt> on their first parameters."  However, 
20.7.8.2 [allocator.traits.members]/8 says that this takes <tt>const Alloc&amp;</tt>, not a container.  
23.2.1 [container.requirements.general]/7 goes on to say "Move constructors obtain an allocator by move construction from 
the allocator belonging to the container being moved." so we can follow that wording.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>In 23.2.1 [container.requirements.general]/7 change as indicated:</p>

<blockquote><p>
-7- Unless otherwise specified, all containers defined in this clause obtain memory using an allocator (see 17.6.3.5).
Copy constructors for these container types obtain an allocator by calling 
<tt>allocator_traits&lt;allocator_type&gt;::select_on_container_copy_construction</tt> on <del>their first 
parameters</del><ins>the allocator belonging to the container being copied</ins>. 
Move constructors obtain an allocator by move construction from the allocator belonging to the container being moved. [&hellip;]
</p></blockquote>
</li>

</ol>






<hr>
<h3><a name="2322"></a>2322. Associative(<tt>initializer_list</tt>, stuff) constructors are underspecified</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.2.4 [associative.reqmts] specifies both <tt>X(i,j)</tt> and <tt>X(i,j,c)</tt>, but only <tt>X(il)</tt>.  
23.4.4.1 [map.overview] declares "<tt>map(initializer_list&lt;value_type&gt;, const Compare&amp; = Compare(), 
const Allocator&amp; = Allocator());</tt>" but 23.4.4.2 [map.cons] intentionally doesn't explain it, relying 
on the big table's requirements. As a result, <tt>map(il, c)</tt>'s behavior is not actually specified by the Standard.  
(All of the other ordered associative containers also provide such constructors.)
<p/>
The unordered associative containers are similarly affected, although they have more arguments. (Again, the actual 
containers are correctly depicted with the desired constructors, their behavior just isn't specified.)
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 23.2.4 [associative.reqmts], Table 102 &mdash; "Associative container requirements", as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 102 &mdash; Associative container requirements (in addition to container) (continued)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>X(il);</tt>
</td>
<td>
<tt></tt>
</td>
<td>
Same as <tt>X(il.begin(), il.end())</tt>.
</td>
<td>
<del>s</del><ins>S</ins>ame as <tt>X(il.begin(), il.end())</tt>.
</td>
</tr>

<tr>
<td>
<ins><tt>X(il, c);</tt></ins>
</td>
<td>
<tt>&nbsp;</tt>
</td>
<td>
<ins>Same as <tt>X(il.begin(), il.end(), c)</tt>.</ins>
</td>
<td>
<ins>Same as <tt>X(il.begin(), il.end(), c)</tt>.</ins>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>
</li>

<li><p>Edit 23.2.5 [unord.req], Table 103 "Unordered associative container requirements", as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 103 &mdash; Unordered associative container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>X(il)</tt>
</td>
<td>
<tt>X</tt>
</td>
<td>
Same as <tt>X(il.begin(), il.end())</tt>.
</td>
<td>
Same as <tt>X(il.begin(), il.end())</tt>.
</td>
</tr>

<tr>
<td>
<ins><tt>X(il, n)</tt></ins>
</td>
<td>
<ins><tt>X</tt></ins>
</td>
<td>
<ins>Same as <tt>X(il.begin(), il.end(), n)</tt>.</ins>
</td>
<td>
<ins>Same as <tt>X(il.begin(), il.end(), n)</tt>.</ins>
</td>
</tr>

<tr>
<td>
<ins><tt>X(il, n, hf)</tt></ins>
</td>
<td>
<ins><tt>X</tt></ins>
</td>
<td>
<ins>Same as <tt>X(il.begin(), il.end(), n, hf)</tt>.</ins>
</td>
<td>
<ins>Same as <tt>X(il.begin(), il.end(), n, hf)</tt>.</ins>
</td>
</tr>

<tr>
<td>
<ins><tt>X(il, n, hf, eq)</tt></ins>
</td>
<td>
<ins><tt>X</tt></ins>
</td>
<td>
<ins>Same as <tt>X(il.begin(), il.end(), n, hf, eq)</tt>.</ins>
</td>
<td>
<ins>Same as <tt>X(il.begin(), il.end(), n, hf, eq)</tt>.</ins>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>

</li>

</ol>






<hr>
<h3><a name="2323"></a>2323. <tt>vector::resize(n, t)</tt>'s specification should be simplified</h3>
<p><b>Section:</b> 23.3.6.3 [vector.capacity], 23.3.3.3 [deque.capacity] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
First, 23.3.3.3 [deque.capacity]/4 and 23.3.6.3 [vector.capacity]/16 say that <tt>resize(size_type sz, const T&amp; c)</tt> 
"<i>Requires:</i> <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt> and <tt>CopyInsertable</tt> into <tt>*this</tt>."  
The <tt>CopyInsertable</tt> requirement is correct (because <tt>sz</tt> might be <tt>size() + 2</tt> or more), but the 
<tt>MoveInsertable</tt> requirement is redundant due to 23.2.1 [container.requirements.general]/13: "<tt>T</tt> is 
<tt>CopyInsertable</tt> into <tt>X</tt> means that, in addition to <tt>T</tt> being <tt>MoveInsertable</tt> into <tt>X</tt>, the [...]".  
(LWG <a href="lwg-defects.html#2033">2033</a>'s resolution said that this was "not redundant, because <tt>CopyInsertable</tt> is not necessarily a refinement 
of <tt>MoveInsertable</tt>" which was true at the time, but then LWG <a href="lwg-defects.html#2177">2177</a>'s resolution made it a refinement.)
<p/>
Second, 23.3.6.3 [vector.capacity]/17 says "<i>Remarks:</i> If an exception is thrown other than by the move constructor of a 
non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects." This is confusing because <tt>T</tt> is required to be 
<tt>CopyInsertable</tt>. (/14 says the same thing for <tt>resize(size_type sz)</tt>, where it is correct because that overload 
requires only <tt>MoveInsertable</tt> and <tt>DefaultInsertable</tt>.)
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 23.3.3.3 [deque.capacity]/4 as indicated:</p>

<blockquote><pre>
void resize(size_type sz, const T&amp; c);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-4- <i>Requires:</i> <tt>T</tt> shall be <del><tt>MoveInsertable</tt> into <tt>*this</tt> and</del> <tt>CopyInsertable</tt> into 
<tt>*this</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 23.3.6.3 [vector.capacity]/16+17 as indicated:</p>

<blockquote><pre>
void resize(size_type sz, const T&amp; c);
</pre><blockquote>
<p>
[&hellip;]
<p/>
-16- <i>Requires:</i> <tt>T</tt> shall be <del><tt>MoveInsertable</tt> into <tt>*this</tt> and</del> <tt>CopyInsertable</tt> into 
<tt>*this</tt>.
<p/>
-17- <i>Remarks:</i> If an exception is thrown <del>other than by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt></del> 
there are no effects.
</p>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2324"></a>2324. Insert iterator constructors should use <tt>addressof()</tt></h3>
<p><b>Section:</b> 24.5.2.2.1 [back.insert.iter.cons], 24.5.2.4.1 [front.insert.iter.cons], 24.5.2.6.1 [insert.iter.cons] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
24.5.2.2.1 [back.insert.iter.cons]/1, 24.5.2.4.1 [front.insert.iter.cons]/1, and 24.5.2.6.1 [insert.iter.cons]/1 
say "Initializes container with <tt>&amp;x</tt>", which doesn't defend against containers overloading <tt>operator&amp;()</tt>.  
Containers are now required to have such defenses for their elements, so we may as well be consistent here.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 24.5.2.2.1 [back.insert.iter.cons]/1 as indicated:</p>

<blockquote><pre>
explicit back_insert_iterator(Container&amp; x);
</pre><blockquote>
<p>
-1- <i>Effects:</i> Initializes <tt>container</tt> with <tt><del>&amp;x</del><ins>std::addressof(x)</ins></tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 24.5.2.4.1 [front.insert.iter.cons]/1 as indicated:</p>

<blockquote><pre>
explicit front_insert_iterator(Container&amp; x);
</pre><blockquote>
<p>
-1- <i>Effects:</i> Initializes <tt>container</tt> with <tt><del>&amp;x</del><ins>std::addressof(x)</ins></tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Edit 24.5.2.6.1 [insert.iter.cons]/1 as indicated:</p>

<blockquote><pre>
insert_iterator(Container&amp; x, typename Container::iterator i);
</pre><blockquote>
<p>
-1- <i>Effects:</i> Initializes <tt>container</tt> with <tt><del>&amp;x</del><ins>std::addressof(x)</ins></tt> and <tt>iter</tt> with <tt>i</tt>.
</p>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2329"></a>2329. <tt>regex_match()/regex_search()</tt> with <tt>match_results</tt> should forbid temporary strings</h3>
<p><b>Section:</b> 28.4 [re.syn] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-13</p>
<p><b>View all other</b> <a href="lwg-index.html#re.syn">issues</a> in [re.syn].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following code:
</p>
<blockquote><pre>
const regex r(R"(meow(\d+)\.txt)");
smatch m;
if (regex_match(dir_iter-&gt;path().filename().string(), m, r)) {
  DoSomethingWith(m[1]);
}
</pre></blockquote>
<p>
This occasionally crashes. The problem is that <tt>dir_iter-&gt;path().filename().string()</tt> returns a temporary string, 
so the <tt>match_results</tt> contains invalidated iterators into a destroyed temporary string.
<p/>
It's fine for <tt>regex_match/regex_search(str, reg)</tt> to accept temporary strings, because they just return <tt>bool</tt>. 
However, the overloads taking <tt>match_results</tt> should forbid temporary strings.
</p>

<p><i>[2014-02-13 Issaquah: Move as Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 28.4 [re.syn], header <tt>&lt;regex&gt;</tt> synopsis, as indicated:</p>

<blockquote><pre>
#include &lt;initializer_list&gt;

namespace std {

  [&hellip;]
  
  <i>// 28.11.2, function template regex_match:</i>
  [&hellip;]
  <ins>template &lt;class ST, class SA, class Allocator, class charT, class traits&gt; 
  bool regex_match(const basic_string&lt;charT, ST, SA&gt;&amp;&amp;, 
                   match_results&lt;
                     typename basic_string&lt;charT, ST, SA&gt;::const_iterator, 
                     Allocator&gt;&amp;, 
                   const basic_regex&lt;charT, traits&gt;&amp;, 
                   regex_constants::match_flag_type = 
                     regex_constants::match_default) = delete;</ins>

  <i>// 28.11.3, function template regex_search:</i>
  [&hellip;]
  <ins>template &lt;class ST, class SA, class Allocator, class charT, class traits&gt; 
  bool regex_search(const basic_string&lt;charT, ST, SA&gt;&amp;&amp;, 
                    match_results&lt;
                      typename basic_string&lt;charT, ST, SA&gt;::const_iterator, 
                      Allocator&gt;&amp;, 
                    const basic_regex&lt;charT, traits&gt;&amp;, 
                    regex_constants::match_flag_type = 
                      regex_constants::match_default) = delete;</ins>
  [&hellip;]
}
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="2330"></a>2330. <tt>regex("meow", regex::icase)</tt> is technically forbidden but should be permitted</h3>
<p><b>Section:</b> 28.5.1 [re.synopt] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-13</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.synopt">active issues</a> in [re.synopt].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.synopt">issues</a> in [re.synopt].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
28.5.1 [re.synopt]/1 says "A valid value of type <tt>syntax_option_type</tt> shall have exactly one of the elements 
<tt>ECMAScript</tt>, <tt>basic</tt>, <tt>extended</tt>, <tt>awk</tt>, <tt>grep</tt>, <tt>egrep</tt>, set." 
<p/>
This "exactly one" wording technically forbids passing <tt>icase</tt> by itself! Users should not be required to pass 
<tt>regex::ECMAScript | regex::icase</tt>. (Note that the cost of an additional check for no grammar being explicitly requested 
is completely irrelevant, as regex construction is so much more expensive.)
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Edit 28.5.1 [re.synopt] as indicated:</p>

<blockquote><p>
-1- The type <tt>syntax_option_type</tt> is an implementation-defined bitmask type (17.5.2.1.3). Setting its elements
has the effects listed in table 138. A valid value of type <tt>syntax_option_type</tt> shall have <del>exactly</del><ins>at most</ins> 
one of the <ins>grammar</ins> elements <tt>ECMAScript</tt>, <tt>basic</tt>, <tt>extended</tt>, <tt>awk</tt>, <tt>grep</tt>, 
<tt>egrep</tt>, set. <ins> If no grammar element is set, the default grammar is <tt>ECMAScript</tt>.</ins>
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2332"></a>2332. <tt>regex_iterator/regex_token_iterator</tt> should forbid temporary regexes</h3>
<p><b>Section:</b> 28.12 [re.iter] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2014-02-14</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Users can write "<tt>for(sregex_iterator i(s.begin(), s.end(), regex("meow")), end; i != end; ++i)</tt>", binding a temporary 
<tt>regex</tt> to <tt>const regex&amp;</tt> and storing a pointer to it. This will compile silently, triggering undefined behavior 
at runtime. We now have the technology to prevent this from compiling, like how <tt>reference_wrapper</tt> refuses to bind to 
temporaries.
</p>

<p><i>[2014-02-14 Issaquah meeting: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 28.12.1 [re.regiter]/1, class template <tt>regex_iterator</tt> synopsis, as indicated:</p>

<blockquote><pre>
regex_iterator();
regex_iterator(BidirectionalIterator a, BidirectionalIterator b,
  const regex_type&amp; re,
  regex_constants::match_flag_type m =
    regex_constants::match_default);
<ins>regex_iterator(BidirectionalIterator a, BidirectionalIterator b,
  const regex_type&amp;&amp; re,
  regex_constants::match_flag_type m =
    regex_constants::match_default) = delete;</ins>
</pre></blockquote>
</li>

<li><p>Change 28.12.2 [re.tokiter]/6, class template <tt>regex_token_iterator</tt> synopsis, as indicated:</p>

<blockquote><pre>
regex_token_iterator();
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp; re,
                     int submatch = 0,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default);
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp; re,
                     const std::vector&lt;int&gt;&amp; submatches,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default);
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp; re,
                     initializer_list&lt;int&gt; submatches,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default);
template &lt;std::size_t N&gt;
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp; re,
                     const int (&amp;submatches)[N],
                     regex_constants::match_flag_type m =
                       regex_constants::match_default);
<ins>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp;&amp; re,
                     int submatch = 0,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default) = delete;
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp;&amp; re,
                     const std::vector&lt;int&gt;&amp; submatches,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default) = delete;
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp;&amp; re,
                     initializer_list&lt;int&gt; submatches,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default) = delete;
template &lt;std::size_t N&gt;
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp;&amp; re,
                     const int (&amp;submatches)[N],
                     regex_constants::match_flag_type m =
                       regex_constants::match_default) = delete;</ins>
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="2339"></a>2339. Wording issue in <tt>nth_element</tt></h3>
<p><b>Section:</b> 25.4.2 [alg.nth.element] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2013-10-19 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.nth.element">issues</a> in [alg.nth.element].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The wording of <tt>nth_element</tt> says:
</p>
<blockquote><pre>
template&lt;class RandomAccessIterator&gt;
  void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                   RandomAccessIterator last);
</pre><blockquote>
<p>
After <tt>nth_element</tt> the element in the position pointed to by <tt>nth</tt> is the element that would be in that
position if the whole range were sorted. Also for every iterator <tt>i</tt> in the range <tt>[first,nth)</tt> and every
iterator <tt>j</tt> in the range <tt>[nth,last)</tt> it holds that: <tt>!(*j &lt; *i)</tt> or <tt>comp(*j, *i) == false</tt>.
</p>
</blockquote></blockquote>
<p>
That wording, to me, implies that there must be an element at '<tt>nth</tt>'.
However, gcc at least accepts <tt>nth == last</tt>, and returns without effect
(which seems like the sensible option).
<p/>
Is it intended to accept <tt>nth == last</tt>? If so, then I would suggest adding
this to the wording explicitly, say:
</p>
<blockquote>
<p>
After <tt>nth_element</tt> the element in the position pointed to by <tt>nth</tt><ins>, if any,</ins> is the element that
would be in that position if the whole range were sorted. Also for every iterator <tt>i</tt> in the range <tt>[first,nth)</tt>
and every iterator <tt>j</tt> in the range <tt>[nth,last)</tt> it holds that: <tt>!(*j &lt; *i)</tt> or <tt>comp(*j, *i) == false</tt>.
</p>
</blockquote>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Modify 25.4.2 [alg.nth.element]/1 as indicated:</p>

<blockquote><pre>
template&lt;class RandomAccessIterator&gt;
  void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                   RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                   RandomAccessIterator last, Compare comp);
</pre><blockquote>
<p>
-1- After <tt>nth_element</tt> the element in the position pointed to by <tt>nth</tt> is the element that would be in that
position if the whole range were sorted<ins>, unless <tt>nth == last</tt></ins>. Also for every iterator <tt>i</tt> in the 
range <tt>[first,nth)</tt> and every iterator <tt>j</tt> in the range <tt>[nth,last)</tt> it holds that: <tt>!(*j &lt; *i)</tt> 
or <tt>comp(*j, *i) == false</tt>.
</p>
</blockquote></blockquote>
</li>

</ol>





<hr>
<h3><a name="2341"></a>2341. Inconsistency between <tt>basic_ostream::seekp(pos)</tt> and <tt>basic_ostream::seekp(off, dir)</tt></h3>
<p><b>Section:</b> 27.7.3.5 [ostream.seeks] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Marshall Clow  <b>Opened:</b> 2013-10-21 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 27.7.3.5 [ostream.seeks], we have:
</p>
<blockquote><pre>
basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type pos);
</pre><blockquote>
<p>
-3- <i>Effects:</i> If <tt>fail() != true</tt>, executes <tt>rdbuf()-&gt;pubseekpos(pos, ios_base::out)</tt>. In case of failure, 
the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
<p/>
-4- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote></blockquote>
<blockquote><pre>
basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type off, ios_base::seekdir dir);
</pre><blockquote>
<p>
-5- <i>Effects:</i> If <tt>fail() != true</tt>, executes <tt>rdbuf()-&gt;pubseekoff(off, dir, ios_base::out)</tt>.
<p/>
-6- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote></blockquote>
<p>
The first call is required to set the <tt>failbit</tt> on failure, but the second is not
<p/>
So (given two ostreams, <tt>os1</tt> and <tt>os2</tt>) the following code (confusingly) works:
</p>
<blockquote><pre>
os1.seekp(-1);
assert(os1.fail());

os2.seekp(-1, std::ios_base::beg);
assert(os2.good());
</pre></blockquote>
<p>
Note that the description of <tt>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type off, ios_base::seekdir dir)</tt> in 
27.7.2.3 [istream.unformatted] p43 <em>does</em> require setting <tt>failbit</tt>.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Modify 27.7.3.5 [ostream.seeks]p5 as indicated:</p>

<blockquote><pre>
basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type off, ios_base::seekdir dir);
</pre><blockquote>
<p>
-5- <i>Effects:</i> If <tt>fail() != true</tt>, executes <tt>rdbuf()-&gt;pubseekoff(off, dir, ios_base::out)</tt>.
<ins>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).</ins>
<p/>
-6- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote></blockquote>
</li>

</ol>





<hr>
<h3><a name="2344"></a>2344. <tt>quoted()</tt>'s interaction with padding is unclear</h3>
<p><b>Section:</b> 27.7.6 [quoted.manip] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-11-01 <b>Last modified:</b> 2014-02-14</p>
<p><b>View other</b> <a href="lwg-index-open.html#quoted.manip">active issues</a> in [quoted.manip].</p>
<p><b>View all other</b> <a href="lwg-index.html#quoted.manip">issues</a> in [quoted.manip].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Given this code:
</p>
<blockquote><pre>
cout &lt;&lt; "[" &lt;&lt; left &lt;&lt; setfill('x') &lt;&lt; setw(20) &lt;&lt; R"("AB \"CD\" EF")" &lt;&lt; "]" &lt;&lt; endl;
cout &lt;&lt; "[" &lt;&lt; left &lt;&lt; setfill('y') &lt;&lt; setw(20) &lt;&lt; quoted(R"(GH "IJ" KL)") &lt;&lt; "]" &lt;&lt; endl;
</pre></blockquote>
<p>
The first line prints <tt>["AB \"CD\" EF"xxxxxx]</tt>. The second line should probably print <tt>["GH \"IJ\" KL"yyyyyy]</tt>, but 
27.7.6 [quoted.manip]/2 doesn't say whether or how <tt>quoted()</tt> should interact with padding. All it says is that 
</p>
<blockquote><p>
"<tt>out &lt;&lt; quoted(s, delim, escape)</tt> behaves as if it inserts the following characters into out using character 
inserter function templates (27.7.3.6.4)". 
</p></blockquote>
<p>
27.7.3.6.4 [ostream.inserters.character] specifies both single-character and null-terminated inserters, both referring to 
27.7.3.6.1 [ostream.formatted.reqmts]/3 for padding. Literally implementing <tt>quoted()</tt> with single-character inserters 
would result in padding being emitted after the first character, with undesirable effects for <tt>ios_base::left</tt>.
<p/>
It appears that 21.4.8.9 [string.io]/5 has the appropriate incantations to follow here. It says that <tt>os &lt;&lt; str</tt> 
</p>
<blockquote><p>
"Behaves as a formatted output function (27.7.3.6.1) of <tt>os</tt>. Forms a character sequence <tt>seq</tt>, initially consisting of the 
elements defined by the range <tt>[str.begin(), str.end())</tt>. Determines padding for <tt>seq</tt> as described in 27.7.3.6.1. 
Then inserts <tt>seq</tt> as if by calling <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of <tt>os.width()</tt> 
and <tt>str.size();</tt> then calls <tt>os.width(0)</tt>." 
</p></blockquote>
<p>
Additionally, saying that it's a "formatted output function" activates 27.7.3.6.1 [ostream.formatted.reqmts]/1's wording for 
sentry objects.
</p>

<p><i>[2014-02-14 Issaquah meeting: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Edit 27.7.6 [quoted.manip] as follows:</p>

<blockquote><pre>
template &lt;class charT&gt;
  unspecified quoted(const charT* s, charT delim=charT('"'), charT escape=charT('\\'));
template &lt;class charT, class traits, class Allocator&gt;
  unspecified quoted(const basic_string&lt;charT, traits, Allocator>&amp; s,
                     charT delim=charT('"'), charT escape=charT('\\'));
</pre><blockquote>
<p>
-2- <i>Returns:</i> An object of unspecified type such that if <tt>out</tt> is an instance of <tt>basic_ostream</tt> with member
type <tt>char_type</tt> the same as <tt>charT</tt>, then the expression <tt>out &lt;&lt; quoted(s, delim, escape)</tt> behaves
as <del>if it inserts the following characters into <tt>out</tt> using character inserter function templates (27.7.3.6.4),
which may throw <tt>ios_base::failure</tt> (27.5.3.1.1)</del><ins>a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]) 
of <tt>out</tt>. This forms a character sequence <tt>seq</tt>, initially consisting of the following elements</ins>:
</p>
<ul>
<li><p>
<tt>delim</tt>.
</p></li>
<li><p>
Each character in <tt>s</tt>. If the character to be output is equal to escape or <tt>delim</tt>, as determined by
<tt>operator==</tt>, first output <tt>escape</tt>.
</p></li>
<li><p>
<tt>delim</tt>.
</p></li>
</ul>
<p>
<ins>Let <tt>x</tt> be the number of elements initially in <tt>seq</tt>. Then padding is determined for <tt>seq</tt> as described 
in 27.7.3.6.1 [ostream.formatted.reqmts], <tt>seq</tt> is inserted as if by calling <tt>out.rdbuf()-&gt;sputn(seq, n)</tt>, where 
<tt>n</tt> is the larger of <tt>out.width()</tt> and <tt>x</tt>, and <tt>out.width(0)</tt> is called.</ins>
The expression <tt>out &lt;&lt; quoted(s, delim, escape)</tt> shall have type <tt>basic_ostream&lt;charT, traits&gt;&amp;</tt>
and value <tt>out</tt>.
</p>
</blockquote></blockquote>
</li>

</ol>






<hr>
<h3><a name="2346"></a>2346. <tt>integral_constant</tt>'s member functions should be marked <tt>noexcept</tt></h3>
<p><b>Section:</b> 20.10.3 [meta.help] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-11-05 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.help">issues</a> in [meta.help].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Obvious.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Edit 20.10.3 [meta.help] as indicated:</p>

<blockquote><pre>
namespace std {
  template&lt;class T, T v&gt;
  struct integral_constant {
    static constexpr T value = v;
    typedef T value_type;
    typedef integral_constant&lt;T,v&gt; type;
    constexpr operator value_type() const <ins>noexcept</ins> { return value; }
    constexpr value_type operator()() const <ins>noexcept</ins> { return value; }
  };
  [&hellip;]
}
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="2350"></a>2350. <tt>min</tt>, <tt>max</tt>, and <tt>minmax</tt> should be <tt>constexpr</tt></h3>
<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2013-12-15 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Having <tt>min</tt>, <tt>max</tt>, and <tt>minmax</tt> <tt>constexpr</tt> 
was a large part of the motivation to allow reference-to-const arguments for 
<tt>constexpr</tt> functions as per 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3039.pdf">N3039</a>.
Furthermore, <tt>initializer_lists</tt> are immutable and not-movable-from
for large part in order to allow using them in <tt>constexpr</tt> contexts
and other hoisting-optimizations. In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf">N3797</a> 
version of the draft none of these functions are <tt>constexpr</tt>, and they should be made
<tt>constexpr</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>In 25.1 [algorithms.general], header <tt>&lt;algorithm&gt;</tt> synopsis, and 25.4.7 [alg.min.max], 
change as indicated (add <tt>constexpr</tt> to every signature before <tt>min_element</tt>):</p>

<blockquote><pre>
template&lt;class T&gt; <ins>constexpr</ins> const T&amp; min(const T&amp; a, const T&amp; b);
template&lt;class T, class Compare&gt;
<ins>constexpr</ins> const T&amp; min(const T&amp; a, const T&amp; b, Compare comp);
[&hellip;]
template&lt;class T&gt;
<ins>constexpr</ins> T min(initializer_list&lt;T&gt; t);
template&lt;class T, class Compare>
<ins>constexpr</ins> T min(initializer_list&lt;T&gt; t, Compare comp);
[&hellip;]
template&lt;class T&gt; <ins>constexpr</ins> const T&amp; max(const T&amp; a, const T&amp; b);
template&lt;class T, class Compare&gt;
<ins>constexpr</ins> const T&amp; max(const T&amp; a, const T&amp; b, Compare comp);
[&hellip;]
template&lt;class T&gt;
<ins>constexpr</ins> T max(initializer_list&lt;T&gt; t);
template&lt;class T, class Compare>
<ins>constexpr</ins> T max(initializer_list&lt;T&gt; t, Compare comp);
[&hellip;]
template&lt;class T&gt; <ins>constexpr</ins> pair&lt;const T&amp;, const T&amp;&gt; minmax(const T&amp; a, const T&amp; b);
template&lt;class T, class Compare&gt;
<ins>constexpr</ins> pair&lt;const T&amp;, const T&amp;&gt; minmax(const T&amp; a, const T&amp; b, Compare comp);
[&hellip;]
template&lt;class T&gt;
<ins>constexpr</ins> pair&lt;T, T&gt; minmax(initializer_list&lt;T&gt; t);
template&lt;class T, class Compare>
<ins>constexpr</ins> pair&lt;T, T&gt; minmax(initializer_list&lt;T&gt; t, Compare comp);
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="2356"></a>2356. Stability of erasure in unordered associative containers</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Joaqu&iacute;n M L&oacute;pez Mu&ntilde;oz <b>Opened:</b> 2014-01-21 <b>Last modified:</b> 2014-02-13</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue <a href="lwg-defects.html#518">518</a> resolution for unordered associative containers, modelled after that of issue <a href="lwg-defects.html#371">371</a>, 
which is related to associative containers, states that insertion, erasure and rehashing preserve the relative ordering 
of equivalent elements. Unfortunately, this is not sufficient to guarantee the validity of code such as this:
</p>
<blockquote><pre>
std::unordered_multimap&lt;int, int&gt; m;
auto i = m.begin();
while (i != m.end()) {
  if (pred(i))
    m.erase(i++);
  else
    ++i;
}
</pre></blockquote>
<p>
(which is a direct translation from <tt>multimap</tt> to <tt>unordered_multimap</tt> of the motivating example in <a href="lwg-defects.html#371">371</a>), 
or even this:
</p>
<blockquote><pre>
std::unordered_multimap&lt;int, int&gt; m;
auto p = m.equal_range(k);
while (p.first != p.second) {
  if (pred(p.first))
    m.erase((p.first)++);
  else
    ++(p.first);
}
</pre></blockquote>
<p>
because the relative ordering of <em>non-equivalent</em> elements elements could potentially change after erasure (not that any actual 
implementation does that, anyway). Such an underspecification does not happen for regular associative containers, where the 
relative ordering of non-equivalent elements is kept by design.
</p>

<p><i>[2014-02-13 Issaquah: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Modify 23.2.5 [unord.req], p14 as indicated:</p>

<blockquote><p>
-14- The <tt>insert</tt> and <tt>emplace</tt> members shall not affect the validity of references to container elements, but may
invalidate all iterators to the container. The <tt>erase</tt> members shall invalidate only iterators and references
to the erased elements<ins>, and preserve the relative order of the elements that are not erased</ins>.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2357"></a>2357. Remaining "<tt>Assignable</tt>" requirement</h3>
<p><b>Section:</b> 25.3.13 [alg.partitions] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2014-02-01 <b>Last modified:</b> 2014-02-12</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.partitions">issues</a> in [alg.partitions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <i>Requires</i> element of <tt>partition_copy</tt> says (emphasis mine):
</p>
<blockquote><p>
<i>Requires</i>: <tt>InputIterator</tt>'s value type shall be <b><tt>Assignable</tt></b>, and &hellip;
</p></blockquote>
<p>
The C++03 term <tt>Assignable</tt> was replaced by <tt>CopyAssignable</tt>, remaining cleanups happened via LWG issue
<a href="lwg-closed.html#972">972</a>, but algorithm <tt>partition_copy</tt> was not affected at that time (during that time the requirements
of <tt>partition_copy</tt> didn't mention writable nor assignable, but I cannot track down at the moment where these requirements
had been added). Presumably this requirement should be corrected similarly to the approach used in <a href="lwg-closed.html#972">972</a>.
<p/>
Another question is whether a <tt>CopyAssignable</tt> is needed here, given the fact that we already require "writable to" an 
<tt>OutputIterator</tt> which is defined in 24.2.1 [iterator.requirements.general] and does already impose the necessary
statement
</p>
<blockquote><pre>
*out = *in;
</pre></blockquote>
<p>
Given the fact that <tt>partition_copy</tt> never touches any input value twice, there is no reason why anything more than
<i>writable to</i> should be necessary.
<p/>
The below suggested primary resolution does not respond to the second part of this question.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Modify 25.3.13 [alg.partitions], p12 as indicated:</p>

<blockquote><p>
-12- <i>Requires</i>: <tt>InputIterator</tt>'s value type shall be <tt><ins>Copy</ins>Assignable</tt>, and shall be writable 
to the <tt>out_true</tt> and <tt>out_false</tt> <tt>OutputIterator</tt>s, and shall be convertible to <tt>Predicate</tt>'s 
argument type. The input range shall not overlap with either of the output ranges.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2359"></a>2359. How does <tt>regex_constants::nosubs</tt> affect <tt>basic_regex::mark_count()</tt>?</h3>
<p><b>Section:</b> 28.5.1 [re.synopt] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-02-01 <b>Last modified:</b> 2014-02-12</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.synopt">active issues</a> in [re.synopt].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.synopt">issues</a> in [re.synopt].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As discussed in <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=35399">c++std-lib-35399</a> and its replies, 
I can see two possible interpretations of the effects of <tt>regex_constants::nosubs</tt>:
</p>
<ol style="list-style-type:decimal">
<li><p>
The effect of <tt>nosubs</tt> only applies during matching. Parentheses are
still recognized as marking a sub-expression by the <tt>basic_regex</tt>
compiler, and <tt>basic_regex::mark_count()</tt> still returns the number of
marked sub-expressions, but anything they match is not stored in the
results. This means it is not always true that <tt>results.size() == r.mark_count() + 1</tt> 
for a successful match.
</p></li>
<li><p>
<tt>nosubs</tt> affects how a regular expression is compiled, altering the
state of the <tt>std::basic_regex</tt> object so that <tt>mark_count()</tt> returns
zero. This also affects any subsequent matching.
</p></li>
</ol>
<p>
The definition of <tt>nosubs</tt> should make this clear.
<p/>
The wording in 28.5.1 [re.synopt]/1 seems to imply that <tt>nosubs</tt> only has
effects during matching, which is (1), but all known implementations
do (2). John Maddock confirmed that (2) was intended.
</p>

<p><i>[Issaquah 20014-10-11: Move to Immediate]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Apply the following edit to the table in 28.5.1 [re.synopt]/1</p>

<blockquote><p>
Specifies that <ins>no sub-expressions shall be considered to be
marked, so that</ins> when a regular expression is matched against a character container
sequence, no sub-expression matches shall be stored in the supplied
<tt>match_results</tt> structure.
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2360"></a>2360. <tt>reverse_iterator::operator*()</tt> is unimplementable</h3>
<p><b>Section:</b> 24.5.1.1 [reverse.iterator] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-02-07 <b>Last modified:</b> 2014-02-14</p>
<p><b>View all other</b> <a href="lwg-index.html#reverse.iterator">issues</a> in [reverse.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Previously, C++03 24.4.1.3.3 [lib.reverse.iter.op.star] required:
</p>
<blockquote>
<pre>
reference operator*() const;
</pre>
<blockquote>
<p>
<i>Effects</i>: 
</p>
<blockquote><pre>
Iterator tmp = current;
return *--tmp;
</pre></blockquote>
</blockquote></blockquote>
<p>
Now, N3797 24.5.1.1 [reverse.iterator] depicts:
</p>
<blockquote><pre>
private:
  Iterator deref_tmp; // exposition only
};
</pre></blockquote>
<p>
And 24.5.1.3.4 [reverse.iter.op.star] requires:
</p>
<blockquote>
<pre>
reference operator*() const;
</pre>
<blockquote>
<p>
<i>Effects</i>: 
</p>
<blockquote><pre>
deref_tmp = current;
--deref_tmp;
return *deref_tmp;
</pre></blockquote>
<p>
[<i>Note</i>: This operation must use an auxiliary member variable rather than a temporary variable to avoid 
returning a reference that persists beyond the lifetime of its associated iterator. (See 24.2.) &mdash; <i>end note</i>]
</p>
</blockquote></blockquote>

<p>
As written, this won't compile, because <tt>operator*()</tt> is <tt>const</tt> yet it's modifying (via assignment and decrement) 
the <tt>deref_tmp</tt> data member. So what happens if you say "<tt>mutable Iterator deref_tmp;</tt>"?
<p/>
DANGER: WARP CORE BREACH IMMINENT.
<p/>
The Standard requires <tt>const</tt> member functions to be callable from multiple threads simultaneously. This is 
17.6.5.9 [res.on.data.races]/3: "A C++ standard library function shall not directly or indirectly modify objects (1.10) 
accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's 
non-const arguments, including <tt>this</tt>."
<p/>
Multiple threads simultaneously modifying <tt>deref_tmp</tt> will trigger data races, so both <tt>mutable</tt> and some form of 
synchronization (e.g. <tt>mutex</tt> or <tt>atomic</tt>) are actually necessary!
<p/>
Here's what implementations currently do: Dinkumware/VC follows C++03 and doesn't use <tt>deref_tmp</tt> (attempting to 
implement it is what led me to file this issue). According to Jonathan Wakely, libstdc++ also follows C++03 (see 
<a href="http://gcc.gnu.org/PR51823">PR51823</a> which is suspended until LWG <a href="lwg-active.html#2204">2204</a> is resolved). According to 
Marshall Clow, libc++ uses <tt>deref_tmp</tt> with <tt>mutable</tt> but without synchronization, so it can trigger data races.
<p/>
This <tt>deref_tmp</tt> Standardese was added by LWG <a href="lwg-defects.html#198">198</a> "Validity of pointers and references unspecified after 
iterator destruction" and is present in Working Papers going back to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1638.pdf">N1638</a> 
on April 11, 2004, long before C++ recognized the existence of multithreading and developed the "<tt>const</tt> means simultaneously 
readable" convention.
<p/>
A related issue is LWG <a href="lwg-closed.html#1052">1052</a> "<tt>reverse_iterator::operator-&gt;</tt> should also support smart pointers" which 
mentioned the need to depict <tt>mutable</tt> in the Standardese, but it was resolved NAD Future and no change was made.
<p/>
Finally, LWG <a href="lwg-active.html#2204">2204</a> "<tt>reverse_iterator</tt> should not require a second copy of the base iterator" talked about 
removing <tt>deref_tmp</tt>, but without considering multithreading.
<p/>
I argue that <tt>deref_tmp</tt> must be removed. Its existence has highly undesirable consequences: either no synchronization 
is used, violating the Standard's usual multithreading guarantees, or synchronization is used, adding further costs for all 
users that benefit almost no iterators.
<p/>
<tt>deref_tmp</tt> is attempting to handle iterators that return references to things "inside themselves", which I usually call 
"stashing iterators" (as they have a secret stash). Note that these are very unusual, and are different from proxy iterators like 
<tt>vector&lt;bool&gt;::iterator</tt>.  While <tt>vector&lt;bool&gt;::iterator</tt>'s <tt>operator*()</tt> does not return a true 
reference, it refers to a bit that is unrelated to the iterator's lifetime.
</p>

<p><i>[2014-02-14 Issaquah meeting: Move to Immediate]</i></p>

<p>
Strike superfluous note to avoid potential confusion, and move to Immediate.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3797.</p>

<ol>
<li><p>Change class template <tt>reverse_iterator</tt> synopsis, 24.5.1.1 [reverse.iterator], as indicated:</p>

<blockquote><pre>
[&hellip;]
protected:
  Iterator current;
<del>private:
  Iterator deref_tmp; // exposition only</del>
};
</pre></blockquote>
</li>

<li><p>Change 24.5.1.3.4 [reverse.iter.op.star] as indicated:</p>

<blockquote><pre>
reference operator*() const;
</pre>
<blockquote>
<p>
-1- <i>Effects</i>:
</p>
<blockquote><pre>
<del>deref_tmp = current;
--deref_tmp;
return *deref_tmp;</del>
<ins>Iterator tmp = current;
return *--tmp;</ins>
</pre></blockquote>
<p>
<del>-2- [<i>Note</i>: This operation must use an auxiliary member variable rather than a temporary variable to
avoid returning a reference that persists beyond the lifetime of its associated iterator. (See 24.2.) &mdash; <i>end note</i>]</del>
</p>
</blockquote></blockquote>
</li>
</ol>






</body>
</html>
