<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Library Issues to be moved in Kona</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>
<h1>C++ Standard Library Issues to be moved in Kona</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P0165R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2015-10-23 at 22:10:34 UTC</p>
</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">Marshall Clow &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h2>Ready Issues</h2>
<hr>
<h3><a name="1169" href="#1169">1169.</a> <tt>num_get</tt> not fully compatible with <tt>strto*</tt></h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As specified in the latest draft,
<a 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
<code>num_get</code> is still not fully compatible with the following C
functions: <code>strtoul</code>, <code>strtoull</code>, 
<code>strtof</code> and
<code>strtod</code>.
</p>
<p>
In C, when conversion of a string to an unsigned integer type falls 
outside the
representable range, <code>strtoul</code> and <code>strtoull</code> return
<code>ULONG_MAX</code> and <code>ULLONG_MAX</code>, respectively, 
regardless
whether the input field represents a positive or a negative value.
On the other hand, the result of <code>num_get</code> conversion of 
negative
values to unsigned integer types is zero. This raises a compatibility 
issue.
</p>
<p>
Moreover, in C, when conversion of a string to a floating-point type falls
outside the representable range, <code>strtof</code>, <code>strtod</code> 
and
<code>strtold</code> return <code>&plusmn;HUGE_VALF</code>,
<code>&plusmn;HUGE_VAL</code> and <code>&plusmn;HUGE_VALL</code>, respectively.
On the other hand, the result of <code>num_get</code> conversion of such
out-of-range floating-point values results in the most positive/negative
representable value.
Although many C library implementations do implement <code>HUGE_VAL</code>
(etc.) as the highest representable (which is, usually, the infinity), 
this isn't required by the C standard. The C library specification makes no
statement regarding the value of <code>HUGE_VAL</code> and friends, which
potentially raises the same compatibility issue as in the above case of
unsigned integers.
In addition, neither C nor C++ define symbolic constants for the maximum
representable floating-point values (they only do so only for the maximum
representable <i>finite</i> floating-point values), which raises a 
usability
issue (it would be hard for the programmer to check the result of
<code>num_get</code> against overflow).
</p>
<p>
As such, we propose to adjust the specification of <code>num_get</code> to
closely follow the behavior of all of its underlying C functions.
</p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote><p>
Some concern that this is changing the specification for an existing C++03 function, but it was 
pointed out that this was underspecified as resolved by issue 23.  This is clean-up for that 
issue in turn. Some concern that we are trying to solve the same problem in both clause 22 and 27.
</p>
<p>
Bill: There's a change here as to whether val is stored to in an error case.
</p>
<p>
Pablo: Don't think this changes whether val is stored to or not, but changes the value that is stored.
</p>
<p>
Bill: Remembers having skirmishes with customers and testers as to whether val is stored to, and the resolution was not to store in error cases.
</p>
<p>
Howard: Believes since C++03 we made a change to always store in overflow.
</p>
<p>
Everyone took some time to review the issue.
</p>
<p>
Pablo: C++98 definitely did not store any value during an error condition.
</p>
<p>
Dietmar: Depends on the question of what is considered an error, and whether overflow is an error or not, which was the crux of LWG 23.
</p>
<p>
Pablo: Yes, but given the "zero, if the conversion function fails to convert the entire field", we are requiring every error condition to store.
</p>
<p>
Bill: When did this happen?
</p>
<p>
Alisdair: One of the last two or three meetings.
</p>
<p>
Dietmar: To store a value in case of failure is a very bad idea.
</p>
<p>
Move to Open, needs more study.
</p>
</blockquote>

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


<p>Move to deferred</p>

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


<p>
The proposed wording looks good, no-one sure why this was held back before.  Move to Review.
</p>


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

<p>
Move to Open.
</p>
<p>
THe issues is what to do with <tt>-1</tt>.  Should it match 'C' or do the "sane" thing.
A fix here changes behavior, but is probably what we want.
</p>
<p>
Pablo to provide wording, with help from Howard.
</p>

<p><i>[2015-05-06 Lenexa: Move to Ready]</i></p>

<p>STL: I like that this uses strtof, which I think is new in C99. that avoids truncation from using atof. I have another issue ...</p>
<p>MC: yes LWG 2403 (stof should call strtof)</p>
<p>PJP: the last line is horrible, you don't assign to err, you call setstate(ios_base::failbit). Ah, no, this is inside num_get so the caller does the setstate.</p>
<p>MC: we need all these words. are they the right words?</p>
<p>JW: I'd like to take a minute to check my impl. Technically this implies a change in behaviour (from always using strtold and checking the extracted floating point value, to using the right function). Oh, we already do exactly this.</p>
<p>MC: Move to Ready</p>
<p>6 in favor, none opposed, 1 abstention</p>


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

<p>
Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:
</p>
<blockquote>
<p>
<b>Stage 3:</b>
The sequence of <code>char</code>s accumulated in stage 2 (the field) is
converted to a numeric value by the rules of one of the functions declared in
the header <code>&lt;cstdlib&gt;</code>:
</p>
<ul>
<li>For a signed integer value, the function <code>strtoll</code>.</li>
<li>For an unsigned integer value, the function <code>strtoull</code>.</li>
<li><ins>For a <code>float</code> value, the function
    <code>strtof</code>.</ins></li>
<li><ins>For a <code>double</code> value, the function
    <code>strtod</code>.</ins></li>
<li>For a <del>floating-point</del> <ins><code>long double</code></ins>
    value, the function <code>strtold</code>.</li>
</ul>
<p>
The numeric value to be stored can be one of:
</p>
<ul>
<li>zero, if the conversion function fails to convert the entire field.
    <del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li>the most positive <ins>(or negative)</ins> representable value, if
    the field <ins>to be converted to a signed integer type</ins> represents a
    value too large positive <ins>(or negative)</ins> to be represented in
    <code>val</code>.
    <del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li><del>the most negative representable value or zero for an unsigned integer
    type, if the field represents a value too large negative to be represented
    in <code>val</code>.
    <code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
<li><ins>the most positive representable value, if the field to be converted to
    an unsigned integer type represents a value that cannot be represented in
    <code>val</code>.</ins></li>
<li>the converted value, otherwise.</li>
</ul>
<p>
The resultant numeric value is stored in <code>val</code>.
<ins>If the conversion function fails to convert the entire field, or if the
field represents a value outside the range of representable values,
<code>ios_base::failbit</code> is assigned to <code>err</code>.</ins>
</p>
</blockquote>






<hr>
<h3><a name="2072" href="#2072">2072.</a> Unclear wording about capacity of temporary buffers</h3>
<p><b>Section:</b> 20.7.11 [temporary.buffer] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Kazutoshi Satoda <b>Opened:</b> 2011-08-10 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all other</b> <a href="lwg-index.html#temporary.buffer">issues</a> in [temporary.buffer].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to 20.7.11 [temporary.buffer] p1+2:

</p><blockquote><pre>
template &lt;class T&gt;
pair&lt;T*, ptrdiff_t&gt; get_temporary_buffer(ptrdiff_t n) noexcept;
</pre><blockquote><p>
-1- <i>Effects</i>: Obtains a pointer to storage sufficient to store up to <tt>n</tt> adjacent <tt>T</tt> 
objects. It is implementation-defined whether over-aligned types are supported (3.11).
<p/>
-2- <i>Returns</i>: A pair containing the buffer's address and capacity (in the units of <tt>sizeof(T)</tt>), 
or a pair of 0 values if no storage can be obtained or if <tt>n &lt;= 0</tt>.
</p></blockquote></blockquote>
<p>
I read this as prohibiting to return a buffer of which capacity is less than <tt>n</tt>, because 
such a buffer is not sufficient to store <tt>n</tt> objects.
<p/>
The corresponding description in <a href="http://www.sgi.com/tech/stl/get_temporary_buffer.html">SGI STL</a> 
is clear on this point, but I think it is a bit too verbose:
</p>

<blockquote class="note"><p>
(for the return value, a pair <tt>P</tt>) [...] the buffer pointed to by <tt>P.first</tt> is large enough 
to hold <tt>P.second</tt> objects of type <tt>T</tt>. <tt>P.second</tt> is greater than or equal to 0, 
and less than or equal to <tt>len</tt>.
</p></blockquote>

<p>
There seems to be two different targets of the "up to n" modification:
The capacity of obtained buffer, and the actual number that the caller
will store into the buffer.
<p/>
First I read as the latter, and got surprised seeing that libstdc++
implementation can return a smaller buffer. I started searching about
<tt>get_temporary_buffer()</tt>. After reading a quote from TC++PL at
<a href="http://stackoverflow.com/questions/3264299/why-do-i-need-stdget-temporary-buffer">stackoverflow</a>, 
I realized that the former is intended.
<p/>
Such misinterpretation seems common:
</p>
<ul>
<li>The above question is likely started from same misinterpretation.</li>
<li><p>JIS standard (Japanese translation of ISO&#47;IEC standard) says nothing
    like "up to". I think the editor misinterpreted the original wording,
    and omitted words for "up to" as it is redundant. (If a buffer is
    sufficient to store <tt>n</tt> objects, it is also sufficient to store
    up to <tt>n</tt> objects.)</p></li>
<li><p>Rogue Wave implementation doesn't return smaller buffer, instead, it
    can return larger buffer on some circumstances. Apache 
	<a href="http://stdcxx.apache.org/">STDCXX</a> is a derived version of that
    implementation, and <a href="https://stdcxx.apache.org/doc/stdlibref/get-temporary-buffer.html">publicly accessible</a>:
</p>
<blockquote class="note"><p>
Specializations of the <tt>get_temporary_buffer()</tt> function template
attempt to allocate a region of storage sufficiently large to store at
least <tt>n</tt> adjacent objects of type <tt>T</tt>.
</p></blockquote>
<p>
I know one commercial compiler package based on Rogue Wave implementation, 
and its implementation is essentially same as the above.
</p>
</li>
</ul>

<p><i>[2014-05-18, Daniel comments and suggests concrete wording]</i></p>


<p>
The provided wording attempts to clarify the discussed capacity freedom, but it also makes it clearer that the returned
memory is just "raw memory", which is currently not really clear. In addition the wording clarifies that the deallocating
<tt>return_temporary_buffer</tt> function does not throw exceptions, which I believe is the intention when the preconditions
of the functions are satisfied. Then, my understanding is that we can provide to <tt>return_temporary_buffer</tt> a
null pointer value if that was the value, <tt>get_temporary_buffer()</tt> had returned. Furthermore, as STL noticed, the current 
wording seemingly allows multiple invocations of <tt>return_temporary_buffer</tt> with the same value returned by 
<tt>get_temporary_buffer</tt>; this should be constrained similar to the wording we have for <tt>operator delete</tt> (unfortunately
we miss such wording for allocators).
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
MC: move to ready? in favor: 14, opposed: 0, abstain: 0 
</p>


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

<ol><li><p>Change 20.7.11 [temporary.buffer] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt;
  pair&lt;T*, ptrdiff_t&gt; get_temporary_buffer(ptrdiff_t n) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: <ins>Obtains a pointer to uninitialized, contiguous storage for <tt><i>N</i></tt> adjacent objects of type 
<tt>T</tt>, for some non-negative number <tt><i>N</i></tt>.</ins><del>Obtains a pointer to storage sufficient 
to store up to <tt>n</tt> adjacent <tt>T</tt> objects.</del> It is implementation-defined whether over-aligned types are supported (3.11).
<p/>
<ins>-?- <i>Remarks</i>: Calling <tt>get_temporary_buffer</tt> with a positive number <tt>n</tt> is a non-binding request to return 
storage for <tt>n</tt> objects of type <tt>T</tt>. In this case, an implementation is permitted to return instead storage for a 
non-negative number <tt><i>N</i></tt> of such objects, where <tt><i>N</i> != n</tt> (including <tt><i>N</i> == 0</tt>). [<i>Note</i>: The 
request is non-binding to allow latitude for implementation-specific optimizations of its memory management. &mdash; <i>end note</i>].</ins>
<p/>
-2- <i>Returns</i>: <ins>If <tt>n &lt;= 0</tt> or if no storage could be obtained, returns a pair <tt>P</tt> such that <tt>P.first</tt>
is a null pointer value and <tt>P.second == 0</tt>; otherwise returns a pair <tt>P</tt> such that <tt>P.first</tt> refers to the 
address of the uninitialized storage and <tt>P.second</tt> refers to its capacity <tt><i>N</i></tt> (in the units of 
<tt>sizeof(T)</tt>).</ins><del>A <tt>pair</tt> containing the buffer's address and capacity (in the units of <tt>sizeof(T)</tt>), or a 
pair of 0 values if no storage can be obtained or if <tt>n &lt;= 0</tt>.</del>
</p>
</blockquote>

<pre>
template &lt;class T&gt; void return_temporary_buffer(T* p);
</pre>
<blockquote>
<p>
-3- <i>Effects</i>: Deallocates the <del>buffer to which <tt>p</tt> points</del><ins>storage referenced by <tt>p</tt></ins>.
<p/>
-4- <i>Requires</i>: <del>The buffer shall have been previously allocated by</del><ins><tt>p</tt> shall be a pointer value 
returned by an earlier call to</ins> <tt>get_temporary_buffer</tt> <ins>which has not been invalidated by an intervening call to
<tt>return_temporary_buffer(T*)</tt></ins>.
<p/>
<ins>-?- <i>Throws</i>: Nothing.</ins>
</p>
</blockquote>

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






<hr>
<h3><a name="2101" href="#2101">2101.</a> Some transformation types can produce impossible types</h3>
<p><b>Section:</b> 20.10.7 [meta.trans] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-11-18 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Table 53 &mdash; "Reference modifications" says in regard to the type trait 
<tt>add_lvalue_reference</tt> (emphasize mine)
</p>

<blockquote>
<p>
If <tt>T</tt> names an object or <strong>function</strong> type then the member typedef type
shall name <tt>T&amp;</tt>;
</p>
</blockquote>

<p>
The problem with this specification is that function types with <i>cv</i>-qualifier or <i>ref</i>-qualifier, 
like
</p>
<blockquote><pre>
void() const
void() &amp;
</pre></blockquote>
<p>
are also affected by the first part of the rule, but this would essentially mean, that
instantiating <tt>add_lvalue_reference</tt> with such a type would attempt to form
a type that is not defined in the C++ type system, namely
</p>
<blockquote><pre>
void(&amp;)() const
void(&amp;)() &amp;
</pre></blockquote>
<p>
The general policy for <i>TransformationTrait</i>s is to define always some meaningful 
mapping type, but this does not hold for <tt>add_lvalue_reference</tt>, <tt>add_rvalue_reference</tt>,
and in addition to these two for <tt>add_pointer</tt> as well. The latter one would 
attempt to form the invalid types
</p>
<blockquote><pre>
void(*)() const
void(*)() &amp;
</pre></blockquote>
<p>
A possible reason why those traits were specified in this way is that in C++03 (and that means
for TR1), <i>cv</i>-qualifier were underspecified in the core language and several compilers
just ignored them during template instantiations. This situation became fixed by adopting
CWG issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#295">295</a> and 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#547">547</a>.
<p/>
While there is possibly some core language clarification needed (see reflector messages
starting from c++std-core-20740), it seems also clear that the library should fix the
specification. The suggested resolution follows the style of the specification of the
support concepts <tt>PointeeType</tt> and <tt>ReferentType</tt> defined in 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>.
</p>


<p><i>[2012-02-10, Kona]</i></p>

<p>
Move to NAD.
</p>
<p>
These cv- and ref-qualified function types are aberrations in the type system, and do
not represent any actual entity defined by the language.  The notion of cv- and ref-
qualification applies only to the implicit <tt>*this</tt> reference in a member function.
</p>
<p>
However, these types can be produced by quirks of template metaprogramming, the question
remains what the library should do about it.  For example, <tt>add_reference</tt> returns
the original type if passed a reference type, or a <tt>void</tt> type.  Conversely,
<tt>add_pointer</tt> will return a pointer to the referenced type when passed a reference.
</p>
<p>
It is most likely that the 'right' answer in any case will depend on the context that the
question is being asked, in terms of forming these obscure types.  The best the LWG can
do is allow an error to propagate back to the user, so they can provide their own meaningful
answer in their context - with additional metaprogramming on their part.  The consensus is
that if anyone is dangerous enough with templates to get themselves into this problem, they
will also have the skills to resolve the problem themselves.  This is not going to trip up
the non-expert developer.
</p>
<p>
Lastly, it was noted that this problem arises only because the language is inconsistent in
providing us these nonsense types that do no really represent anything in the language.
There may be some way Core or Evolution could give us a more consistent type system so that
the LWG does not need to invent an answer at all, should this question need resolving.  This
is another reason to not specify anything at the LWG trait level at this time, leaving the
other working groups free to produce the 'right' answer that we can then follow without
changing the meaning of existing, well-defined programs.
</p>

<p><i>[2012-02-10, post-Kona]</i></p>

<p>
Move back to Open. Daniel is concerned that this is not an issue we can simply ignore,
further details to follow.
</p>

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

<p>
This issue really should be resolved as a defect: First, the argument that "forming these obscure types"
should "allow an error to propagate" is inconsistent with the exact same "obscure type" that would be formed
when <tt>std::add_lvalue_reference&lt;void&gt;</tt> wouldn't have an extra rules for <tt>void</tt> types, which
also cannot form references. The originally proposed resolution attempts to apply the same solution for the same 
common property of <tt>void</tt> types and function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier.
These functions had the property of <tt>ReferentType</tt> during concept time (see 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#749">CWG 749</a> bullet three for the final 
wording).
<p/>
Core issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1417">CWG 1417</a> has clarified
that any attempt to form a reference of a pointer to a function type with <em>cv</em>-qualifiers or 
<em>ref</em>-qualifier is ill-formed. Unfortunately, many compilers don't implement this yet.
<p/>
I also would like to warn about so-called "obscure" types: The problem is that these can occur as the side effect
of finding a best match overload of function templates, where this type is exactly correct for one of these
overloads, but causes a deep (not-sfinae-friendly) error for others where one of these traits are part of the 
signature.
<p/>
Existing experience with <tt>void</tt> types shows, that this extra rule is not so unexpected. Further, any usage 
of the result types of these traits as argument types or return types of functions would make these ill-formed 
(and in a template context would be sfinaed away), so the expected effects are rarely unnoticed. Checking
all existing explicit usages of the traits <tt>add_rvalue_reference</tt>, <tt>add_lvalue_reference</tt>, and
<tt>add_pointer</tt> didn't show any example where the error would be silent: <tt>add_rvalue_reference</tt>
is used to specify the return value of <tt>declval()</tt> and the instantiation of <tt>declval&lt;void() const&gt;()</tt>
would be invalid, because of the attempt to return a function type. Similarly, <tt>add_lvalue_reference</tt>
is used to specify the return type of <tt>unique_ptr&lt;T&gt;::operator*()</tt>. Again, any instantiation with 
<tt>void() const</tt> wouldn't remain unnoticed. The trait <tt>add_pointer</tt> is used to specify the trait
<tt>std::decay</tt> and this is an interesting example, because it is well-formed when instantiated with <tt>void</tt> 
types, too, and is heavily used throughout the library specification. All use-cases would not be negatively affected 
by the suggested acceptance of function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier, because they involve 
types that are either function arguments, function parameters or types were references are formed from.
<p/>
The alternative would be to add an additional extra rule that doesn't define a type member 'type' when
we have a function type with <em>cv</em>-qualifiers or <em>ref</em>-qualifier. This is better than the
current state but it is not superior than the proposal to specify the result as the original type, because
both variants are sfinae-friendly. A further disadvantage of the "non-type" approach here would be that any
usage of <tt>std::decay</tt> would require special protection against these function types, because 
instantiating <tt>std::decay&lt;void() const&gt;</tt> again would lead to a deep, sfinae-unfriendly error.
<p/>
The following example demonstrates the problem: Even though the second <tt>f</tt> template is the best final
match here, the first one will be instantiated. During that process <tt>std::decay&lt;T&gt;::type</tt>
becomes instantiated as well and will raise a deep error, because as part of the implementation the trait
<tt>std::add_pointer&lt;void() const&gt;</tt> becomes instantiated:
</p>
<blockquote><pre>
#include &lt;type_traits&gt;

template&lt;class T&gt;
typename std::decay&lt;T&gt;::type f(T&amp;&amp; t);

template&lt;class T, class U&gt;
U f(U u);

int main() {
  f&lt;void() const&gt;(0);
}
</pre></blockquote>
<p>
When the here proposed resolution would be applied this program would be well-formed and selects the expected function.
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>
<li><p>Change Table 53 &mdash; "Reference modifications" in 20.10.7.2 [meta.trans.ref] as indicated:</p>

<table border="1">
<caption>Table 53 &mdash; Reference modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

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

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_lvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names an object <tt>type</tt> or <ins>if <tt>T</tt> names a</ins> function type <ins>that does not have<br/>
<i>cv</i>-qualifiers or a <i>ref</i>-qualifier</ins> then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;</tt>; otherwise, if <tt>T</tt> names a type "rvalue reference to <tt>T1</tt>" then<br/>
the member typedef <tt>type</tt> shall name <tt>T1&amp;</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>.
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_rvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names an object <tt>type</tt> or <ins>if <tt>T</tt> names a</ins> function type <ins>that does not have<br/>
<i>cv</i>-qualifiers or a <i>ref</i>-qualifier</ins> then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;&amp;</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>. [<i>Note</i>: This rule reflects<br/>
the semantics of reference collapsing (8.3.2 [dcl.ref]). For example, when a type <tt>T</tt><br/>
names a type <tt>T1&amp;</tt>, the type <tt>add_rvalue_reference&lt;T&gt;::type</tt> is not an<br/>
rvalue reference. &mdash; <i>end note</i>]
</td>
</tr>
</table>

</li>

<li><p>Change Table 56 &mdash; "Pointer modifications" in 20.10.7.5 [meta.trans.ptr] as indicated:</p>

<table border="1">
<caption>Table 56 &mdash; Pointer modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

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

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct add_pointer;</tt>
</td>
<td>
<del>The member typedef <tt>type</tt> shall name the same type as</del><br/>
<ins>If <tt>T</tt> names a function type that has <i>cv</i>-qualifiers or a <i>ref</i>-qualifier<br/>
then the member typedef <tt>type</tt> shall name <tt>T</tt>; otherwise, it<br/> 
shall name the same type as</ins> <tt>remove_reference&lt;T&gt;::type*</tt>.
</td>
</tr>

</table>

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

<p>
The following revised proposed resolution defines - in the absence of a proper core language definition - a new
term <em>referenceable type</em> as also suggested by the resolution for LWG <a href="lwg-defects.html#2196">2196</a> as an
umbrella of the negation of <tt>void</tt> types and function types with <em>cv</em>-qualifiers or <em>ref</em>-qualifier. 
This simplifies and minimizes the requires wording changes.
</p>

<p><i>[
2013-09-26, Daniel synchronizes wording with recent draft
]</i></p>


<p><i>[
2014-05-18, Daniel synchronizes wording with recent draft and comments
]</i></p>


<p>
My impression is that this urgency of action this issue attempts to point out is partly caused by the fact that even for
the most recent C++14 compilers the implementations have just recently changed to adopt the core wording. Examples for these
are bug reports to <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182">gcc</a> or 
<a href="http://llvm.org/bugs/show_bug.cgi?id=19742">clang</a>.
<p/>
Occasionally the argument has been presented to me that the suggested changes to the traits affected by this issue would
lead to irregularities compared to other traits, especially the lack of guarantee that <tt>add_pointer</tt> might not return
a pointer or that <tt>add_(l/r)value_reference</tt> might not return a reference type. I would like to point out that this
kind of divergence is actually already present in most <tt>add/remove</tt> traits: For example, we have no guarantee that
<tt>add_const</tt> returns a const type (Reference types or function types get special treatments), or that <tt>add_rvalue_reference</tt>
returns an rvalue-reference (e.g. when applied to an lvalue-reference type).
<p/>
Zhihao Yuan brought to my attention, that the originally proposing paper 
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2002/n1345.html">N1345</a> carefully discussed these design choices.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
MC: move to Ready: in favor: 16, opposed: 0, abstain: 1<br/>
STL: have libstdc++, libc++ implemented this? we would need to change your implementation<br/>
</p>


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

<ol>
<li><p>Change Table 53 &mdash; "Reference modifications" in 20.10.7.2 [meta.trans.ref] as indicated:</p>

<table border="1">
<caption>Table 53 &mdash; Reference modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

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

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_lvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names <del>an object or function type</del><ins>a referenceable type</ins><br/>
then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;</tt>; otherwise, <del>if <tt>T</tt> names a type "rvalue reference to <tt>T1</tt>" then<br/>
the member typedef <tt>type</tt> shall name <tt>T1&amp;</tt>; otherwise,</del> <tt>type</tt> shall name <tt>T</tt>.<br/>
<ins>[<i>Note</i>: This rule reflects the semantics of reference collapsing (8.3.2 [dcl.ref]). &mdash; <i>end note</i>]</ins>
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct<br/>
add_rvalue_reference;</tt>
</td>
<td>
If <tt>T</tt> names <del>an object or function type</del><ins>a referenceable type</ins><br/>
then the member typedef <tt>type</tt><br/>
shall name <tt>T&amp;&amp;</tt>; otherwise, <tt>type</tt> shall name <tt>T</tt>. [<i>Note</i>: This rule reflects<br/>
the semantics of reference collapsing (8.3.2 [dcl.ref]). For example, when a type <tt>T</tt><br/>
names a type <tt>T1&amp;</tt>, the type <tt>add_rvalue_reference_t&lt;T&gt;</tt> is not an<br/>
rvalue reference. &mdash; <i>end note</i>]
</td>
</tr>
</table>

</li>

<li><p>Change Table 56 &mdash; "Pointer modifications" in 20.10.7.5 [meta.trans.ptr] as indicated:</p>

<table border="1">
<caption>Table 56 &mdash; Pointer modifications</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

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

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct add_pointer;</tt>
</td>
<td>
<ins>If <tt>T</tt> names a referenceable type or a (possibly <i>cv</i>-qualified) <tt>void</tt> type then<br/></ins>
<del>T</del><ins>t</ins>he member typedef <tt>type</tt> shall name the same type as<br/>
<tt>remove_reference_t&lt;T&gt;*</tt><ins>; otherwise, <tt>type</tt> shall name <tt>T</tt></ins>.
</td>
</tr>

</table>

</li>
</ol>





<hr>
<h3><a name="2111" href="#2111">2111.</a> Which <tt>unexpected</tt>&#47;<tt>terminate</tt> handler is called from the exception handling runtime?</h3>
<p><b>Section:</b> 18.8.3.4 [terminate], D.8.4 [unexpected] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2011-12-06 <b>Last modified:</b> 2015-09-25</p>
<p><b>View all other</b> <a href="lwg-index.html#terminate">issues</a> in [terminate].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Prior to N3242, modified by N3189, we said this about <tt>unexpected()</tt>:
</p>

<blockquote><p>
<i>Effects</i>: Calls the <tt>unexpected_handler</tt> function in effect immediately after evaluating the throw-expression 
(D.13.1), if called by the implementation, or calls the current <tt>unexpected_handler</tt>, if called by the program.
</p></blockquote>

<p>
and this about <tt>terminate()</tt>:
</p>

<blockquote><p>
<i>Effects</i>: Calls the <tt>terminate_handler</tt> function in effect immediately after evaluating the throw-expression (18.8.3.1), 
if called by the implementation, or calls the current <tt>terminate_handler</tt> function, if called by the program.
</p></blockquote>

<p>
But now in both places we say:
</p>

<blockquote><p>
Calls the current <tt>unexpected_handler</tt> function.
</p></blockquote>

<p>
and:
</p>

<blockquote><p>
Calls the current <tt>terminate</tt> function.
</p></blockquote>

<p>
The difference is that in C++98&#47;03 if a destructor reset a handler during stack unwinding, that new handler was 
not called if the unwinding later led to <tt>unexpected()</tt> or <tt>terminate()</tt> being called.  But these new 
words say that this new handler <em>is</em> called. This is an ABI-breaking change in the way exceptions are handled.  
Was this change intentional?
<p/>
N3189 was mainly about introducing exception safety and getters for the handlers. I don't recall the issue of 
<em>which</em> handler gets called being part of the discussion.
<p/>
I propose that we revert to the C++98&#47;03 behavior in this regard, lest ABI's such as the Itanium ABI are invalidated.  
A mechanical way to do this is to revert bullets 9 and 12 of N3189.
</p>

<p><i>[2011-12-09: Daniel comments]</i></p>


<p>
There was no such semantic change intended. It was an unfortunate side effect when trying to better separate different
responsibilities in the previous wording.
<p/>
A related issue is <a href="lwg-active.html#2088">2088</a>.
</p>

<p><i>[2012-01-30: Howard comments]</i></p>


<p>
The C++98&#47;03 wording is somewhat ambiguous:
</p>
<blockquote><p>
Calls the terminate_handler function in effect immediately after evaluating the throw-expression...
</p></blockquote>
<p>
There are potentially two throw-expressions being referred to here, and it is not clear if this sentence is referring to just the first or both:
</p>
<ol>
<li><tt>throw <i>assignment-expression</i>;</tt></li>
<li><tt>throw;</tt></li>
</ol>
<p>
There is ample evidence in current implementations that it is understood that <i>only</i> 
1. was meant. But clearly both 1 and 2 could have been meant. We need a clarification. Does an execution 
of a rethrow (throw;) update which handlers can potentially be called?
</p>
<ol>
<li value="2"><tt>throw;</tt> // update handlers to get_xxx()?</li>
</ol>
<p>
My opinion: Go with existing practice, and clarify what that practice is, if surveys find that everyone 
does the same thing. Gcc 4.2 and Apple do 1. only, and do not reset the handlers to the current handlers 
on throw;.
<p/>
If current practice is not unanimously one way or the other, I have no strong opinion. I have not found 
a motivating use case for the use of any particular handler. Most applications set the handlers once at 
the beginning of the program and then do not change them, and so will not be impacted by whatever decision 
is made here.
</p>

<p><i>[2014-02-15 Issaquah: Move to Review]</i></p>


<p>
STL: Original change in N3242 came from trying to make set/get exception handler thread safe.
The issue requests we revert to 98/03, which Howard notes was already ambiguous.
</p>

<p>
Alisdair: Issue author thinks we made this change in C++11 without taking into account Itanium ABI,
which cannot implement the new semantic (without breaking compatibility).
</p>

<p>
Alisdair: original change in N3242 was trying to solve the problem of which handler is called when
the handler is changing in another thread, but this turns out to be an issue in even the
single-threaded case.
</p>

<p>
Pablo: despite wanting to make it thread safe, you are still changing a global
</p>

<p>
STL and Marshall confirm that there is real implementation divergance on the question, so
we cannot pick just one behavior if we want to avoid breaking exisitng practice.
</p>

<p>
Alisdair: not sure who to talk to across all library vendors to fix, need more information
for progress (IBM and Sun)
</p>

<p>
STL: Howard did identify a problem with the wording as well: <tt>throw;</tt> is a throw expression,
but we typically want to re-activate the in-flight exception, not throw a new copy.
</p>

<p>
Pablo: wondering why all of this wording is here (N3189)? It looks like we were trying to handle another thread
changing handler between a <tt>throw</tt> and <tt>terminate</tt> in current thread.
</p>

<p>
Alisdair: Anything working with exception handling should have used only thread-local resources, but that ship has sailed.
We must account for the same exception object being re-thrown in multiple threads simultaneously, with no happens-before
relationships.
</p>

<p>
Room: Why on earth would we care about exactly which way the program dies when the terminate calls are racing?!
</p>

<p>
Pablo: Reasonable to set the handler once (in <tt>main</tt>) and never change it.
</p>

<p>
Pablo: If willing to put lots of work into this, you could say at point of a <tt>throw</tt> these handlers become
thread local but that is overkill.  We want destructors to be able to change these handlers (if only for backwards
compatibility).
</p>

<p>
Alisdair: the <i>&quot;do it right&quot;</i> is to do something per thread, but that is more work than vendors will want to do.
Want to say setting handler while running multiple threads is unspecified.
</p>

<p>
Pablo: possible all we need to do is say it is always the current handler
</p>

<p>
STL: That prevents an implementation or single threaded program from calling a new handler after a <tt>throw</tt>,
probably should say if <tt>terminate</tt> is called <i>by the implementation</i> (during EH), any handler that was
current can be called.  Leaves it up in the air as to when the handler is captured, supporting the diverging
existing practices.
</p>

<p>
Jeffrey: use <i>happens before</i> terminology to avoid introducing races
</p>

<p>
STL: Give this to concurrency?
</p>

<p>
Jeffrey: It is in clause 18, generally LWG and not SG1 territory.
</p>

<p>
Alisdair: Concerned about introducing <i>happens before</i> into fundamental exception handling since it would affect
single threaded performance as well.  Want to give to concurrency or LEWG/EWG, we are into language design here.
</p>

<p>
Jeffrey: suspect LEWG won't have a strong opinion.  I don't want it to be ours!!!
</p>

<p>
Pablo: Might be a case for core>
</p>

<p>
Alisdair: Would be happier if at least one core person were in the discussion.
</p>

<p>
STL: No sympathy for code that tries to guard the terminate handler.
</p>

<p>
Alisdair: We are back to set it once, globally.  Want to be clear that if <tt>set_terminate</tt> is called just once,
when EH is not active, and never changed again, then the user should get the handler from that specific call.
</p>

<p>
AlisdairM: "unspecified which handler is called if an exception is active when <tt>set_terminate</tt> is called."
This supports existing behaviors, and guarantees which handler is called in non-conentious situations.  Implicit
assumption that a funtion becomes a handler only after a successful call to <tt>set_handler</tt>, so we are not
leaving a door open to the implementation inventing entirely new handlers of its own.
</p>

<p>
<i>Consensus.</i>
</p>

<p>
Poll to confirm status as P1: new consensus is P3
</p>

<p>
<i>Action:</i> Alisdair provides new wording.  Drop from P1 to P3, and move to Review.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
HH: we accidentally changed semantics of which handler gets called during exception unwinding. This was attempt to put it back. 
Discovered implementations don't really do anything. [&hellip;] Fine with unspecified behavior to move this week.<br/>
STL/MC: observed different behavior<br/>
STL: legitimizes all implementations and tells users to not do this<br/>
Move to ready? 9/0/1 
</p>


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

<p>
Amend 18.8.3.4 [terminate] as indicated:
</p>

<tt>[[noreturn]] void terminate() noexcept;</tt>
<blockquote><p>
<i>Remarks:</i> Called by the implementation when exception handling must be abandoned for any of several reasons (15.5.1)
<del>, in effect immediately after throwing the exception</del>. May also be called directly by the program.
</p></blockquote>

<blockquote><p>
<i>Effects:</i> <ins>Calls a <tt>terminate_handler</tt> function. It is unspecified which <tt>terminate_handler</tt> function will
be called if an exception is active during a call to <tt>set_terminate</tt>. Otherwise c</ins><del>C</del>alls the current
<tt>terminate_handler</tt> function. [<i>Note:</i> A default <tt>terminate_handler</tt> is always considered a callable handler in
this context. &mdash; <i>end note</i>]
</p></blockquote>

<p>
Amend D.8.4 [unexpected] as indicated:
</p>

<tt>[[noreturn]] void unexpected();</tt>
<blockquote><p>
Remarks: Called by the implementation when a function exits via an exception not allowed by its <i>exception-specification</i>
(15.5.2)<del>, in effect after evaluating the throw-expression (D.11.1)</del>. May also be called directly by the program.
</p></blockquote>

<blockquote><p>
<i>Effects:</i> <ins>Calls an <tt>unexpected_handler</tt> function. It is unspecified which <tt>unexpected_handler</tt>
function will be called if an exception is active during a call to <tt>set_unexpected</tt>. Otherwise c</ins><del>C</del>alls the current 
<tt>unexpected_handler</tt> function. [<i>Note:</i> A default <tt>unexpected_handler</tt> is always considered a callable handler in 
this context. &mdash; <i>end note</i>] 
</p></blockquote>






<hr>
<h3><a name="2119" href="#2119">2119.</a> Missing <tt>hash</tt> specializations for extended integer types</h3>
<p><b>Section:</b> 20.9.13 [unord.hash] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-12-16 <b>Last modified:</b> 2015-05-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
According to the header <tt>&lt;functional&gt;</tt> synopsis 20.9 [function.objects] 
and to the explicit description in 20.9.13 [unord.hash] class template 
<tt>hash</tt> specializations shall be provided for all arithmetic types that are 
not extended integer types. This is not explicitly mentioned, but neither the list 
nor any normative wording does include them, so it follows by implication.
<p/>
What are the reasons that extended integer types are excluded? E.g. for 
<tt>numeric_limits</tt> corresponding specializations are required. I would 
expect that an <tt>unordered_map</tt> with key type <tt>std::uintmax_t</tt> would 
just work, but that depends now on whether this type is an extended integer type 
or not.
<p/>
This issue is <em>not</em> asking for also providing specializations for the
<i>cv</i>-qualified arithmetic types. While this is surely a nice-to-have feature,
I consider that restriction as a more secondary problem in practice.
<p/>
The proposed resolution also fixes a problem mentioned in <a href="lwg-defects.html#2109">2109</a> in regard
to confusing requirements on user-defined types and those on implementations.
</p>

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

<p>
Move to Open.
</p>
<p>
Agreed that it's a real issue and that the proposed wording fixes it. However, the wording
change is not minimal and isn't consistent with the way we fixed hash wording elsewhere.
</p>
<p>Alisdair will provide updated wording.
</p>

<p><i>[2014-05-06 Geoffrey Romer suggests alternative wording]</i></p>


<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to the FDIS.</p>

<p>Change 20.9.13 [unord.hash] p2 as indicated:</p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;bool&gt;;
template &lt;&gt; struct hash&lt;char&gt;;
[&hellip;]
template &lt;&gt; struct hash&lt;long double&gt;;
template &lt;class T&gt; struct hash&lt;T*&gt;;
</pre><blockquote>
<p>
-2- <del><i>Requires</i>: the template specializations shall meet the requirements 
of class template <tt>hash</tt> (20.9.13 [unord.hash])</del><ins>The header 
<tt>&lt;functional&gt;</tt> provides definitions for specializations of the 
<tt>hash</tt> class template for each <i>cv</i>-unqualified arithmetic type. This 
header also provides a definition for a partial specialization of the <tt>hash</tt> 
class template for any pointer type. The requirements for the members of these 
specializations are given in sub-clause 20.9.13 [unord.hash]</ins>.
</p>
</blockquote></blockquote>
</blockquote>

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL: the new PR is very simple and could resolve that nicely<br/>
MC: the older PR is rather longish
</p>
<ul>
<li><p>anybody have any objections to this approach?</p></li>
<li><p>what people want to have as a status?</p></li>
</ul>
<p>
STL: I want to have Ready<br/>
MC: move to ready: in favor: 13, opposed: 0, abstain: 4 
</p>


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

<p>Change 20.9.13 [unord.hash] p1 as indicated:</p>

<blockquote><p>
The unordered associative containers defined in 23.5 use specializations of the class template <tt>hash</tt> as the
default hash function. For all object types <tt>Key</tt> for which there exists a specialization <tt>hash&lt;Key&gt;</tt>, 
and for all <ins>integral and</ins> enumeration types (7.2) <tt>Key</tt>, the instantiation <tt>hash&lt;Key&gt;</tt> shall: [&hellip;]
</p></blockquote>






<hr>
<h3><a name="2127" href="#2127">2127.</a> Move-construction with <tt>raw_storage_iterator</tt></h3>
<p><b>Section:</b> 20.7.10 [storage.iterator] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-01-23 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all other</b> <a href="lwg-index.html#storage.iterator">issues</a> in [storage.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Aliaksandr Valialkin pointed out that <tt>raw_storage_iterator</tt> only supports constructing 
a new object from lvalues so cannot be used to construct move-only types:
</p>
<blockquote><pre>
template &lt;typename InputIterator, typename T&gt;
void move_to_raw_buffer(InputIterator first, InputIterator last, T *raw_buffer)
{
  std::move(first, last, std::raw_storage_iterator&lt;T *, T&gt;(raw_buffer));
}
</pre></blockquote>
<p>
This could easily be solved by overloading <tt>operator=</tt> for rvalues.
<p/>
Dave Abrahams:
<p/>
<tt>raw_storage_iterator</tt> causes exception-safety problems when used with any
generic algorithm. I suggest leaving it alone and not encouraging its use.
</p>

<p><i>[2014-11-11, Jonathan provides improved wording]</i></p>

<p>
In Urbana LWG decided to explicitly say the value is constructed from an rvalue.
</p>

<strong>Previous resolution from Jonathan [SUPERSEDED]:</strong>
<p/>
<blockquote class="note">
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf">N3337</a>.</p>

<ol>
<li><p>Add a new signature to the synopsis in 20.7.10 [storage.iterator] p1:</p>

<blockquote><pre>
namespace std {
  template &lt;class OutputIterator, class T&gt;
  class raw_storage_iterator
    : public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
  public:
    explicit raw_storage_iterator(OutputIterator x);

    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator*();
    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(const T&amp; element);
    <ins>raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(T&amp;&amp; element);</ins>
    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator++();
    raw_storage_iterator&lt;OutputIterator,T&gt; operator++(int);
};
}
</pre></blockquote>
</li>

<li><p>Insert the new signature and a new paragraph before p4:</p>

<blockquote><pre>
raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(const T&amp; element);
<ins>raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(T&amp;&amp; element);</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Requires</i>: For the first signature <tt>T</tt> shall be <tt>CopyConstructible</tt>. For
the second signature <tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins>
<p/>
-4- <i>Effects</i>: Constructs a value from <tt>element</tt> at the location to which the iterator points.
<p/>
-5- <i>Returns</i>: A reference to the iterator.
</p>
</blockquote></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-05, Lenexa]</i></p>

<p>
MC: Suggestion to move it to Ready for incorporation on Friday<br/>
MC: move to ready: in favor: 12, opposed: 0, abstain: 3 
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n4140.pdf">N4140</a>.</p>

<ol>
<li><p>Add a new signature to the synopsis in 20.7.10 [storage.iterator] p1:</p>

<blockquote><pre>
namespace std {
  template &lt;class OutputIterator, class T&gt;
  class raw_storage_iterator
    : public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
  public:
    explicit raw_storage_iterator(OutputIterator x);

    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator*();
    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(const T&amp; element);
    <ins>raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(T&amp;&amp; element);</ins>
    raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator++();
    raw_storage_iterator&lt;OutputIterator,T&gt; operator++(int);
};
}
</pre></blockquote>
</li>

<li><p>Insert a new paragraph before p4:</p>

<blockquote><pre>
raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(const T&amp; element);
</pre><blockquote>
<p>
<ins>-?- <i>Requires</i>: <tt>T</tt> shall be <tt>CopyConstructible</tt>.</ins>
<p/>
-4- <i>Effects</i>: Constructs a value from <tt>element</tt> at the location to which the iterator points.
<p/>
-5- <i>Returns</i>: A reference to the iterator.
</p>
</blockquote></blockquote>
</li>

<li><p>Insert the new signature and a new paragraph after p5:</p>

<blockquote><pre>
<ins>raw_storage_iterator&lt;OutputIterator,T&gt;&amp; operator=(T&amp;&amp; element);</ins>
</pre><blockquote>
<p>
<ins>-?- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins>
<p/>
<ins>-?- <i>Effects</i>: Constructs a value from <tt>std::move(element)</tt> at the
location to which the iterator points.</ins>
<p/>
<ins>-?- <i>Returns</i>: A reference to the iterator.</ins>
</p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="2133" href="#2133">2133.</a> Attitude to overloaded comma for iterators</h3>
<p><b>Section:</b> 17.6.5.4 [global.functions] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Yakov Galka <b>Opened:</b> 2012-01-25 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all other</b> <a href="lwg-index.html#global.functions">issues</a> in [global.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
17.6.5.4 [global.functions] says
</p>
<blockquote><p>
Unless otherwise specified, global and non-member functions in the standard library 
shall not use functions from another namespace which are found through argument-dependent 
name lookup (3.4.2).
</p></blockquote>
<p>
This sounds clear enough. There are just two problems:
</p>
<ol>
<li><p>
Both implementations I tested (VS2005 and GCC 3.4.3) do unqualified
calls to the comma operator in some parts of the library with operands
of user-defined types.
</p></li>
<li>
<p>
The standard itself does this in the description of some algorithms. E.g. <tt>uninitialized_copy</tt> 
is defined as:
</p>
<blockquote><p>
<i>Effects</i>:
</p><blockquote>
<pre>
for (; first != last; <span style="color:#C80000;font-weight:bold">++result, ++first</span>)
  ::new (static_cast&lt;void*&gt;(&amp;*result))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
</pre>
</blockquote>
</blockquote>
</li>
</ol>
<p>
If understood literally, it is required to call <tt>operator,(ForwardIterator, InputIterator)</tt>.
<p/>
For detailed discussion with code samples see 
<a href="http://stackoverflow.com/questions/8719829/should-the-implementation-guard-itself-against-comma-overloading">here</a>.
<p/>
Proposal:
</p>
<ol>
<li>
Add an exception to the rule in 17.6.5.4 [global.functions] by permitting
the implementation to call the comma operator as much as it wants to. I doubt we want this. or
</li>
<li>
Fix the description of the said algorithms and perhaps add a note to 17.6.5.4 [global.functions] 
that brings attention of the implementers to avoid this pitfall.
</li>
</ol>

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

<p>
Moved to Open.
</p>
<p>
There are real questions here, that may require a paper to explore and answer properly.
</p>

<p><i>[2014-05-18, Daniel comments and suggests concrete wording]</i></p>


<p>
Other issues, such as <a href="lwg-active.html#2114">2114</a> already follow a similar spirit as the one suggested by bullet 2 of the
issue submitter. I assert that consideration of possible user-provided overloads of the comma-operator were not intended
by the original wording and doing so afterwards would unnecessarily complicate a future conceptualization of the library
and would needlessly restrict implementations.
<p/>
I don't think that a paper is needed to solve this issue, there is a simply way to ensure that the code-semantics
excludes consideration of user-provided comma operators. The provided wording below clarifies this by explicitly
casting the first argument of the operator to <tt>void</tt>. 
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
DK: is putting it in the middle the right place for it?<br/>
STL: either works, but visually putting it in the middle is clearer, and for "++it1, ++i2, ++it3" it needs to be 
done after the second comma, so "++it1, (void) ++i2, (void) ++it3" is better than "(void) ++it1, ++i2, (void) ++it3"<br/>
ZY: for <tt><i>INVOKE</i></tt> yesterday we used <tt>static_cast&lt;void&gt;</tt> but here we're using C-style cast, why?<br/>
STL: for <tt><i>INVOKE</i></tt> I want to draw attention that there's an intentional coercion to <tt>void</tt> because that's 
the desired type. Here we only do it because that's the best way to prevent the problem, not because we specifically want a 
<tt>void</tt> type.<br/>
Move to Ready: 9 in favor, none opposed, 1 abstention 
</p>


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

<ol>
<li><p>Change 20.7.12.2 [uninitialized.copy] as indicated:</p>

<blockquote>
<pre>
template &lt;class InputIterator, class ForwardIterator&gt;
  ForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
                                     ForwardIterator result);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>:
</p>
<blockquote>
<pre>
for (; first != last; ++result, <ins>(void)</ins> ++first)
  ::new (static_cast&lt;void*&gt;(&amp;*result))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
</pre>
</blockquote>
<p>
[&hellip;]
</p>
</blockquote>

<pre>
template &lt;class InputIterator, class Size,class ForwardIterator&gt;
  ForwardIterator uninitialized_copy_n(InputIterator first, Size n,
                                       ForwardIterator result);
</pre>
<blockquote>
<p>
-3- <i>Effects</i>:
</p>
<blockquote>
<pre>
for (; n &gt; 0; ++result, <ins>(void)</ins> ++first, --n)
  ::new (static_cast&lt;void*&gt;(&amp;*result))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
</pre>
</blockquote>
</blockquote>

</blockquote>
</li>

<li><p>Change 25.4.8 [alg.lex.comparison] p3 as indicated:</p>

<blockquote>
<pre>
template&lt;class InputIterator1, class InputIterator2&gt;
  bool
    lexicographical_compare(InputIterator1 first1, InputIterator1 last1,
                            InputIterator2 first2, InputIterator2 last2);
template&lt;class InputIterator1, class InputIterator2, class Compare&gt;
  bool
    lexicographical_compare(InputIterator1 first1, InputIterator1 last1,
                            InputIterator2 first2, InputIterator2 last2,
                            Compare comp);
</pre>
<blockquote>
<p>
-3- <i>Remarks</i>: [&hellip;]
</p>
<blockquote>
<pre>
for ( ; first1 != last1 &amp;&amp; first2 != last2 ; ++first1, <ins>(void)</ins> ++first2) {
  if (*first1 &lt; *first2) return true;
  if (*first2 &lt; *first1) return false;
}
return first1 == last1 &amp;&amp; first2 != last2;
</pre>
</blockquote>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2156" href="#2156">2156.</a> Unordered containers' <tt>reserve(n)</tt> reserves for <tt>n-1</tt> elements</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel James <b>Opened:</b> 2012-05-07 <b>Last modified:</b> 2015-05-22</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
I think that unordered containers' <tt>reserve</tt> doesn't quite do what it should. I'd expect after calling 
<tt>x.reserve(n)</tt> to be able to insert <tt>n</tt> elements without invalidating iterators. But as 
the standard is written (I'm looking at n3376), I think the guarantee only holds for <tt>n-1</tt> elements.
<p/>
For a container with <tt>max_load_factor</tt> of <tt>1</tt>, <tt>reserve(n)</tt> is equivalent to
<tt>rehash(ceil(n/1))</tt>, ie. <tt>rehash(n)</tt>. <tt>rehash(n)</tt> requires that the bucket
count is <tt>&gt;= n</tt>, so it can be <tt>n</tt> (Table 103). The rule is that <tt>insert</tt>
shall not affect the validity of iterators if <tt>(N + n) &lt; z * B</tt> (23.2.5 [unord.req] p15). 
But for this case the two sides of the equation are equal, so <tt>insert</tt> can affect the validity of iterators.
</p>

<p><i>[2013-03-16 Howard comments and provides wording]</i></p>


<p>
Given the following:
</p>

<blockquote><pre>
LF := load_factor()
MLF := max_load_factor()
S := size()
B := bucket_count()

LF == S/B
</pre></blockquote>

<p>
The container has an invariant:
</p>

<blockquote><pre>
LF &lt;= MLF
</pre></blockquote>

<p>
Therefore:
</p>

<blockquote><pre>
MLF &gt;= S/B
S &lt;= MLF * B
B &gt;= S/MLF
</pre></blockquote>

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

<p>
Moved to Open.
</p>
<p>
Howard to provide rationale and potentally revised wording.
</p>


<p><i>[2012-02-12 Issaquah : recategorize as P3]</i></p>

<p>
Jonathon Wakely: submitter is Boost.Hash maintainer. Think it's right.
</p>

<p>
Marshall Clow: even if wrong it's more right than what we have now
</p>

<p>
Geoffrey Romer: issue is saying rehash should not leave container in such a state that a notional insertion of zero elements should not trigger a rehash
</p>

<p>
AJM: e.g. if you do a range insert from an empty range
</p>

<p>
AJM: we don't have enough brainpower to do this now, so not priority zero
</p>

<p>
Recategorised as P3
</p>

<p><i>[Lenexa 2015-05-06: Move to Ready]</i></p>



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

<ol>
<li>
<p>
In 23.2.5 [unord.req] Table 103 &mdash; Unordered associative container requirements, change the post-condition 
in the row for <code>a.rehash(n)</code> to:
</p>
<blockquote>
Post: <code>a.bucket_count() &gt;<ins>=</ins> a.size() / a.max_load_factor()</code> and <code>a.bucket_count() &gt;= n</code>.
</blockquote>
</li>

<li>
<p>
In 23.2.5 [unord.req]/p15 change
</p>
<blockquote>
The <code>insert</code> and <code>emplace</code> members shall not affect the validity of iterators if 
<code>(N+n) &lt;<ins>=</ins> z * B</code>, where <code>N</code> is the number of elements in the container 
prior to the insert operation, <code>n</code> is the number of elements inserted, <code>B</code> is the container's 
bucket count, and <code>z</code> is the container's maximum load factor.
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2181" href="#2181">2181.</a> Exceptions from <em>seed sequence</em> operations</h3>
<p><b>Section:</b> 26.5.1.2 [rand.req.seedseq], 26.5.3 [rand.eng], 26.5.4 [rand.adapt] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-18 <b>Last modified:</b> 2015-09-25</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.req.seedseq">issues</a> in [rand.req.seedseq].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
LWG issue <a href="lwg-defects.html#2180">2180</a> points out some deficiences in regard to the specification of the library-provided
type <tt>std::seed_seq</tt> regarding exceptions, but there is another specification problem 
in regard to general types satisfying the <em>seed sequence</em> constraints (named <tt>SSeq</tt>) as described in 
26.5.1.2 [rand.req.seedseq].
<p/>
26.5.3 [rand.eng] p3 and 26.5.4.1 [rand.adapt.general] p3 say upfront:
</p>
<blockquote><p>
Except where specified otherwise, no function described in this section 
26.5.3 [rand.eng]/26.5.4 [rand.adapt] throws an exception.
</p></blockquote>
<p>
This constraint causes problems, because the described templates in these sub-clauses depend on operations of 
<tt>SSeq::generate()</tt> which is a function template, that depends both on operations provided by the 
implementor of <tt>SSeq</tt> (e.g. of <tt>std::seed_seq</tt>), and those of the random access iterator type 
provided by the caller. With class template <tt>linear_congruential_engine</tt> we have just one example for a user 
of <tt>SSeq::generate()</tt> via:
</p>
<blockquote><pre>
template&lt;class Sseq&gt; 
linear_congruential_engine&lt;&gt;::linear_congruential_engine(Sseq&amp; q);

template&lt;class Sseq&gt; 
void linear_congruential_engine&lt;&gt;::seed(Sseq&amp; q);
</pre></blockquote>
<p>
None of these operations has an exclusion rule for exceptions.
<p/>
As described in <a href="lwg-defects.html#2180">2180</a> the wording for <tt>std::seed_seq</tt> should and can be fixed to ensure that 
operations of <tt>seed_seq::generate()</tt> won't throw except from operations of the provided iterator range, 
but there is no corresponding "safety belt" for user-provided <tt>SSeq</tt> types, since 26.5.1.2 [rand.req.seedseq]
does not impose no-throw requirements onto operations of <em>seed sequences</em>.
</p>

<ol style="list-style-type:upper-roman">

<li><p>
A quite radical step to fix this problem would be to impose general no-throw requirements on the expression
<tt>q.generate(rb,re)</tt> from Table 115, but this is not as simple as it looks initially, because this
function again depends on general types that are mutable random access iterators. Typically, we do not
impose no-throw requirements on iterator operations and this would restrict general seed sequences where
exceptions are not a problem. Furthermore, we do not impose comparable constraints for other expressions,
like that of the expression <tt>g()</tt> in Table 116 for good reasons, e.g. <tt>random_device::operator()</tt>
explicitly states when it throws exceptions.
</p></li>

<li><p>
A less radical variant of the previous suggestion would be to add a normative requirement on the expression
<tt>q.generate(rb,re)</tt> from Table 115 that says: "Throws nothing if operations of <tt>rb</tt> and <tt>re</tt> 
do not throw exceptions". Nevertheless we typically do not describe <em>conditional</em> Throws elements in proper
requirement sets elsewhere (Container requirements excluded, they just describe the containers from Clause 23)
and this may exclude resonable implementations of seed sequences that could throw exceptions under rare
situations. 
</p></li>

<li><p>
The iterator arguments provided to <tt>SSeq::generate()</tt> for operations in templates of 26.5.3 [rand.eng] and 
26.5.4 [rand.adapt] are under control of implementations, so we could impose stricter exceptions requirements
on <tt>SSeq::generate()</tt> for <tt>SSeq</tt> types that are used to instantiate member templates in 26.5.3 [rand.eng] 
and 26.5.4 [rand.adapt] solely.
</p></li>

<li><p>
We simply add extra wording to the introductive parts of 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]
that specify that operations of the engine (adaptor) templates that depend on a template parameter <tt>SSeq</tt>
throw no exception unless <tt>SSeq::generate()</tt> throws an exception.
</p></li>
</ol>

<p>
Given these options I would suggest to apply the variant described in the fourth bullet.
<p/>
The proposed resolution attempts to reduce a lot of the redundancies of requirements in the introductory paragraphs of 
26.5.3 [rand.eng] and 26.5.4 [rand.adapt] by introducing a new intermediate sub-clause 
"Engine and engine adaptor class templates" following sub-clause 26.5.2 [rand.synopsis]. This approach also
solves the problem that currently 26.5.3 [rand.eng] also describes requirements that apply for
26.5.4 [rand.adapt] (Constrained templates involving the <tt>Sseq</tt> parameters).
</p>

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


<p>
Remove the first bullet point:
</p>
<blockquote><p>
?- Throughout this sub-clause general requirements and conventions are described that apply to every class 
template specified in sub-clause 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]. Phrases of the form "in those 
sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]". 
</p></blockquote>
<p>
Replace "in those sub-clauses" with "in sub-clauses 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]".
<p/>
Find another place for the wording. 
<p/>
Daniel: These are requirements on the implementation not on the types. I'm not comfortable in moving it to another place 
without double checking. 
<p/>
Improve the text (there are 4 "for"s): <em>for</em> copy constructors, <em>for</em> copy assignment operators, 
<em>for</em> streaming operators, and <em>for</em> equality and inequality operators are not shown in the synopses. 
<p/>
Move the information of this paragraph to the paragraphs it refers to: 
</p>
<blockquote><p>
"-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in 
26.5.1.4 [rand.req.eng], for adaptor operations that are not described in 26.5.1.5 [rand.req.adapt], or for 
operations where there is additional semantic information. In particular, declarations for copy constructors, for 
copy assignment operators, for streaming operators, and for equality and inequality operators are not shown in the synopses." 
</p></blockquote>
<p>
Alisdair: I prefer duplication here than consolidation/reference to these paragraphs. 
<p/>
The room showed weakly favjust or for duplication. 
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>
<li><p>Add a new sub-clause titled "Engine and engine adaptor class templates" following sub-clause 
26.5.2 [rand.synopsis] (but at the same level) and add one further sub-clause "General" as
child of the new sub-clause as follows:
<p/>
<ins>Engine and engine adaptor class templates [rand.engadapt]</ins>
<p/>
<ins>General [rand.engadapt.general]</ins>
</p>
<blockquote><p>
<ins>-?- Throughout this sub-clause general requirements and conventions are described that apply to every class 
template specified in sub-clause 26.5.3 [rand.eng] and 26.5.4 [rand.adapt]. Phrases of the 
form "in those sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.5.3 [rand.eng] and 
26.5.4 [rand.adapt]".
</ins>
<p/>
<ins>-?- Except where specified otherwise, the complexity of each function specified in those sub-clauses is constant.</ins>
<p/>
<ins>-?- Except where specified otherwise, no function described in those sub-clauses throws an exception.</ins>
<p/>
<ins>-?- Every function described in those sub-clauses that has a function parameter <tt>q</tt> of type
<tt>SSeq&amp;</tt> for a template type parameter named <tt>SSeq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
<ins>-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in 
26.5.1.4 [rand.req.eng], for adaptor operations that are not described in 26.5.1.5 [rand.req.adapt],
or for operations where there is additional semantic information. In particular, declarations for copy constructors,
for copy assignment operators, for streaming operators, and for equality and inequality operators
are not shown in the synopses.</ins>
<p/>
<ins>-?- Each template specified in those sub-clauses requires one or more relationships, involving the value(s) of
its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.</ins>
<p/>
<ins>-?- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in those 
sub-clauses:</ins>
</p>
<ul>
<li><p>
<ins>if the constructor</ins>
</p>
<blockquote><pre>
<ins>template &lt;class Sseq&gt; explicit X(Sseq&amp; q);</ins>
</pre></blockquote>
<p>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
participate in overload resolution;</ins>
</p>
</li>

<li><p>
<ins>if the member function</ins>
</p>
<blockquote><pre>
<ins>template &lt;class Sseq&gt; void seed(Sseq&amp; q);</ins>
</pre></blockquote>
<p>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
participate in overload resolution;</ins>
</p>
</li>
</ul>
<p>
<ins>The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
<tt>X::result_type</tt>.</ins>
</p>
</blockquote>

</li>

<li><p>Edit the contents of sub-clause 26.5.3 [rand.eng] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 26.5.3 [rand.eng] satisfies the 
requirements of a random number engine (26.5.1.4 [rand.req.eng]) type <ins>and the general implementation 
requirements specified in sub-clause [rand.engadapt.general]</ins>.
<p/>
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.3 [rand.eng] 
is constant.</del>
<p/>
<del>-3- Except where specified otherwise, no function described in this section 26.5.3 [rand.eng] throws an exception.</del>
<p/>
<del>-4- Descriptions are provided in this section 26.5.3 [rand.eng] only for engine operations that are not 
described in 26.5.1.4 [rand.req.eng] [&hellip;]</del>
<p/>
<del>-5- Each template specified in this section 26.5.3 [rand.eng] requires one or more relationships, 
involving the value(s) of its non-type template parameter(s), to hold. [&hellip;]</del>
<p/>
<del>-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
(26.5.3 [rand.eng]) and in sub-clause 26.5.3 [rand.eng]: [&hellip;]</del>
</p></blockquote>

</li>

<li><p>Edit the contents of sub-clause 26.5.4.1 [rand.adapt.general] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section <del>26.5.3 [rand.eng]</del><ins>26.5.4 [rand.adapt]</ins> satisfies the 
requirements of a random number engine adaptor (26.5.1.5 [rand.req.adapt]) type <ins>and the general 
implementation requirements specified in sub-clause [rand.engadapt.general]</ins>.
<p/>
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.4 [rand.adapt] 
is constant.</del>
<p/>
<del>-3- Except where specified otherwise, no function described in this section 26.5.4 [rand.adapt] throws an exception.</del>
<p/>
<del>-4- Descriptions are provided in this section 26.5.4 [rand.adapt] only for engine operations that are not 
described in 26.5.1.5 [rand.req.adapt] [&hellip;]</del>
<p/>
<del>-5- Each template specified in this section 26.5.4 [rand.adapt] requires one or more relationships, involving 
the value(s) of its non-type template parameter(s), to hold. [&hellip;]</del>
</p></blockquote>

</li>

</ol>
</blockquote>

<p><i>[2014-02-09, Daniel provides alternative resolution]</i></p>


<p><i>[Lenexa 2015-05-07: Move to Ready]</i></p>

<p>LWG 2181 exceptions from seed sequence operations</p>
<p>STL: Daniel explained that I was confused. I said, oh, seed_seq says it can throw if the RanIt throws. Daniel says the RanIts are provided by the engine. Therefore if you give a seed_seq to an engine, it cannot throw, as implied by the current normative text. So what Daniel has in the PR is correct, if slightly unnecessary. It's okay to have explicitly non-overlapping Standardese even if overlapping would be okay.</p>
<p>Marshall: And this is a case where the std:: on seed_seq is a good thing.</p>
<p>STL: Meh.</p>
<p>STL: And that was my only concern with this PR. I like the latest PR much better than the previous.</p>
<p>Marshall: Yes. There's a drive-by fix for referencing the wrong section. Other than that, the two are the same.</p>
<p>STL: Alisdair wanted the repetition instead of centralization, and I agree.</p>
<p>Marshall: Any other opinions?</p>
<p>Jonathan: I'll buy it.</p>
<p>STL: For a dollar?</p>
<p>Hwrd: I'll buy that for a nickel.</p>
<p>Marshall: Any objections to Ready? I don't see a point in Immediate.</p>
<p>Jonathan: Absolutely agree.</p>
<p>Marshall: 7 for ready, 0 opposed, 0 abstain.</p>

<p><i>[2014-05-22, Daniel syncs with recent WP]</i></p>



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

<ol>
<li><p>Edit the contents of sub-clause 26.5.3 [rand.eng] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 26.5.3 [rand.eng] satisfies the 
requirements of a random number engine (26.5.1.4 [rand.req.eng]) type.
<p/>
-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.3 [rand.eng] 
is constant.
<p/>
-3- Except where specified otherwise, no function described in this section 26.5.3 [rand.eng] throws an exception.
<p/>
<ins>-?- Every function described in this section 26.5.3 [rand.eng] that has a function parameter <tt>q</tt> of 
type <tt>Sseq&amp;</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
-4- Descriptions are provided in this section 26.5.3 [rand.eng] only for engine operations that are not 
described in 26.5.1.4 [rand.req.eng] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and 
for</del> equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
<p/>
-5- Each template specified in this section 26.5.3 [rand.eng] requires one or more relationships, 
involving the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is 
ill-formed if any such required relationship fails to hold.
<p/>
-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
(26.5.3 [rand.eng]) and in sub-clause 26.5.4 [rand.adapt]: 
</p>
<ul>
<li><p>
if the constructor
</p>
<blockquote><pre>
template &lt;class Sseq&gt; explicit X(Sseq&amp; q);
</pre></blockquote>
<p>
is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
participate in overload resolution;
</p>
</li>
<li><p>
if the member function
</p>
<blockquote><pre>
template &lt;class Sseq&gt; void seed(Sseq&amp; q);
</pre></blockquote>
<p>
is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
participate in overload resolution;
</p>
</li>
</ul>
<p>
The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
<tt>X::result_type</tt>.
</p>
</blockquote>
</li>

<li><p>Edit the contents of sub-clause 26.5.4.1 [rand.adapt.general] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 
<del>26.5.3 [rand.eng]</del><ins>26.5.4 [rand.adapt]</ins> satisfies the requirements of a 
random number engine adaptor (26.5.1.5 [rand.req.adapt]) type.
<p/>
-2- Except where specified otherwise, the complexity of each function specified in this section 26.5.4 [rand.adapt] 
is constant.
<p/>
-3- Except where specified otherwise, no function described in this section 26.5.4 [rand.adapt] throws an exception.
<p/>
<ins>-?- Every function described in this section 26.5.4 [rand.adapt] that has a function parameter <tt>q</tt> of 
type <tt>Sseq&amp;</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
-4- Descriptions are provided in this section 26.5.4 [rand.adapt] only for adaptor operations that are not 
described in section 26.5.1.5 [rand.req.adapt] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and for</del> 
equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
<p/>
-5- Each template specified in this section 26.5.4 [rand.adapt] requires one or more relationships, involving 
the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.
</p></blockquote>
</li>

<li><p>Edit the contents of sub-clause 26.5.8.1 [rand.dist.general] p2 as indicated: [<i>Drafting note</i>: These
editorial changes are just for consistency with those applied to 26.5.3 [rand.eng] and 
26.5.4.1 [rand.adapt.general] &mdash; <i>end drafting note</i>]</p>

<blockquote><p>
-2- Descriptions are provided in this section 26.5.8 [rand.dist] only for distribution operations that are not 
described in 26.5.1.6 [rand.req.dist] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and for</del> 
equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
</p></blockquote>
</li>

</ol>





<hr>
<h3><a name="2218" href="#2218">2218.</a> Unclear how containers use <tt>allocator_traits::construct()</tt></h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-11-27 <b>Last modified:</b> 2015-05-08</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Firstly, 23.2.1 [container.requirements.general]/7 says a container's
allocator is used to obtain memory, but it isn't stated explicitly that the same 
allocator is used to construct and destroy elements, as opposed to a value-initialized 
allocator of the same type.
</p>
<p>
Secondly, 23.2.1 [container.requirements.general]/3 says elements "shall be
constructed using the <tt>allocator_traits&lt;allocator_type&gt;::construct</tt>
function and destroyed using the <tt>allocator_traits&lt;allocator_type&gt;::destroy</tt> function" and
23.2.1 [container.requirements.general]/13 defines <tt>CopyInsertable</tt> etc. in
terms of an allocator <tt>A</tt> which is identical to the container's <tt>allocator_type</tt>.
</p>
<p>
The intent of making <tt>construct()</tt> and <tt>destroy()</tt> function templates was
that containers would be permitted to use <tt>allocator_traits&lt;A&gt;::construct()</tt> instead of
<tt>allocator_traits&lt;allocator_type&gt;::construct()</tt>, where <tt>A</tt> is
<tt>allocator_traits&lt;allocator_type&gt;::rebind_alloc&lt;U&gt;</tt> for some other type
<tt>U</tt>.  This allows node-based containers to store an allocator of the right type for 
allocating nodes and to use the same object to construct elements in aligned storage within 
those nodes, avoiding rebinding and copying the stored allocator every time an element needs
to be constructed.
<p/>
It should be made clear that a possibly-rebound copy of the container's allocator is used for object 
construction.
</p>

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

<p>
Moved to Open.
</p>
<p>
Jonathan: point 2 in the proposed resolution is definitely needed.
</p>

<p><i>[2014-11-28, Jonathan improves wording]</i></p>

<p>
In the first set of edits to paragraph 3 both pieces inserting "<tt>rebind_alloc&lt;U&gt;::</tt>"
should be replaced by "<tt>rebind_traits&lt;U&gt;::</tt>"
<p/>
Otherwise it implies using the allocator's functions directly, but they might not exist and 
it should be through the rebound traits type.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL: You want to permit but not require rebinding?<br/>
Wakely: The current wording forces me to use the original allocator, not the rebound one.<br/>
STL: Oh, I see. Yeah, we immediately rebind.<br/>
Wakely: The edits clarify that we don't use some other allocator. The third diff is because the definitions of 
EmplaceConstructible/etc. happen with the same types. The diff to the note is because it doesn't require the value 
of the allocator was the one passed in.<br/>
STL: After looking at this, I think I'm comfortable with the edits. The previous Standardese was nonsense so it's 
pretty easy to improve upon.<br/>
Marshall: Any other opinions?<br/>
Marshall: Any objections to moving it to Ready? Review? Ready in Kona?<br/>
Wakely: My preference would be Ready. We all know this is what we're doing anyways.<br/>
Nevin: The intent won't change.<br/>
STL: I think this is the right fix.<br/>
Hwrd: I third Ready. Even if Jonathan retracts his.<br/>
Marshall: Ready! 
</p>


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

<ol>
<li><p>Edit 23.2.1 [container.requirements.general] paragraph 3:</p>
<blockquote><p>
For the components affected by this subclause that declare an <tt>allocator_type</tt>, objects stored in these
components shall be constructed using the <tt>allocator_traits&lt;allocator_type&gt;::<ins>rebind_traits&lt;U&gt;::</ins>construct</tt> 
function and destroyed using the <tt>allocator_traits&lt;allocator_type&gt;::<ins>rebind_traits&lt;U&gt;::</ins>destroy</tt> 
function (20.7.8.2 [allocator.traits.members])<ins>, where <tt>U</tt> is either <tt>allocator_type::value_type</tt> 
or an internal type used by the container</ins>. These functions are called only for the container's element type, 
not for internal types used by the container. [ <i>Note</i>: This means, for example, that a node-based container 
might need to construct nodes containing aligned buffers and call construct to place the element into the buffer. 
&mdash; <i>end note</i> ]
</p></blockquote>
</li>

<li><p>Edit 23.2.1 [container.requirements.general] paragraph 7:</p>
<blockquote><p>
[&hellip;] A copy of this allocator is used for any memory allocation <ins>and element construction</ins> performed, 
by these constructors and by all member functions, during the lifetime of each container object or until the allocator 
is replaced. [&hellip;]
</p></blockquote>
</li>

<li><p>Edit 23.2.1 [container.requirements.general] paragraph 13:</p>
<blockquote><p>
[&hellip;] Given <ins>an allocator type <tt>A</tt> and given</ins> a container type <tt>X</tt> having <del>an 
<tt>allocator_type</tt> identical to <tt>A</tt> and</del> a <tt>value_type</tt> identical to <tt>T</tt> 
<ins>and an <tt>allocator_type</tt> identical to <tt>allocator_traits&lt;A&gt;::rebind_alloc&lt;T&gt;</tt></ins> 
and given an lvalue <tt>m</tt> of type <tt>A</tt>, a pointer <tt>p</tt> 
of type <tt>T*</tt>, an expression <tt>v</tt> of type (possibly <tt>const</tt>) <tt>T</tt>, and an rvalue <tt>rv</tt> 
of type <tt>T</tt>, the following terms are defined.
<p/>
[&hellip;]
<p/>
[ <i>Note</i>: A container calls <tt>allocator_traits&lt;A&gt;::construct(m, p, args)</tt> to construct an element 
at <tt>p</tt> using <tt>args</tt><ins>, with <tt>m == get_allocator()</tt></ins>. The default <tt>construct</tt> in 
<tt>std::allocator</tt> will call <tt>::new((void*)p) T(args)</tt>, but specialized allocators may choose a 
different definition. &mdash; <i>end note</i> ]
</p></blockquote>
</li>

</ol>






<hr>
<h3><a name="2219" href="#2219">2219.</a> <tt><i>INVOKE</i></tt>-ing a pointer to member with a <tt>reference_wrapper</tt> as the object expression</h3>
<p><b>Section:</b> 20.9.2 [func.require] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2012-11-28 <b>Last modified:</b> 2015-05-06</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The standard currently requires this to be invalid:
</p>
<blockquote><pre>
#include &lt;functional&gt;

struct X { int i; } x;
auto f = &amp;X::i;
auto t1 = std::ref(x);
int i = std::mem_fn(f)(t1);
</pre></blockquote>
<p>
The call expression on the last line is equivalent to <tt><i>INVOKE</i>(f, std::ref(x))</tt> 
which according to 20.9.2 [func.require]p1 results in the invalid expression <tt>(*t1).*f</tt> 
because <tt>reference_wrapper&lt;X&gt;</tt> is neither an object of type <tt>X</tt> nor a reference 
to an object of type <tt>X</tt> nor a reference to an object of a type derived from <tt>X</tt>.
</p>
<p>
The same argument applies to pointers to member functions, and if they don't work with <tt>INVOKE</tt> 
it becomes harder to do all sorts of things such as:
</p>
<blockquote><p>
<tt>call_once(o, &amp;std::thread::join, std::ref(thr))</tt>
</p></blockquote>
<p>
or
</p>
<blockquote><p>
<tt>async(&amp;std::list&lt;int&gt;::sort, std::ref(list));</tt>
</p></blockquote>
<p>
The definition of <tt><i>INVOKE</i></tt> should be extended to handle reference wrappers.
</p>

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

<p>
Moved to Review.
</p>
<p>
The wording seems accurate, but verbose.  If possible, we would like to define the kind of thing being
specified so carefully as one of a number of potential language constructs in a single place.  It is
also possible that this clause <i>is</i> that single place.
</p>

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


<p>Jonathan comments:</p>

<p>In the proposed resolution in the first bullet <tt>(t1.*f)</tt> is not valid if <tt>t1</tt> is a
<tt>reference_wrapper</tt>, so we probably need a separate bullet to handle the
<tt>reference_wrapper</tt> case.</p>

<p><i>[2014-02-14, Issaquah, Mike Spertus supplies wording]</i></p>


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

<blockquote class="note">

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

<ol>
<li><p>Edit 20.9.2 [func.require]:</p>
<blockquote><p>
Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
</p>
<ul>
<li><p>
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of type <del><tt>T</tt> or a reference 
to an object of a type derived from <tt>T</tt></del> <ins><tt>U</tt> or an object of type <tt>reference_wrapper&lt;U&gt;</tt> 
or a reference to an object of type <tt>reference_wrapper&lt;U&gt;</tt> where <tt>U</tt> is either the type 
<tt>T</tt> or a type derived from <tt>T</tt></ins>;
</p>
</li>

<li><p>
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> is not one of the types described in the previous item;
</p></li>

<li><p> 
<tt>t1.*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
is an object of type <tt>T</tt> or a reference to an object of type <del><tt>T</tt> or a reference to an object of a 
type derived from <tt>T</tt></del> <ins><tt>U</tt> or an object of type <tt>reference_wrapper&lt;U&gt;</tt> 
or a reference to an object of type <tt>reference_wrapper&lt;U&gt;</tt> where <tt>U</tt> is either the type 
<tt>T</tt> or a type derived from <tt>T</tt></ins>;
</p></li>

<li><p>
<tt>(*t1).*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
is not one of the types described in the previous item;
</p></li>

<li><p>
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
</p></li>
</ul>

</blockquote>

</li>
</ol>

</blockquote>
 
<p><i>[2014-10-01, STL adds discussion and provides an improved resolution]</i></p>

<p>
Because neither <tt>t1.*f</tt> nor <tt>(*t1).*f</tt> will compile when <tt>t1</tt> is <tt>reference_wrapper&lt;U&gt;</tt> 
for any <tt>U</tt>, we don't need to inspect <tt>U</tt> carefully. We can bluntly detect all <tt>reference_wrapper</tt>s 
and use <tt>get()</tt> for them.
<p/>
We would have to be more careful if we had to deal with pointers to members of <tt>reference_wrapper</tt> itself.  
Fortunately, we don't. First, it doesn't have user-visible data members. Second, users technically can't take the 
addresses of its member functions (this is a consequence of 17.6.5.5 [member.functions], the Implementer's Best Friend).
<p/>
While we're in the neighborhood, I recommend simplifying and clarifying the wording used to detect base/derived objects.
</p>

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

<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit 20.9.2 [func.require]:</p>
<blockquote><p>
Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
</p>
<ul>
<li><p>
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference 
to an object of a type derived from <tt>T</tt>;
</p>
</li>

<li><p>
<ins>
<tt>(t1.get().*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function
of class <tt>T</tt>
and <tt>t1</tt> is an object of type <tt>reference_wrapper&lt;U&gt;</tt> where <tt>U</tt>
is either the type <tt>T</tt> or a type derived from <tt>T</tt>.
</ins>
</p>
</li>

<li><p>
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> is not one of the types described in the previous item;
</p></li>



<li><p> 
<tt>t1.*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference to an object of a 
type derived from <tt>T</tt>;
</p></li>

<li><p>
<ins>
<tt>t1.get().*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a
class <tt>T</tt> and <tt>t1</tt> is an object of type <tt>reference_wrapper&lt;U&gt;</tt>
where <tt>U</tt> is either the type <tt>T</tt> or a type derived from <tt>T</tt>.
</ins>
</p></li>

<li><p>
<tt>(*t1).*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
is not one of the types described in the previous item;
</p></li>

<li><p>
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
</p></li>
</ul>

</blockquote>

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

<p><i>[2015-02, Cologne]</i></p>

<p>
Waiting for implementation experience. 
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL: latest note from Cologne, waiting for implementation experience<br/>
STL: don't think this is harder than anything else we do<br/>
MC: it does involve <tt>mem_fn</tt> and invoke<br/>
STL: my simplication was not to attempt fine-grained<br/>
STL: can ignore pmf<br/>
STL: can't invoke pmf to reference wrapper<br/>
STL: wording dated back to TR1 when there was no <tt>decltype</tt><br/>
MC: should <tt>decay_t&lt;decltype(t1)&gt;</tt> be pulled out since it is in multiple places<br/>
STL: it could be handled editorially<br/>
STL: we fix function, bind, invoke<br/>
STL: have not implemented this but believe it is fine<br/>
MC: Eric F, you have worked in invoke<br/>
EF: yes, looks ok<br/>
MC: consensus move to ready 
</p>


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

<ol>
<li><p>Change 20.9.2 [func.require] p1 as depicted:</p>
<blockquote><p>
Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
</p>
<ul>
<li><p>
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<del><tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference 
to an object of a type derived from <tt>T</tt></del><ins><tt>is_base_of&lt;T, decay_t&lt;decltype(t1)&gt;&gt;::value</tt> 
is true</ins>;
</p>
</li>

<li><p>
<ins><tt>(t1.get().*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>decay_t&lt;decltype(t1)&gt;</tt> is a specialization of <tt>reference_wrapper</tt>;</ins>
</p></li>

<li><p>
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function of a class <tt>T</tt> and 
<tt>t1</tt> <del>is not one of the types described in the previous item</del><ins>does not satisfy the previous two 
items</ins>;
</p></li>

<li><p> 
<tt>t1.*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <del><tt>t1</tt> 
is an object of type <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference to an object of a 
type derived from <tt>T</tt></del><ins><tt>is_base_of&lt;T, decay_t&lt;decltype(t1)&gt;&gt;::value</tt> 
is true</ins>;
</p></li>

<li><p>
<ins><tt>t1.get().*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and 
<tt>decay_t&lt;decltype(t1)&gt;</tt> is a specialization of <tt>reference_wrapper</tt>;</ins>
</p></li>

<li><p>
<tt>(*t1).*f</tt> when <tt>N == 1</tt> and <tt>f</tt> is a pointer to member data of a class <tt>T</tt> and <tt>t1</tt> 
<del>is not one of the types described in the previous item</del><ins>does not satisfy the previous two items</ins>;
</p></li>

<li><p>
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
</p></li>
</ul>

</blockquote>

</li>
</ol>






<hr>
<h3><a name="2224" href="#2224">2224.</a> Ambiguous status of access to non-live objects</h3>
<p><b>Section:</b> 17.6.4.10 [res.on.objects] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2012-12-17 <b>Last modified:</b> 2015-05-05</p>
<p><b>View all other</b> <a href="lwg-index.html#res.on.objects">issues</a> in [res.on.objects].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The standard currently does not discuss when library objects may be accessed, except in a non-normative 
note pertaining to synchronization in [res.on.objects], leaving it ambiguous whether single-threaded 
code can access a library object during its construction or destruction. For example, there is a 
reasonable question as to what happens if the deleter supplied to a <tt>unique_ptr</tt> transitively 
accesses the <tt>unique_ptr</tt> itself during <tt>unique_ptr</tt>'s destruction; a straightforward 
reading suggests that this is permitted, and that the deleter will see the <tt>unique_ptr</tt> still 
holding the originally stored pointer, but consensus on the LWG reflector indicates this was not the 
intent (see discussion beginning with 
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=33362">c++std-lib-33362</a>).
</p>

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

<p>
Moved to Open.
</p>
<p>
Geoffrey will provide an example that clearly highlights the issue.
</p>

<p><i>[2013-03-19 Geoffrey provides revised resolution and an example]</i></p>


<p>
I contend that the most straightforward reading of the current standard requires the following example code to print 
"good" (because <tt>~unique_ptr</tt> is not specified to modify the state of the internal pointer), but the consensus 
on the reflector was that its behavior should be undefined.
<p/>
This example also shows that, contrary to a comment in the telecon, the PR is not tautological. 12.7 [class.cdtor]/p4 
explicitly permits member function calls during destruction, so the behavior of this code is well-defined as far as 
the core language is concerned, despite the fact that it accesses a library object after the end of the object's 
lifetime. If we want this code to have undefined behavior, we need to specify that at the library level.
</p>

<blockquote><pre>
#include &lt;memory&gt;
#include &lt;iostream&gt;

class A;

struct B {
 std::unique_ptr&lt;A&gt; a;
};

struct A {
 B* b;
 ~A() {
   if (b-&gt;a.get() == this) {
     std::cout &lt;&lt; "good" &lt;&lt; std::endl;
   }
 }
};

int main() {
 B b;
 b.a.reset(new A);
 b.a-&gt;b = &amp;b;
}
</pre></blockquote>

<p>
Previous resolution:
</p>
<blockquote class="note">
<ol>
<li><p>Change the title of sub-clause 17.6.4.10 [res.on.objects] as indicated:</p>
<p><del>Shared objects and the library</del><ins>Library object access</ins> [res.on.objects]</p>
</li>

<li><p>Edit 17.6.4.10 [res.on.objects] p2 as indicated:</p>
<p>-2- <del>[<i>Note</i>: In particular, the program is required to ensure that completion of the constructor 
of any object of a class type defined in the standard library happens before any other member function 
invocation on that object and, unless otherwise specified, to ensure that completion of any member function 
invocation other than destruction on such an object happens before destruction of that object. This applies 
even to objects such as mutexes intended for thread synchronization. &mdash; <i>end note</i>]</del>
<ins>If an object of a standard library type is accessed outside of the object's lifetime (3.8 [basic.life]), 
the behavior is undefined unless otherwise specified.</ins></p>
</li>
</ol>
</blockquote>

<p><i>[2014 Urbana]</i></p>

<p>
STL: is this resolved by our change to the reeentrancy rules? [LWG <a href="lwg-active.html#2414">2414</a>]<br/>
GR: don't think that solves the multi-threaded case<br/>
MC: I like changing the note to normative text<br/>
GR: uses the magic "happens before" words, and "access" is magic too<br/>
JW: I like this. strict improvement, uses the right wording we have to say this properly<br/>
STL: I like the last sentence of the note, could we add that as a new note at the end?<br/>
So add "[Note: This applies even to objects such as mutexes intended for thread synchronization.]" to the end and move to Ready 
</p>


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

<ol>
<li><p>Change the title of sub-clause 17.6.4.10 [res.on.objects] as indicated:</p>
<p><del>Shared objects and the library</del><ins>Library object access</ins> [res.on.objects]</p>
</li>

<li><p>Edit 17.6.4.10 [res.on.objects] p2 as indicated: <em>[<i>Editorial remark:</i> The motivation, is to 
be more precise about the meaning of "outside the object's lifetime" in the presence of threads &mdash; <i>end editorial 
remark</i>]</em></p>
<p>-2- <del>[<i>Note</i>: In particular, the program is required to ensure that completion of the constructor 
of any object of a class type defined in the standard library happens before any other member function 
invocation on that object and, unless otherwise specified, to ensure that completion of any member function 
invocation other than destruction on such an object happens before destruction of that object. This applies 
even to objects such as mutexes intended for thread synchronization. &mdash; <i>end note</i>]</del>
<ins>If an object of a standard library type is accessed, and the beginning of the object's lifetime 
(3.8 [basic.life]) does not happen before the access, or the access does not happen before the end 
of the object's lifetime, the behavior is undefined unless otherwise specified. [<i>Note</i>: This applies even to 
objects such as mutexes intended for thread synchronization. &mdash; <i>end note</i>]</ins></p>
</li>
</ol>






<hr>
<h3><a name="2234" href="#2234">2234.</a> <tt>assert()</tt> should allow usage in constant expressions</h3>
<p><b>Section:</b> 19.3 [assertions] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-01-12 <b>Last modified:</b> 2015-09-27</p>
<p><b>View other</b> <a href="lwg-index-open.html#assertions">active issues</a> in [assertions].</p>
<p><b>View all other</b> <a href="lwg-index.html#assertions">issues</a> in [assertions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is unclear from the current specification whether <tt>assert()</tt> expressions can be used in 
(potential) constant expressions. As an example consider the implementation of a <tt>constexpr</tt>
function:
</p>

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

template&lt;class T, unsigned N&gt;
struct array {
  T data[N];
  constexpr const T&amp; operator[](unsigned i) const {
    return assert(i &lt; N), data[i];
  }
};

int main() {
  constexpr array&lt;int, 3&gt; ai = {1, 2, 3};
  constexpr int i = ai[0];
  int j = ai[0];
  // constexpr int k = ai[5];
}
</pre></blockquote>

<p>
The first question is whether this program is guaranteed well-formed? A second question is whether is would guaranteed to be
ill-formed, if we uncomment the last code line in <tt>main()</tt>?
</p>

<p>
The wording in 19.3 [assertions] doesn't add anything significant to the C99 wording. From the C99 specification 
(7.2 p1 and 7.2.1.1 p2) we get already some valuable guarantees:
</p>

<ul>
<li><p>
The expression <tt>assert(e)</tt> is a <tt>void</tt> expression for all expressions <tt>e</tt> independent of 
the definition of <tt>NDEBUG</tt>.
</p></li>
<li><p>
If <tt>NDEBUG</tt> is defined, <tt>assert(e)</tt> is equivalent to the expression <tt>void()</tt>
(or anything that cannot be distinguished from that).
</p></li>
</ul>

<p>
The current wording does not yet <em>guarantee</em> that <tt>assert</tt> expressions can be used in constant expressions,
but all tested implementations (gcc, MSVC) would already support this use-case. It seems to me that this should be possible
without giving <tt>assert</tt> a special meaning for the core language.
<p/>
As a related comment it should be added, that there is a core language 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3444.html">proposal</a> 
that intents to relax some current constraints for <tt>constexpr</tt> functions and <tt>literal</tt> types. The most 
interesting one (making <tt>void</tt> a literal types and allowing for expression-statements) would simplify the motivating 
example implementation of <tt>operator[]</tt> to:
</p>
<blockquote><pre>
constexpr const T&amp; operator[](unsigned i) const {
  assert(i &lt; N);
  return data[i];
};
</pre></blockquote>

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

<p>
Moved to Open.
</p>
<p>
We are still gaining experience with <tt>constexpr</tt> as a language feature, and there may
be work in Evolution that would help address some of these concerns.  Defer discussion until
we have a group familiar with any evolutionary direction.
</p>

<p><i>[2014-06-08, Daniel comments and suggests wording]</i></p>

<p>
After approval of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html"/>N3652<a/>,
<tt>void</tt> is now a literal type and <tt>constexpr</tt> functions can contain multiple statements, so
this makes the guarantee that <tt>assert</tt> expressions are per-se <tt>constexpr</tt>-friendly even more
relevant. A possible wording form could be along the lines of:
</p>
<blockquote>
<p>
For every core constant expression <em>e</em> of scalar type that evaluates to <tt>true</tt> after being contextually 
converted to <tt>bool</tt>, the expression <tt>assert(<em>e</em>)</tt> shall be a prvalue core constant expression of type 
<tt>void</tt>.
</p>
</blockquote>
<p>
Richard Smith pointed out some weaknesses of this wording form, for example it would not guarantee to require
the following example to work:
</p>
<blockquote><pre>
constexpr void check(bool b) { assert(b); }
</pre></blockquote>
<p>
because <tt>b</tt> is not a core constant expression in this context.
<p/>
He suggested improvements that lead to the wording form presented below (any defects mine). 
</p>

<p><i>[Lenexa 2015-05-05]</i></p>

<p>
MC : ran into this<br/>
Z : Is it guaranteed to be an expression?<br/>
MC : clarifies that assert runs at runtime, not sure what it does at compile time<br/>
STL : c standard guarantees its an expression and not a whole statement, so comma chaining it is ok<br/>
HH : Some implementations work as author wants it to<br/>
STL : also doing this as constexpr<br/>
DK/STL : discussing how this can actually work<br/>
HH : GCC 5 also implements it. We have implementor convergence<br/>
MC : Wants to do this without giving assert a special meaning<br/>
STL : NDEBUG being defined where assert appears is not how assert works. This is bug in wording. Should be "when assert is defined" or something like that. ... is a constant subexpression if NDEBUG is defined at the point where assert is last defined or redefined."<br/>
Would like to strike the "either" because ok if both debug or assertion is true. We want inclusive-or here<br/>
MC : is redefined needed?<br/>
STL : my mental model is its defined once and then redefined<br/>
HH : wants to up to P2<br/>
Z/STL : discussing how wording takes care of how/when assert is defined/redefefined<br/>
STL/WB : discussing whether to move to ready or review. -> Want to move it to ready.<br/>
ask for updated wording<br/>
p3 -> p2<br/>
plan to go to ready after checking wording<br/>
</p>

<p><i>[Telecom 2015-06-30]</i></p>

<p>
HH: standardizing existing practice<br/>
MC: what about the comment from Lenexa about striking "either"?<br/>
HH: all three implementations accept it<br/>
MC: update issue to strike "either" and move to Tentatively Ready<br/>
</p>



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

<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class="note"> 
<ol>
<li><p>Introduce the following new definition to the existing list in 17.3 [definitions]: [<i>Drafting note</i>:
If LWG <a href="lwg-active.html#2296">2296</a> is accepted before this issue, the accepted wording for the new definition should be used instead 
&mdash; <i>end drafting note</i>]</p>

<blockquote>
<p>
<strong>constant subexpression</strong> [defns.const.subexpr]
<p/>
an expression whose evaluation as subexpression of a <em>conditional-expression</em> <em>CE</em> (5.16 [expr.cond]) 
would not prevent <em>CE</em> from being a core constant expression (5.20 [expr.const]).
</p>
</blockquote>
</li>

<li><p>Insert a new paragraph following 19.3 [assertions] p1 as indicated:</p>

<blockquote>
<p>
<ins>-?- An expression <tt>assert(<em>E</em>)</tt> is a constant subexpression ( [defns.const.subexpr]), if either</ins>
</p>
<ul>
<li><p><ins><tt>NDEBUG</tt> is defined at the point where <tt>assert(<em>E</em>)</tt> appears, or</ins></p></li>
<li><p><ins><tt><em>E</em></tt> contextually converted to <tt>bool</tt> (4 [conv]), is a constant subexpression 
that evaluates to the value <tt>true</tt>.</ins></p></li>
</ul>
</blockquote>
</li>

</ol>
</blockquote>

<ol>
<li><p>Introduce the following new definition to the existing list in 17.3 [definitions]: [<i>Drafting note</i>:
If LWG <a href="lwg-active.html#2296">2296</a> is accepted before this issue, the accepted wording for the new definition should be used instead 
&mdash; <i>end drafting note</i>]</p>

<blockquote>
<p>
<strong>constant subexpression</strong> [defns.const.subexpr]
<p/>
an expression whose evaluation as subexpression of a <em>conditional-expression</em> <em>CE</em> (5.16 [expr.cond]) 
would not prevent <em>CE</em> from being a core constant expression (5.20 [expr.const]).
</p>
</blockquote>
</li>

<li><p>Insert a new paragraph following 19.3 [assertions] p1 as indicated:</p>

<blockquote>
<p>
<ins>-?- An expression <tt>assert(<em>E</em>)</tt> is a constant subexpression ( [defns.const.subexpr]), if </ins>
</p>
<ul>
<li><p><ins><tt>NDEBUG</tt> is defined at the point where <tt>assert(<em>E</em>)</tt> appears, or</ins></p></li>
<li><p><ins><tt><em>E</em></tt> contextually converted to <tt>bool</tt> (4 [conv]), is a constant subexpression 
that evaluates to the value <tt>true</tt>.</ins></p></li>
</ul>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2244" href="#2244">2244.</a> Issue on <tt>basic_istream::seekg</tt></h3>
<p><b>Section:</b> 27.7.2.3 [istream.unformatted] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-03-04 <b>Last modified:</b> 2015-05-22</p>
<p><b>View other</b> <a href="lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When issue <a href="lwg-defects.html#1445">1445</a> was resolved by adopting 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">N3168</a>, it exposed the need to 
modify both overloads of <tt>basic_istream::seekg</tt> (by inserting "the function clears eofbit," after "except that"), 
but the fix applied to the text apparently forgets the second overload at 27.7.2.3 [istream.unformatted] p43.
</p>

<p><i>[2013-10-17: Daniel provides concrete wording]</i></p>


<p>
It seems that the tiny sentence "SIMILARLY for 27.7.1.3/43 (<tt>seekg</tt>)." had been overlooked. I agree that the wording needs to be
applied here as well.
</p>

<p><i>[2015-05-06 Lenexa: Move to Ready]</i></p>

<p>MC: This was just missed when we added "the function first clears eofbit" to the other overload, Daniel agrees. Editing mistake.</p>
<p>Move to Ready, consensus.</p>



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

<ol>
<li><p>Change 27.7.2.3 [istream.unformatted] p43 as indicated:</p>

<blockquote><pre>
basic_istream&lt;charT,traits&gt;&amp; seekg(off_type off, ios_base::seekdir dir);
</pre><blockquote>
<p>
-43- <i>Effects:</i> Behaves as an unformatted input function (as described in 27.7.2.3, paragraph 1), except
that <ins>the function first clears <tt>eofbit</tt>,</ins> it does not count the number of characters extracted<ins>,</ins> 
and does not affect the value returned by subsequent calls to <tt>gcount()</tt>. [&hellip;]
</p>
</blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2250" href="#2250">2250.</a> Follow-up On Library Issue 2207</h3>
<p><b>Section:</b> 20.6.1 [bitset.cons], 20.6.2 [bitset.members], 21.4.2 [string.cons], 21.4.6 [string.modifiers], 21.4.7 [string.ops] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Frank Birbacher <b>Opened:</b> 2013-04-18 <b>Last modified:</b> 2015-09-25</p>
<p><b>View all other</b> <a href="lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Similar to LWG <a href="lwg-defects.html#2207">2207</a> there are several other places where the "Requires" clause precludes the "Throws" condition. 
Searching for the <tt>out_of_range</tt> exception to be thrown, the following have been found (based on the working draft
N3485):
</p>

<ol>
<li><p>20.6.1 [bitset.cons] p3+4</p></li>
<li><p>20.6.2 [bitset.members] p13+14 (<tt>set</tt>)</p></li>
<li><p>20.6.2 [bitset.members] p19+20 (<tt>reset</tt>)</p></li>
<li><p>20.6.2 [bitset.members] p27+28 (<tt>flip</tt>)</p></li>
<li><p>20.6.2 [bitset.members] p41+42 (<tt>test</tt>)</p></li>
<li><p>21.4.2 [string.cons] p3+4</p></li>
<li><p>21.4.6.2 [string::append] p3+4</p></li>
<li><p>21.4.6.3 [string::assign] p4+5</p></li>
<li><p>21.4.6.4 [string::insert] p1+2, p5+6, p9+10 (partially)</p></li>
<li><p>21.4.6.5 [string::erase] p1+2</p></li>
<li><p>21.4.6.6 [string::replace] p1+2, p5+6, p9+10 (partially)</p></li>
<li><p>21.4.6.7 [string::copy] p1+2</p></li>
<li><p>21.4.7.8 [string::substr] p1+2</p></li>
</ol>

<p><i>[2013-10-15: Daniel provides wording]</i></p>


<p>
In addition to the examples mentioned in the discussion, a similar defect exists for <tt>thread</tt>'s <tt>join()</tt> 
and <tt>detach</tt> functions (see 30.3.1.5 [thread.thread.member]). The suggested wording applies a similar fix for these
as well.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL : likes it<br/>
DK : does it change behavior?<br/>
Multiple : no<br/>
Move to ready? Unanimous 
</p>


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

<ol>
<li><p>Modify 20.6.1 [bitset.cons] as indicated: <em>[Editorial comment: The wording form used to ammend the 
<i>Throws</i> element is borrowed from a similar style used in 21.4.6.6 [string::replace] p10]</em></p>

<blockquote><pre>
template &lt;class charT, class traits, class Allocator&gt;
explicit
bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
       typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
       typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
         basic_string&lt;charT, traits, Allocator&gt;::npos,
         charT zero = charT('0'), charT one = charT('1'));
</pre><blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>pos &lt;= str.size()</tt>.</del>
<p/>
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt> <ins>or <tt>invalid_argument</tt> if an
invalid character is found (see below)</ins>.
<p/>
-5- <i>Effects:</i> Determines the effective length <tt>rlen</tt> of the initializing string as the smaller of <tt>n</tt> and 
<tt>str.size() - pos</tt>.
<p/>
The function then throws <tt>invalid_argument</tt> if any of the <tt>rlen</tt> characters in <tt>str</tt> beginning at position
<tt>pos</tt> is other than <tt>zero</tt> or <tt>one</tt>. The function uses <tt>traits::eq()</tt> to compare the character values.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 20.6.2 [bitset.members] as indicated:</p>

<blockquote><pre>
bitset&lt;N&gt;&amp; set(size_t pos, bool val = true);
</pre><blockquote>
<p>
<del>-13- <i>Requires:</i> <tt>pos</tt> is valid</del>
<p/>
-14- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
bitset&lt;N&gt;&amp; reset(size_t pos);
</pre><blockquote>
<p>
<del>-19- <i>Requires:</i> <tt>pos</tt> is valid</del>
<p/>
-20- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
bitset&lt;N&gt;&amp; flip(size_t pos);
</pre><blockquote>
<p>
<del>-27- <i>Requires:</i> <tt>pos</tt> is valid</del>
<p/>
-28- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
bool test(size_t pos) const;
</pre><blockquote>
<p>
<del>-41- <i>Requires:</i> <tt>pos</tt> is valid</del>
<p/>
-42- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit position.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

</li>

<li><p>Modify 21.4.2 [string.cons] as indicated:</p>

<blockquote><pre>
basic_string(const basic_string&amp; str,
             size_type pos, size_type n = npos,
             const Allocator&amp; a = Allocator());
</pre><blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>pos &lt;= str.size()</tt></del>
<p/>
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.4 [string.capacity] as indicated:</p>

<blockquote><pre>
void resize(size_type n, charT c);
</pre><blockquote>
<p>
<del>-6- <i>Requires:</i> <tt>n &lt;= max_size()</tt></del>
<p/>
-7- <i>Throws:</i> <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.2 [string::append] as indicated:</p>

<blockquote><pre>
basic_string&amp;
  append(const basic_string&amp; str, size_type pos, size_type n = npos);
</pre><blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>pos &lt;= str.size()</tt></del>
<p/>
-4- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.3 [string::assign] as indicated:</p>

<blockquote><pre>
basic_string&amp;
  assign(const basic_string&amp; str, size_type pos, 
         size_type n = npos);
</pre><blockquote>
<p>
<del>-5- <i>Requires:</i> <tt>pos &lt;= str.size()</tt></del>
<p/>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt>.
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.4 [string::insert] as indicated: <em>[Editorial note: The first change suggestion is also a bug fix
of the current wording, because (a) the function has parameter <tt>pos1</tt> but the semantics refers to <tt>pos</tt> and (b) 
it is possible that this function can throw <tt>length_error</tt>, see p10]</em></p>

<blockquote><pre>
basic_string&amp;
  insert(size_type pos<del>1</del>, const basic_string&amp; str);
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos &lt;= size()</tt>.</del>
<p/>
<del>-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.</del>
<p/>
-3- <i>Effects:</i> <del>Calls</del><ins>Equivalent to:</ins> <tt><ins>return</ins> insert(pos, str.data(), str.size())<ins>;</ins></tt><del>.</del>
<p/>
<del>-4- <i>Returns:</i> <tt>*this</tt>.</del>
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  insert(size_type pos1, const basic_string&amp; str,
         size_type pos2, size_type n = npos);
</pre><blockquote>
<p>
<del>-5- <i>Requires:</i> <tt>pos1 &lt;= size()</tt> and <tt>pos2 &lt;= str.size()</tt>.</del>
<p/>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>pos2 &gt; str.size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  insert(size_type pos, const charT* s, size_type n);
</pre><blockquote>
<p>
-9- <i>Requires:</i> <tt>s</tt> points to an array of at least <tt>n</tt> elements of <tt>charT</tt> <del>and 
<tt>pos &lt;= size()</tt></del>.
<p/>
-10- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt> or <tt>length_error</tt> if <tt>size() + n &gt; max_size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  insert(size_type pos, const charT* s);
</pre><blockquote>
<p>
-13- <i>Requires:</i> <del><tt>pos &lt;= size()</tt> and</del> <tt>s</tt> points to an array of at least 
<tt>traits::length(s) + 1</tt> elements of <tt>charT</tt>.
<p/>
-14- <i>Effects:</i> Equivalent to <tt><ins>return</ins> insert(pos, s, traits::length(s))<ins>;</ins></tt><del>.</del>
<p/>
<del>-15- <i>Returns:</i> <tt>*this</tt>.</del>
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.5 [string::erase] as indicated:</p>

<blockquote><pre>
basic_string&amp; erase(size_type pos = 0, size_type n = npos);
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos &lt;= size()</tt></del>
<p/>
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.6.6 [string::replace] as indicated: <em>[Editorial note: The first change suggestion is also a bug fix
of the current wording, because it is possible that this function can throw <tt>length_error</tt>, see p10]</em></p>

<blockquote><pre>
basic_string&amp;
  replace(size_type pos1, size_type n1,
          const basic_string&amp; str);
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos1 &lt;= size()</tt>.</del>
<p/>
<del>-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt>.</del>
<p/>
-3- <i>Effects:</i> <del>Calls</del><ins>Equivalent to</ins> <tt><ins>return</ins> replace(pos1, n1, str.data(), str.size())<ins>;</ins></tt><del>.</del>
<p/>
<del>-4- <i>Returns:</i> <tt>*this</tt>.</del>
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  replace(size_type pos1, size_type n1,
          const basic_string&amp; str,
          size_type pos2, size_type n = npos);
</pre><blockquote>
<p>
<del>-5- <i>Requires:</i> <tt>pos1 &lt;= size()</tt> and <tt>pos2 &lt;= str.size()</tt>.</del>
<p/>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>pos2 &gt; str.size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  replace(size_type pos1, size_type n1, const charT* s, size_type n2);
</pre><blockquote>
<p>
-9- <i>Requires:</i> <del><tt>pos1 &lt;= size()</tt> and</del> <tt>s</tt> points to an array of at least <tt>n2</tt> elements 
of <tt>charT</tt>.
<p/>
-10- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>length_error</tt> if the length of the resulting 
string would exceed <tt>max_size()</tt> (see below).
<p/>
[&hellip;]
</p>
</blockquote></blockquote>

<blockquote><pre>
basic_string&amp;
  replace(size_type pos, size_type n, const charT* s);
</pre><blockquote>
<p>
-13- <i>Requires:</i> <del><tt>pos &lt;= size()</tt> and</del> <tt>s</tt> points to an array of at least 
<tt>traits::length(s) + 1</tt> elements of <tt>charT</tt>.
<p/>
-14- <i>Effects:</i> Equivalent to <tt><ins>return</ins> replace(pos, n, s, traits::length(s))<ins>;</ins></tt><del>.</del>
<p/>
<del>-15- <i>Returns:</i> <tt>*this</tt>.</del>
</p>
</blockquote></blockquote>

</li>

<li><p>Modify 21.4.6.7 [string::copy] as indicated:</p>

<blockquote><pre>
size_type copy(charT* s, size_type n, size_type pos = 0) const;
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos &lt;= size()</tt></del>
<p/>
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 21.4.7.8 [string::substr] as indicated:</p>

<blockquote><pre>
basic_string substr(size_type pos = 0, size_type n = npos) const;
</pre><blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>pos &lt;= size()</tt></del>
<p/>
-2- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
<p/>
[&hellip;]
</p>
</blockquote></blockquote>
</li>

<li><p>Modify 30.3.1.5 [thread.thread.member] as indicated:</p>

<blockquote><pre>
void join();
</pre><blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>joinable()</tt> is true.</del>
<p/>
[&hellip;]
<p/>
-7- <i>Throws:</i> <tt>system_error</tt> when an exception is required (30.2.2).
<p/>
-8- <i>Error conditions:</i>
</p>
<ul>
<li><p>[&hellip;]</p></li>
<li><p><tt>invalid_argument</tt> &mdash; if the thread is not joinable.</p></li>
</ul>
</blockquote></blockquote>

<blockquote><pre>
void detach();
</pre><blockquote>
<p>
<del>-9- <i>Requires:</i> <tt>joinable()</tt> is true.</del>
<p/>
[&hellip;]
<p/>
-12- <i>Throws:</i> <tt>system_error</tt> when an exception is required (30.2.2).
<p/>
-13- <i>Error conditions:</i>
</p>
<ul>
<li><p>[&hellip;]</p></li>
<li><p><tt>invalid_argument</tt> &mdash; if the thread is not joinable.</p></li>
</ul>
</blockquote></blockquote>
</li>

</ol>

<hr>
<h3><a name="2259" href="#2259">2259.</a> Issues in 17.6.5.5 rules for member functions</h3>
<p><b>Section:</b> 17.6.5.5 [member.functions] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2013-05-12 <b>Last modified:</b> 2015-09-25</p>
<p><b>View all other</b> <a href="lwg-index.html#member.functions">issues</a> in [member.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
17.6.5.5 [member.functions] p2 says:
</p>

<blockquote><p>
&quot;An implementation may declare additional non-virtual member function signatures within a class:
</p>
<ul>
<li>by adding arguments with default values to a member function signature; [Footnote: Hence, the address of a member 
function of a class in the C++ standard library has an unspecified type.] [<i>Note</i>: An implementation
may not add arguments with default values to virtual, global, or non-member functions. &mdash; <i>end note</i>]</li>
<li>by replacing a member function signature with default values by two or more member function signatures
with equivalent behavior; and</li>
<li>by adding a member function signature for a member function name.&quot;</li>
</ul>
</blockquote>

<ol>
<li>
<p>
This wording is not using the correct terminology. "by adding arguments with default values" presumably means 
"by adding parameters with default arguments", and likewise throughout.
</p>
</li>
<li>
<p>
This paragraph only allows an implementation to declare "additional" signatures, but the first bullet is talking 
about replacing a standard signature with one with additional parameters.
</p>
</li>
<li>
<p>
None of these bullets allows a member function with no <i>ref</i>-qualifier to be replaced by signatures with <i>ref</i>-qualifiers 
(a situation which was just discussed on std-proposals), and likewise for <i>cv</i>-qualifiers. Presumably that is 
not intentional, and such changes should be permissible.
</p>
</li>
</ol>

<p>
I think the first two items are probably editorial, since the intent is clear.
</p>

<p><i>[2013-12-11 Richard provides concrete wording]</i></p>

<p>
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
JW: I don't like that this loses the footnote about the address of member functions having an unspecified type, 
the footnote is good to be able to point to as an explicit clarification of one consequence of the normative wording.<br/>
MC: so we want to keep the footnote<br/>
STL: doesn't need to be a footnote, can be an inline Note<br/>
JW: does this have any impact on our ability to add totally different functions with unrelated names, not described in 
the standard?<br/>
MC: no, the old wording didn't refer to such functions anyway<br/>
Move to Ready and include in motion on Friday?<br/>
9 in favor, 0 opposed, 2 abstention 
</p>


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

<ol>
<li><p>Merge 17.6.5.5 [member.functions]p2+3 as indicated:</p>

<blockquote>
<p>
-2- <del>An implementation may declare additional non-virtual member function signatures within a class:</del>
</p>
<ul>
<li><p>
<del>by adding arguments with default values to a member function signature;188 [<i>Note:</i> An implementation
may not add arguments with default values to virtual, global, or non-member functions. &mdash; <i>end note</i>]</del>
</p></li>
<li><p>
<del>by replacing a member function signature with default values by two or more member function signatures
with equivalent behavior; and</del>
</p></li>
<li><p>
<del>by adding a member function signature for a member function name.</del>
</p></li>
</ul>
<p>
<del>-3- A call to a member function signature described in the C++ standard library behaves as if the implementation
declares no additional member function signatures.[Footnote: A valid C++ program always calls the expected library 
member function, or one with equivalent behavior. An implementation may also define additional member functions 
that would otherwise not be called by a valid C++ program.]</del> <ins>For a non-virtual member function described 
in the C++ standard library, an implementation may declare a different set of member function signatures, provided 
that any call to the member function that would select an overload from the set of declarations described in this 
standard behaves as if that overload were selected. [<i>Note:</i> For instance, an implementation may add parameters 
with default values, or replace a member function with default arguments with two or more member functions with 
equivalent behavior, or add additional signatures for a member function name. &mdash; <i>end note</i>]</ins>
</p>

</blockquote>
</li>

</ol>





<hr>
<h3><a name="2273" href="#2273">2273.</a> <tt>regex_match</tt> ambiguity</h3>
<p><b>Section:</b> 28.11.2 [re.alg.match] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2013-07-14 <b>Last modified:</b> 2015-09-14</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
28.11.2 [re.alg.match] p2 in describing regex_match says:
</p>
<blockquote>
<p>
-2-  <i>Effects:</i> Determines whether there is a match between the regular expression <tt>e</tt>, and all of 
the character sequence <tt>[first,last)</tt>. The parameter <tt>flags</tt> is used to control how the expression 
is matched against the character sequence. Returns true if such a match exists, false otherwise.
</p>
</blockquote>

<p>
It has come to my attention that different people are interpreting the first sentence of p2 in different ways:
</p>

<ol>
<li><p>
If a search of the input string using the regular expression <tt>e</tt> matches the entire input string, 
<tt>regex_match</tt> should return true.
</p></li>
<li><p>
Search the input string using the regular expression <tt>e</tt>. Reject all matches that do not match the 
entire input string. If a such a match is found, return true.
</p></li>
</ol>

<p>
The difference between these two subtly different interpretations is found using the following ECMAScript example:
</p>

<blockquote><pre>
std::regex re("Get|GetValue");
</pre></blockquote>

<p>
Using <tt>regex_search</tt>, this <tt>re</tt> can never match the input string <tt>"GetValue"</tt>, because ECMA 
specifies that alternations are ordered, not greedy. As soon as <tt>"Get"</tt> is matched in the left alternation, 
the matching algorithm stops.
<p/>
Using definition 1, <tt>regex_match</tt> would return false for an input string of <tt>"GetValue"</tt>.
<p/>
However definition 2 alters the grammar and appears equivalent to augmenting the regex with a trailing <tt>'$'</tt>, 
which is an anchor that specifies, reject any matches which do not come at the end of the input sequence.
So, using definition 2, <tt>regex_match</tt> would return true for an input string of <tt>"GetValue"</tt>.
<p/>
My opinion is that it would be strange to have <tt>regex_match</tt> return true for a <tt>string/regex</tt> 
pair that <tt>regex_search</tt> could never find. I.e. I favor definition 1.
<p/>
John Maddock writes:
<p/>
The intention was always that <tt>regex_match</tt> would reject any match candidate which didn't match the entire 
input string. So it would find <tt>GetValue</tt> in this case because the <tt>"Get"</tt> alternative had already 
been rejected as not matching. Note that the comparison with ECMA script is somewhat moot, as ECMAScript defines 
the regex grammar (the bit we've imported), it does not define anything like <tt>regex_match</tt>, nor do we import 
from ECMAScript the behaviour of that function. So IMO the function should behave consistently regardless of the 
regex dialect chosen. Saying "use awk regexes" doesn't cut it, because that changes the grammar in other ways.
<p/>
(John favors definition 2).
<p/>
We need to clarify 28.11.2 [re.alg.match]/p2 in one of these two directions.
</p>

<p><i>[2014-06-21, Rapperswil]</i></p>

<p>
AM: I think there's a clear direction and consensus we agree with John Maddock's position, and if noone else 
thinks we need the other function I won't ask for it.
<p/>
Marshall Clow and STL to draft.
</p>

<p><i>[2015-06-10, Marshall suggests concrete wording]</i></p>


<p><i>[2015-01-11, Telecom]</i></p>

<p>Move to Tenatatively Ready</p>


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

<ol>
<li><p>Change 28.11.2 [re.alg.match]/2, as follows:</p>

<blockquote><pre>
template &lt;class BidirectionalIterator, class Allocator, class charT, class traits&gt;
  bool regex_match(BidirectionalIterator first, BidirectionalIterator last,
                   match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m,
                   const basic_regex&lt;charT, traits>&amp; e,
                   regex_constants::match_flag_type flags =
                     regex_constants::match_default);
</pre>
<blockquote>
<p>
-1- <i>Requires</i>: The type <tt>BidirectionalIterator</tt> shall satisfy the requirements of a Bidirectional Iterator
(24.2.6).
<p/>
-2- <i>Effects</i>: Determines whether there is a match between the regular expression <tt>e</tt>, and all of the character
sequence <tt>[first,last)</tt>. The parameter <tt>flags</tt> is used to control how the expression is matched against
the character sequence. <ins>When determining if there is a match, only potential matches that match the entire character 
sequence are considered.</ins> Returns <tt>true</tt> if such a match exists, <tt>false</tt> otherwise. <ins>[<i>Example</i>:</ins>
</p>
<blockquote>
<pre>
<ins>std::regex re("Get|GetValue");
std::cmatch m;
regex_search("GetValue", m, re);	// returns true, and m[0] contains "Get"
regex_match ("GetValue", m, re);	// returns true, and m[0] contains "GetValue"
regex_search("GetValues", m, re);	// returns true, and m[0] contains "Get"
regex_match ("GetValues", m, re);	// returns false</ins>
</pre>
</blockquote>
<p>
<ins>&mdash; <i>end example</i>]</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2336" href="#2336">2336.</a> <tt>is_trivially_constructible/is_trivially_assignable</tt> traits are always false</h3>
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-10-01 <b>Last modified:</b> 2015-05-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 20.10.4.3 [meta.unary.prop] we have traits to allow testing for triviality of specific operations, such as
<tt>is_trivially_constructible</tt> and <tt>is_trivially_assignable</tt> (and their derived forms), which are specified
in terms of the following initialization and assignment, respectively:
</p>
<blockquote><pre>
T t(create&lt;Args&gt;()...);

declval&lt;T&gt;() = declval&lt;U&gt;()
</pre></blockquote>
<p>
The wording that describes the way how triviality is deduced, is in both cases of the same form:
</p>
<blockquote><p>
[&hellip; ] and the variable definition/assignment, as defined by <tt>is_constructible/is_assignable</tt>, is known
to call no operation that is not trivial (3.9, 12).
</p></blockquote>
<p>
The problematic part of this wording is that both definitions are specified in terms of an "object construction" function
<tt>create</tt> or <tt>declval</tt>, respectively, (The former being a conceptual function, the latter being a library function), 
but for none of these functions we can assume that they could be considered as trivial &mdash; only special member functions can 
have this property and none of these is one. This problem became obvious, when the similar issue LWG <a href="lwg-defects.html#2298">2298</a> 
in regard to <tt>is_nothrow_constructible</tt> was opened.
<p/>
A possible approach to solve this specification problem is to make a blanket statement for sub-clause 20.10.4.3 [meta.unary.prop]
that these helper functions are considered trivial for the purpose of defining these traits.
<p/>
Using this kind of wording technique can also be used to get rid of the additional helper function template <tt>create</tt>, which
is currently needed for the <tt>is_convertible</tt> and the <tt>is_constructible</tt> traits, because both traits are specified in
terms of contexts where technically the corresponding "object construction" function would be considered as odr-used. This is problematic,
because these traits are defined in terms of well-formed code and odr-using <tt>declval</tt> would make the program ill-formed (see
20.2.5 [declval]). So extending above blanket statement to consider <tt>std::declval&lt;T&gt;()</tt> as not odr-used
in the context of the corresponding trait definition would allow for replacing <tt>create</tt> by <tt>declval</tt>.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL: would you consider moving the change to 20.10 as editorial or are you uncomfortable with it?<br/>
JW: this sounds a viable editorial change<br/>
VV: I guarantee you that moving it doesn't change anything<br/>
MC: how about this: we move it to Ready as is and if we conclude moving it is editorial we can do it and if not open an issue<br/>
STL: I would like to guarantee that the lifting happens<br/>
JW: I do that! If it goes in I move it up<br/>
MC: move to Ready: in favor: 15, opposed: 0, abstain: 1 
</p>


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

<ol>
<li><p>Add a new paragraph after 20.10.4.3 [meta.unary.prop] p3 as indicated: <em>[Editorial note: The first change in
20.10.4.3 [meta.unary.prop] p3 is recommended, because technically a Clause is always a "main chapter" &mdash; such as
Clause 20 &mdash; but every child of a Clause or sub-clause is a sub-clause]</em></p>

<blockquote>
<p>
[&hellip;]
<p/>
-3- For all of the class templates <tt>X</tt> declared in this <del>Clause</del><ins>sub-clause</ins>, instantiating that 
template with a template-argument that is a class template specialization may result in the implicit instantiation of the 
template argument if and only if the semantics of <tt>X</tt> require that the argument must be a complete type.
<p/>
<ins>-?- For the purpose of defining the templates in this sub-clause, a function call expression 
<tt>declval&lt;T&gt;()</tt> for any type <tt>T</tt> is considered to be a trivial (3.9 [basic.types], 12 [special]) 
function call that is not an odr-use (3.2 [basic.def.odr]) of <tt>declval</tt> in the context of the corresponding definition 
notwithstanding the restrictions of 20.2.5 [declval].</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 20.10.4.3 [meta.unary.prop] p7 as indicated:</p>

<blockquote>
<p>
-7- <del>Given the following function prototype:</del>
</p>
<blockquote><pre>
<del>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();</del>
</pre></blockquote>
<p>
<del>t</del><ins>T</ins>he predicate condition for a template specialization <tt>is_constructible&lt;T, Args...&gt;</tt> 
shall be satisfied if and only if the following variable definition would be well-formed for some invented variable <tt>t</tt>:
</p>
<blockquote><pre>
T t(<del>create</del><ins>declval</ins>&lt;Args&gt;()...);
</pre></blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Add a new paragraph after 20.10.6 [meta.rel] p2 as indicated: <em>[Editorial note: Technically we don't need
the guarantee of "a trivial function call" for the type relationship predicates at the very moment, but it seems more robust and
consistent to have the exact same guarantee here as well]</em>
</p>
<blockquote>
<p>
[&hellip;]
<p/>
-2- [&hellip;]
<p/>
<ins>-?- For the purpose of defining the templates in this sub-clause, a function call expression 
<tt>declval&lt;T&gt;()</tt> for any type <tt>T</tt> is considered to be a trivial (3.9 [basic.types], 12 [special]) 
function call that is not an odr-use (3.2 [basic.def.odr]) of <tt>declval</tt> in the context of the corresponding definition 
notwithstanding the restrictions of 20.2.5 [declval].</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 20.10.6 [meta.rel] p4 as indicated:</p>

<blockquote>
<p>
-4- <del>Given the following function prototype:</del>
</p>
<blockquote><pre>
<del>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();</del>
</pre></blockquote>
<p>
<del>t</del><ins>T</ins>he predicate condition for a template specialization <tt>is_convertible&lt;From, To&gt;</tt> 
shall be satisfied if and only if the return expression in the following code would be well-formed, including any implicit 
conversions to the return type of the function:
</p>
<blockquote><pre>
To test() {
  return <del>create</del><ins>declval</ins>&lt;From&gt;();
}
</pre></blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2353" href="#2353">2353.</a> <tt>std::next</tt> is over-constrained</h3>
<p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2013-12-24 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In LWG <a href="lwg-defects.html#1011">1011</a>, <tt>std::next</tt> and <tt>std::prev</tt> were changed 
from accepting <tt>InputIterator</tt> to accepting
<tt>ForwardIterator</tt>. This needlessly excludes perfectly legitimate use
cases. Consider the following hypothetical range-based implementation of
drop, which creates a view of a range without the first <tt>n</tt> elements:
</p>
<blockquote><pre>
template&lt;typename Distance, typename InputRange&gt;
iterator_range&lt;range_iterator_t&lt;InputRange&gt;&gt;
drop(Distance n, InputRange&amp; rng)
{
  return make_iterator_range(
    std::next(std::begin(rng), n),
    std::end(rng)
  );
}
</pre></blockquote>
<p>
I believe this to be a legitimate use case that is currently outlawed by
the standard without cause. See the discussion beginning at
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=35313">c++std-lib-35313</a> 
for an in-depth discussion of the issue, in which
Howard Hinnant agreed that it was a defect.
<p/>
(Some discussion then ensued about whether an overload should be added
that only accepts rvalue <tt>InputIterators</tt> to avoid the surprise that issue
<a href="lwg-defects.html#1011">1011</a> sought to address. I make no such attempt, nor do I believe it to
be necessary.)
<p/>
Suggested resolution:
<p/>
Back out the resolution of <a href="lwg-defects.html#1011">1011</a>.
</p>

<p><i>[Lenexa 2015-05-07: Move to Ready]</i></p>



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

<ol>
<li><p>Change 24.3 [iterator.synopsis], header <tt>&lt;iterator&gt;</tt> synopsis, and 24.4.4 [iterator.operations]
before p.6 as indicated:</p>

<blockquote><pre>
template &lt;class <del>Forward</del><ins>Input</ins>Iterator&gt;
  <del>Forward</del><ins>Input</ins>Iterator next(<del>Forward</del><ins>Input</ins>Iterator x,
    typename std::iterator_traits&lt;<del>Forward</del><ins>Input</ins>Iterator&gt;::difference_type n = 1);
</pre></blockquote>
</li>

</ol>





<hr>
<h3><a name="2367" href="#2367">2367.</a> <tt>pair</tt> and <tt>tuple</tt> are not correctly implemented for <tt>is_constructible</tt> with no args</h3>
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2014-02-19 <b>Last modified:</b> 2015-05-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider:
</p>
<blockquote><pre>
struct X
{
  X() = delete;
};

int main()
{
  typedef std::pair&lt;int, X&gt; P;
  static_assert(!std::is_constructible&lt;P&gt;::value, "");
  static_assert(!std::is_default_constructible&lt;P&gt;::value, "");
  typedef std::tuple&lt;int, X&gt; T;
  static_assert(!std::is_constructible&lt;T&gt;::value, "");
  static_assert(!std::is_default_constructible&lt;T&gt;::value, "");
}
</pre></blockquote>
<p>
For me these <tt>static_asserts</tt> fail. And worse than that, even asking the question fails (as opposed to gets the wrong answer):
</p>
<blockquote><pre>
assert(!std::is_constructible&lt;P&gt;::value);
</pre></blockquote>
<p>
In file included from test.cpp:2:
</p>
<blockquote><pre>
error:
      call to deleted constructor of 'X'
   pair() : first(), second() {}
                     ^
note: function has been explicitly marked deleted here
    X() = delete;
    ^
1 error generated.
</pre></blockquote>
<p>
This can be solved by specializing <tt>is_constructible</tt> on <tt>pair</tt> and <tt>tuple</tt> for zero Args:
</p>
<blockquote><pre>
template &lt;class T, class U&gt;
struct is_constructible&lt;pair&lt;T, U&gt;&gt;
  : integral_constant&lt;bool, is_default_constructible&lt;T&gt;::value &amp;&amp;
                            is_default_constructible&lt;U&gt;::value&gt;
{};

template &lt;class ...T&gt;
struct is_constructible&lt;tuple&lt;T...&gt;&gt;
  : integral_constant&lt;bool,
                      __all&lt;is_default_constructible&lt;T&gt;::value...&gt;::value&gt;
{};
</pre></blockquote>
<p>
Now everything just works.
</p>

<p><i>[2014-05-14, Daniel comments]</i></p>


<p>
The proposed resolution is incomplete, because it wouldn't work for <i>cv</i>-qualified objects of
<tt>pair</tt> or for references of them during reference-initialization.
<p/>
I would like to point out that the approach suggested in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3739.html">N3739</a>
can be easily extended to solve the problem without need to muddle with specializing <tt>is_constructible</tt>:
</p>
<blockquote><pre>
template&lt;class U1 = T1, class U2 = T2,
  typename enable_if&lt;
    is_default_constructible&lt;U1&gt;::value &amp;&amp; is_default_constructible&lt;U2&gt;::value
  , bool&gt;::type = false
&gt;
constexpr pair();
</pre></blockquote>
<p>
The new wording proposal represents an alternative wording change that I would strongly prefer.
</p>

<strong>Previous resolution from Howard [SUPERSEDED]:</strong>
<p/>
<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Add to 20.3.3 [pairs.spec]:</p>

<blockquote>
<pre>
<ins>template &lt;class T, class U&gt;
struct is_constructible&lt;pair&lt;T, U&gt;&gt;
  : integral_constant&lt;bool, is_default_constructible&lt;T&gt;::value &amp;&amp;
                            is_default_constructible&lt;U&gt;::value&gt;
{};</ins>
</pre>
</blockquote>
</li>

<li><p>Add to 20.4.2.9 [tuple.special]:</p>

<blockquote>
<pre>
<ins>template &lt;class ...T&gt;
struct is_constructible&lt;tuple&lt;T...&gt;&gt;
  : integral_constant&lt;bool, <i>see below</i>&gt;
{};</ins>
</pre>
<blockquote><p>
<ins>-?- The second argument to <tt>integral_constant</tt> shall be true if for each <tt>T</tt>, 
<tt>is_default_constructible&lt;T&gt;::value</tt> is true.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL: I object to this resolution due to British spelling of behavior<br/>
JW: we already have other places of this spelling<br/>
VV: the easy resolution is to remove the notes<br/>
MC: if that's all we want to change: put it in and make the editorial change of removing the note<br/>
VV: the other paper doesn't make any of these changes so it would be consistent<br/>
JW: this make me want even more the features of having constructors doing the Right Thing
- I haven't written up the request to do something like that<br/>
VV: so it would be an aggregate reflecting the properties of the constituting types<br/>
JW: I should write that up<br/>
MC: any objection to move to ready? in favor: 16, opposed: 0, abstain: 1 
</p>


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

<ol>
<li><p>Change 20.3.2 [pairs.pair] around p3 as indicated:</p>

<blockquote><pre>
constexpr pair();
</pre>
<blockquote>
<p>
<del>-3- <i>Requires</i>: <tt>is_default_constructible&lt;first_type&gt;::value</tt> is true and 
<tt>is_default_constructible&lt;second_type&gt;::value</tt> is true.</del>
<p/>
-4- <i>Effects</i>: Value-initializes first and second.
<p/>
<ins>-?- <i>Remarks</i>: This constructor shall not participate in overload resolution unless 
<tt>is_default_constructible&lt;first_type&gt;::value</tt> is true and 
<tt>is_default_constructible&lt;second_type&gt;::value</tt> is true. [<i>Note</i>: This behaviour can be implemented
by a constructor template with default template arguments &mdash; <i>end note</i>].</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.4.2.1 [tuple.cnstr] around p4 as indicated:</p>

<blockquote><pre>
constexpr tuple();
</pre>
<blockquote>
<p>
<del>-4- <i>Requires</i>: <tt>is_default_constructible&lt;<i>T<sub>i</sub></i>&gt;::value</tt> is true for all <i>i</i>.</del>
<p/>
-5- <i>Effects</i>: Value initializes each element.
<p/>
<ins>-?- <i>Remarks</i>: This constructor shall not participate in overload resolution unless 
<tt>is_default_constructible&lt;<i>T<sub>i</sub></i>&gt;::value</tt> is true for all <i>i</i>. [<i>Note</i>: This behaviour can 
be implemented by a constructor template with default template arguments &mdash; <i>end note</i>].</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2380" href="#2380">2380.</a> May <tt>&lt;cstdlib&gt;</tt> provide <tt>long ::abs(long)</tt> and <tt>long long ::abs(long long)</tt>?</h3>
<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-03-31 <b>Last modified:</b> 2015-05-05</p>
<p><b>View all other</b> <a href="lwg-index.html#headers">issues</a> in [headers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
D.5 [depr.c.headers] p3 says:
</p>
<blockquote><p>
[<i>Example</i>: The header <tt>&lt;cstdlib&gt;</tt> assuredly provides its declarations and definitions within the namespace
<tt>std</tt>. It may also provide these names within the global namespace. The header <tt>&lt;stdlib.h&gt;</tt> assuredly
provides the same declarations and definitions within the global namespace, much as in the C Standard. It
may also provide these names within the namespace <tt>std</tt>. &mdash; <i>end example</i>]
</p></blockquote>
<p>
This suggests that <tt>&lt;cstdlib&gt;</tt> may provide <tt>::abs(long)</tt> and <tt>::abs(long long)</tt>. But this seems like 
it might contradict the normative wording of 17.6.1.2 [headers] p4:
</p>
<blockquote><p>
Except as noted in Clauses 18 through 30 and Annex D, the contents of each header <tt>c<em>name</em></tt> shall be the same
as that of the corresponding header <tt><em>name</em>.h</tt>, as specified in the C standard library (1.2) or the C Unicode
TR, as appropriate, as if by inclusion. In the C++ standard library, however, the declarations (except for
names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace <tt>std</tt>. It is
unspecified whether these names are first declared within the global namespace scope and are then injected
into namespace <tt>std</tt> by explicit using-declarations (7.3.3).
</p></blockquote>
<p>
Note that this allows <tt>&lt;cstdlib&gt;</tt> to provide <tt>::abs(int)</tt>, but does not obviously allow <tt>::abs(long)</tt> 
nor <tt>::abs(long long)</tt>, since they are not part of the header <tt>stdlib.h</tt> as specified in the C standard library.
<p/>
26.8 [c.math] p7 adds signatures <tt>std::abs(long)</tt> and <tt>std::abs(long long)</tt>, but not in a way that seems 
to allow <tt>::abs(long)</tt> and <tt>::abs(long long)</tt> to be provided.
<p/>
I think the right approach here would be to allow <tt>&lt;cstdlib&gt;</tt> to either provide no <tt>::abs</tt> declaration, or 
to provide all three declarations from namespace <tt>std</tt>, but it should not be permitted to provide only <tt>int abs(int)</tt>. 
Suggestion:
<p/>
Change in 17.6.1.2 [headers] p4:
</p>
<blockquote><p>
[&hellip;]. It is unspecified whether these names <ins>(including any overloads added in Clauses 18 through 30 and Annex D)</ins> 
are first declared within the global namespace scope and are then injected into namespace <tt>std</tt> by explicit using-declarations 
(7.3.3).
</p></blockquote>

<p><i>[2015-05, Lenexa]</i></p>

<p>
MC: do we need to defer this?<br/>
PJP: just need to get my mind around it, already playing dirty games here, my reaction is just do it as it will help C++<br/>
STL: this is safe<br/>
TP: would be surprising if using abs didn't bring in all of the overloads<br/>
MC: that's Richard's argument<br/>
MC: move to ready 
</p>



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

<ol>
<li><p>Modify 17.6.1.2 [headers] p4 as indicated:</p>

<blockquote><p>
Except as noted in Clauses 18 through 30 and Annex D, the contents of each header <tt>c<em>name</em></tt> shall be the same
as that of the corresponding header <tt><em>name</em>.h</tt>, as specified in the C standard library (1.2) or the C Unicode
TR, as appropriate, as if by inclusion. In the C++ standard library, however, the declarations (except for
names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace <tt>std</tt>. It is
unspecified whether these names <ins>(including any overloads added in Clauses 18 through 30 and Annex D)</ins> are first 
declared within the global namespace scope and are then injected into namespace <tt>std</tt> by explicit using-declarations (7.3.3).
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2384" href="#2384">2384.</a> Allocator's <tt>deallocate</tt> function needs better specification</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2014-05-19 <b>Last modified:</b> 2015-05-08</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to Table 28, 17.6.3.5 [allocator.requirements], an <tt>Allocator</tt>'s <tt>deallocate</tt>
function is specified as follows:
</p>
<blockquote><p>
All <tt>n</tt> <tt>T</tt> objects in the area
pointed to by <tt>p</tt> shall be
destroyed prior to this call. <tt>n</tt>
shall match the value passed to
allocate to obtain this
memory. Does not throw
exceptions. [<i>Note</i>: <tt>p</tt> shall not be
singular. &mdash; <i>end note</i>]
</p></blockquote>
<p>
This wording is confusing in regard to the following points:
</p>
<ol>
<li><p>This specification does not make clear that the result of an <tt>allocate</tt>
call can only be returned once to the <tt>deallocate</tt> function. This is much
clearer expressed for <tt>operator delete</tt> (18.6.1.1 [new.delete.single] p12, emphasis mine):</p>
<blockquote><p>
<i>Requires</i>: <tt>ptr</tt> shall be a null pointer or <span style="color:#C80000;font-weight:bold">its value shall be a value returned 
by an earlier call to</span> the (possibly replaced) <span style="color:#C80000;font-weight:bold"><tt>operator new(std::size_t)</tt> or 
<tt>operator new(std::size_t,const std::nothrow_t&amp;)</tt> which has not been invalidated 
by an intervening call to <tt>operator delete(void*)</tt></span>.
</p></blockquote>
</li>
<li><p>The intended meaning of that wording was to say that <tt>deallocate</tt> shall accept <em>every</em> result value
that had been returned by a corresponding call to <tt>allocate</tt>, this includes also a possible result of a
null pointer value, which is possible ("[<i>Note</i>: If <tt>n == 0</tt>, the return value is unspecified.
&mdash; <i>end note</i>]"). Unfortunately the <tt>deallocate</tt> function uses a non-normative note ("<tt>p</tt> shall not be
singular.") which refers to the fuzzy term <tt>singular</tt>, that is one of the most unclear and misunderstood terms
of the library, as pointed out in <a href="lwg-active.html#1213">1213</a>. The occurrence of this term has lead to the possible understanding,
that this function would never allow null pointer values. Albeit for allocators the intention had not been to require the support
<em>in general</em> that a null pointer value can be provided to <tt>deallocate</tt> (as it is allowed for <tt>std::free</tt>
and <tt>operator delete</tt>), the mental model was that <em>every</em> returned value of <tt>allocate</tt> shall be an
acceptable argument type of the corresponding <tt>deallocate</tt> function.
</p>
</li>
</ol>

<p>
This issue is not intending to enforce a specific meaning of <em>singular</em> iterator values, but the assertion is
that this note does more harm than good. In addition to wording from <tt>operator delete</tt> there is no longer any need
to obfuscate the normative wording. 
</p>

<p><i>[2014-05-24 Alisdair comments]</i></p>


<p>
Now that I am reading it very precisely, there is another mis-stated assumption
as a precondition for <tt>deallocate</tt>:
</p>
<blockquote><p>
All <tt>n T</tt> objects in the area pointed to by <tt>p</tt> shall be destroyed prior to this call.
</p></blockquote>
<p>
This makes a poor assumption that every possible object in the allocated buffer
was indeed constructed, but this is often not the case, e.g., a <tt>vector</tt> that is not
filled to capacity. We should require calling the destructor for only those objects
actually constructed in the buffer, which may be fewer than <tt>n</tt>, or even 0.
<p/>
I wonder if we really require all objects to be destroyed before calling <tt>deallocate</tt>
though. Are we really so concerned about leaking objects that might not manage
resources? Should this not be the proper concern of the library managing the
objects and memory?
</p>

<p><i>[2014-06-05 Daniel responds and improves wording]</i></p>


<p>
I fully agree with the last comment and I think that this requirement should be removed. We have no such
requirements for comparable functions such as <tt>operator delete</tt> or <tt>return_temporary_buffer()</tt>,
and this wording seems to be a wording rudiment that exists since C++98.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Marshall: What do people think about this?<br/>
PJP: Sure.<br/>
Wakely: Love it.<br/>
Marshall: Ready?<br/>
Everyone agrees.<br/>
</p>


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

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

<ol>
<li><p>Change Table 28 ("<tt>Allocator</tt> requirements") as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 28 &mdash; <tt>Allocator</tt> requirements</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Assertion/note<br/>pre-/post-condition</th>
<th align="center">Default</th>
</tr>

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

<tr>
<td>
<tt>a.deallocate(p,n)</tt>
</td>
<td>
(not used)
</td>
<td>
<ins><i>Pre</i>: <tt>p</tt> shall be a value returned by an earlier<br/> 
call to <tt>allocate</tt> which has not been invalidated by<br/> 
an intervening call to <tt>deallocate</tt>. <tt>n</tt> shall<br/> 
match the value passed to <tt>allocate</tt> to obtain this<br/> 
memory.</ins> <del>All <tt>n T</tt> objects in the area pointed to by<br/> 
<tt>p</tt> shall be destroyed prior to this call.</del><br/>
<ins><i>Throws</i>: Nothing.</ins><del><tt>n</tt><br/>
shall match the value passed to<br/>
allocate to obtain this<br/>
memory. Does not throw<br/>
exceptions. [<i>Note</i>: <tt>p</tt> shall not<br/>
be singular. &mdash; <i>end note</i>]</del>
</td>
<td>
&nbsp;
</td>
</tr>

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

</table>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2385" href="#2385">2385.</a> <tt>function::assign</tt> allocator argument doesn't make sense</h3>
<p><b>Section:</b> 20.9.12.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2014-05-23 <b>Last modified:</b> 2015-05-07</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The definition of <tt>function::assign</tt> in N3936 is:
</p>
<blockquote><pre>
template&lt;class F, class A&gt;
  void assign(F&amp;&amp; f, const A&amp; a);
</pre>
<blockquote>
<p>
<i>Effects</i>: <tt>function(allocator_arg, a, std::forward&lt;F&gt;(f)).swap(*this)</tt>
</p>
</blockquote>
</blockquote>
<p>
This definition is flawed in several respects:
</p>
<ol>
<li><p>The interface implies that the intent is to replace the allocator in <tt>*this</tt>
with the specified allocator, <tt>a</tt>.  Such functionality is unique in the
standard and is problematic when creating, e.g. a container of function
objects, all using the same allocator.</p>
</li>
<li><p>The current definition of <tt>swap()</tt> makes it unclear whether the objects being
swapped can have different allocators.  The general practice is that
allocators must be equal in order to support swap, and this practice is
reinforced by the proposed library TS. Thus, the definition of <tt>assign</tt> would
have undefined behavior unless the allocator matched the allocator already
within function.
</p>
</li>
<li><p>
The general rule for members of function is to supply the allocator before
the functor, using the <tt>allocator_arg</tt> prefix. Supplying the allocator as a
second argument, without the <tt>allocator_arg</tt> prefix is error prone and
confusing.
</p></li>
</ol>

<p>
I believe that this ill-conceived interface was introduced in the effort to
add allocators to parts of the standard where it had been missing, when we
were unpracticed in the right way to accomplish that. Allocators were added
to function at a time when the allocator model was in flux and it was the
first class in the standard after <tt>shared_ptr</tt> to use type-erased allocators, so
it is not surprising to see some errors in specification here. (<tt>shared_ptr</tt> is
a special case because of its shared semantics, and so is not a good model.)
<p/>
The main question is whether this member should be specified with better
precision or whether it should be deprecated/removed. The only way I can see to
give a "reasonable" meaning to the existing interface is to describe it in
terms of destroying and re-constructing <tt>*this</tt>:
</p>
<blockquote><pre>
function temp(allocator_arg, a, std::forward&lt;F&gt;(f));
this-&gt;~function();
::new(this) function(std::move(temp));
</pre></blockquote>
<p>
(The temp variable is needed for exception safety). The ugliness of this
specification underscores the ugliness of the concept. What is the purpose of
this member other than to reconstruct the object from scratch, a facility that
library classes do not generally provide? Programmers are always free to
destroy and re-construct objects &mdash; there is no reason why function should
make that especially easy.
<p/>
I propose, therefore, that we make no attempt at giving the current interface
a meaningful definition of questionable utility, but simply get rid of it
all together. This leaves us with only two questions:
</p>
<ol>
<li><p>Should we deprecate the interface or just remove it?</p></li>
<li><p>Should we replace it with an <tt>assign(f)</tt> member that doesn't take an
allocator?</p></li>
</ol>
<p>
Of these four combinations of binary answers to the above questions, I think
the ones that make the most sense are (remove, no) and (deprecate, yes). The
proposed new interface provides nothing that <tt>operator=</tt> does not already
provide. However, if the old (deprecated) interface remains, then having the
new interface will guide the programmer away from it.
<p/>
The proposed wording below assumes deprecation. If we choose removal, then
there is no wording needed; simply remove the offending declaration and
definition.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change class template <tt>function</tt> synopsis, 20.9.12.2 [func.wrap.func], as indicated:</p>

<blockquote>
<pre>
template&lt;class R, class... ArgTypes&gt;
class function&lt;R(ArgTypes...)&gt; {
  [&hellip;]
  <i>// 20.9.11.2.2, function modifiers:</i>
  void swap(function&amp;) noexcept;
  template&lt;class F<del>, class A</del>&gt; void assign(F&amp;&amp;<del>, const A&amp;</del>);
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Change 20.9.12.2.2 [func.wrap.func.mod] as indicated:</p>

<blockquote>
<pre>
template&lt;class F<del>, class A</del>&gt; void assign(F&amp;&amp; f<del>, const A&amp; a</del>);
</pre>
<blockquote>
<p>
<i>Effects</i>: <tt><ins>*this = forward&lt;F&gt;(f);</ins><del>function(allocator_arg, a, std::forward&lt;F&gt;(f)).swap(*this)</del></tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>To deprecation section  [depr.function.objects], add the following new sub-clause:</p>

<blockquote>
<p>
<b>Old <tt>assign</tt> member of polymorphic function wrappers [depr.function.objects.assign]</b>
</p>
<blockquote>
<pre>
namespace std{
  template&lt;class R, class... ArgTypes&gt;
  class function&lt;R(ArgTypes...)&gt; {
    <i>// remainder unchanged</i>
    template&lt;class F, class A&gt; void assign(F&amp;&amp; f, const A&amp; a);
    [&hellip;]
  };
}
</pre>
</blockquote>
<p>
The two-argument form of <tt>assign</tt> is defined as follows:
</p>
<pre>
template&lt;class F, class A&gt; void assign(F&amp;&amp; f, const A&amp; a);
</pre>
<blockquote>
<p>
<i>Requires</i>: <tt>a</tt> shall be equivalent to the allocator used to construct <tt>*this</tt>.
<p/>
<i>Effects</i>: <tt>this-&gt;assign(forward&lt;F&gt;(f));</tt>
</p>
</blockquote>

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

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL: I would ask, does anybody oppose removing this outright?<br/>
Wakely: I don't even have this signature.<br/>
Hwrd: And I think this doesn't go far enough, even more should be removed. This is a step in the right direction.<br/>
PJP: I'm in favor of removal.<br/>
Wakely: We've already got TS1 that has a new function that does it right. We could wait for feedback on that. 
I think this issue should be taken now.<br/>
Marshall: Then the goal will be to move to ready. 
</p>


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

<ol>
<li><p>Change class template <tt>function</tt> synopsis, 20.9.12.2 [func.wrap.func], as indicated:</p>

<blockquote>
<pre>
template&lt;class R, class... ArgTypes&gt;
class function&lt;R(ArgTypes...)&gt; {
  [&hellip;]
  <i>// 20.9.12.2.2, function modifiers:</i>
  void swap(function&amp;) noexcept;
  <del>template&lt;class F, class A&gt; void assign(F&amp;&amp;, const A&amp;);</del>
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Change 20.9.12.2.2 [func.wrap.func.mod] as indicated:</p>

<blockquote>
<pre>
<del>template&lt;class F, class A&gt; 
  void assign(F&amp;&amp; f, const A&amp; a);</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Effects</i>: <tt>function(allocator_arg, a, std::forward&lt;F&gt;(f)).swap(*this)</tt></del>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2435" href="#2435">2435.</a> <tt>reference_wrapper::operator()</tt>'s Remark should be deleted</h3>
<p><b>Section:</b> 20.9.4.4 [refwrap.invoke] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-10-01 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.9.4.4 [refwrap.invoke]/2 is no longer useful. (It was originally TR1 2.1.2.4 [tr.util.refwrp.invoke]/2.)  
First, we already have the As If Rule (1.9 [intro.execution]/1) and the STL Implementers Can Be Sneaky Rule 
(17.6.5.5 [member.functions]). Second, with variadic templates and other C++11/14 tech, this can be implemented 
exactly as depicted.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
DK: I don't see a defect here<br/>
STL: the issue is that the standard is overly verbose, we don't need this sentence. It's redundant.<br/>
MC: does anyone think this paragraph has value?<br/>
JW: it has negative value. reading it makes me wonder if there's some reason I would want to provide a set of overloaded 
functions, maybe there's some problem with doing it the obvious way that I'm not clever enough to see.<br/>
Move to Ready status: 8 in favor, none against. 
</p>


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

<ol>
<li><p>Change 20.9.4.4 [refwrap.invoke] p2 as depicted:</p>

<blockquote>
<pre>
template &lt;class... ArgTypes&gt;
  result_of_t&lt;T&amp;(ArgTypes&amp;&amp;...)>
    operator()(ArgTypes&amp;&amp;... args) const;
</pre>
<blockquote>
<p>
-1- <i>Returns</i>: <tt>INVOKE(get(), std::forward&lt;ArgTypes&gt;(args)...)</tt>. (20.9.2)
<p/>
<del>-2- <i>Remark</i>: <tt>operator()</tt> is described for exposition only. Implementations are not required to provide an
actual <tt>reference_wrapper::operator()</tt>. Implementations are permitted to support <tt>reference_wrapper</tt> function 
invocation through multiple overloaded operators or through other means.</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2447" href="#2447">2447.</a> Allocators and <tt>volatile</tt>-qualified value types</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2014-10-16 <b>Last modified:</b> 2015-09-25</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to Table 27 &mdash; "Descriptive variable definitions" which is used to define the symbols used in the
allocator requirements table within 17.6.3.5 [allocator.requirements] we have the following constraints for
the types <tt>T, U, C</tt>:
</p>
<blockquote><p>
any non-const object type (3.9)
</p></blockquote>
<p>
This wording can be read to allow instead a <tt>volatile</tt>-qualified value type such as <tt>volatile int</tt>.
<p/>
The nearest-by way of fixing this would be to add "non-<tt>volatile</tt>" as additional constraint to this table
row.
<p/>
Another choice would be to think of requiring that allocators must be capable to handle any <tt><i>cv</i></tt>-qualified
value types. This would make all currently existing allocators non-conforming that can't handle <tt><i>cv</i></tt>-qualified 
value types, so I'm not suggesting to follow that route.
<p/>
A less radical step would be to allow <tt><i>cv</i></tt>-qualified types just for <tt>C</tt> (which is used to specify the
functions <tt>construct</tt> and <tt>destroy</tt> and where does not even exist any requirement that <tt>C</tt> actually 
is related to the value type of the allocator at all). This seemingly extension would be harmless because as of p8 of the
same sub-clause "An allocator may constrain the types on which it can be instantiated and the arguments for which its
<tt>construct</tt> member may be called."
<p/>
This differs from the requirements imposed on the types <tt>T</tt> and <tt>U</tt> which both refer to value types of allocators.
<p/>
The proposed wording attempts to separate the two classes of requirements.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>
This wording is relative to N4140.
</p>

<ol>
<li><p>Change 17.6.3.5 [allocator.requirements], Table 27 &mdash; "Descriptive variable definitions", as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 27 &mdash; Descriptive variable definitions</caption>
<tr>
<th>Variable</th>
<th>Definition</th>
</tr>

<tr>
<td>
<tt>T, U<del>, C</del></tt>
</td>
<td>
any non-<del>const</del><ins><tt>const</tt> and non-<tt>volatile</tt></ins> object type (3.9)
</td>
</tr>

<tr>
<td>
<ins><tt>C</tt></ins>
</td>
<td>
<ins>any object type</ins>
</td>
</tr>

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

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

<li><p>Change 17.6.3.5 [allocator.requirements] p8 as indicated: (This wording change is intended to
fix an obvious asymmetry between <tt>construct</tt> and <tt>destroy</tt> which I believe is not intended)</p>

<blockquote><p>
-8- An allocator may constrain the types on which it can be instantiated and the arguments for which its
<tt>construct</tt> <ins>or <tt>destroy</tt></ins> member<ins>s</ins> may be called. If a type cannot be 
used with a particular allocator, the allocator class or the call to <tt>construct</tt> <ins>or <tt>destroy</tt></ins> 
may fail to instantiate.
</p></blockquote>
</li>
</ol>

</blockquote>

<p><i>[2014-11, Urbana]</i></p>

<p>
JW: say "cv-unqualified" instead?<br/>
JW: very nervous about allowing construct on const-types, because of the cast to (non-const) <tt>void*</tt><br/>
MA: should we just make the minimal fix?<br/>
STL: don't break <tt>C</tt> out for special treatment<br/>
New proposed resolution: just change "non-const" to "cv-unqualified". Keep addition of <tt>destroy</tt> later. 
</p>

<p><i>[2015-02 Cologne]</i></p>

<p>
GR: It makes me nervous that someone at some point decided to not add "non-<tt>volatile</tt>".<br/> 
AM: That was over ten years ago. It was a deliberate, minuted choice to support <tt>volatile</tt>. We are now reversing that decision. 
It would be good to poll our vendors, none of which are in the room. This is a bit more work than we expect of a P0 issue.<br/> 
VV: libstdc++ and libc++ seem to support <tt>volatile</tt> template parameters for the standard allocator.<br/> 
AM: To clarify, the proposed resolution here would remove the requirement to support <tt>volatile</tt>. Implementations could still 
choose to support <tt>volatile</tt>.<br/>
DK: I'm happy to drop this and open a new issue in regard to the <tt>destroy</tt> member specification.<br/>
AM: I just think this is harder than a P0. Let's reprioritize.
</p>

<p><i>[2015-04-01 Daniel comments]</i></p>

<p>
The less controversial part of the issue related to constraints imposed on <tt>destroy</tt> has be handed over to the new 
issue <a href="lwg-defects.html#2470">2470</a>.
</p>

<p><i>[2015-05-06 Lenexa: Move to Ready]</i></p>



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

<ol>
<li><p>Change 17.6.3.5 [allocator.requirements], Table 27 &mdash; "Descriptive variable definitions", as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 27 &mdash; Descriptive variable definitions</caption>
<tr>
<th>Variable</th>
<th>Definition</th>
</tr>

<tr>
<td>
<tt>T, U, C</tt>
</td>
<td>
any <del>non-const</del><ins><i>cv</i>-unqualified</ins> object type (3.9)
</td>
</tr>

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

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





<hr>
<h3><a name="2462" href="#2462">2462.</a> <tt>std::ios_base::failure</tt> is overspecified</h3>
<p><b>Section:</b> 27.5.3 [ios.base], 27.5.3.1.1 [ios::failure] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-12-15 <b>Last modified:</b> 2015-05-22</p>
<p><b>View all other</b> <a href="lwg-index.html#ios.base">issues</a> in [ios.base].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
27.5.3 [ios.base] defines <tt>ios_base::failure</tt> as a nested class:
</p>
<blockquote>
<pre>
namespace std {
  class ios_base {
  public:
    class failure;
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
<p>
This means it is valid to use an elaborated-type-specifier to
refer to <tt>ios_base::failure</tt>:
</p>
<blockquote>
<pre>
using F = class std::ios_base::failure;
throw F();
</pre>
</blockquote>
<p>
Therefore implementations are not permitted to define
<tt>ios_base::failure</tt> as a typedef e.g.
</p>
<blockquote>
<pre>
 class ios_base {
 public:
#if __cplusplus &lt; 201103L
   class failure_cxx03 : public exception {...};
   typedef failure_cxx03 failure;
#else
   class failure_cxx11 : public system_error {...};
   typedef failure_cxx11 failure;
#endif
   [&hellip;]
 };
</pre>
</blockquote>
<p>
This constrains implementations, making it harder to manage the ABI
change to <tt>ios_base::failure</tt> between C++03 and C++11.
</p>

<p><i>[2015-05-06 Lenexa: Move to Ready]</i></p>

<p>JW: the issue is that users are currently allowed to write "class failure" with an elaborated-type-specifier and it must be well-formed, I want the freedom to make that type a typedef, so they can't necessarily use an elaborated-type-specifier (which there is no good reason to use anyway)</p>
<p>JW: ideally I'd like this everywhere for all nested classes, but that's a paper not an issue, I only need this type fixed right now.</p>
<p>RD: is a synonym the same as an alias?</p>
<p>JW: dcl.typedef says a typedef introduces a synonym for another type, so I think this is the right way to say this</p>
<p>JW: I already shipped this last month</p>
<p>PJP: we're going to have to break ABIs again some time, we need all the wiggle room we can get to make that easier. This helps.</p>
<p>MC: do we want this at all? Ready?</p>
<p>9 in favor, none opose or abstaining</p>


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

<ol>
<li><p>Change the synopsis in 27.5.3 [ios.base] as indicated:</p>

<blockquote>
<pre>
namespace std {
  class ios_base {
  public:
    class failure; <ins><i>// see below</i></ins>
    [&hellip;]
  };
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Change 27.5.3 [ios.base] paragraph 1:</p>

<blockquote>
<p>
<tt>ios_base</tt> defines several member types:
</p>
<ul>
<li><p>a <del>class <tt>failure</tt></del><ins>type <tt>failure</tt>, defined as either
a class derived from <tt>system_error</tt> or a synonym for a class</ins> derived from 
<tt>system_error</tt>;</p></li>
</ul>
</blockquote>
</li>

<li><p>Change 27.5.3.1.1 [ios::failure] paragraph 1:</p>
<blockquote>
<p>
-1- <ins>An implementation is permitted to define <tt>ios_base::failure</tt> as
a synonym for a class with equivalent functionality to class <tt>ios_base::failure</tt> shown 
in this subclause. [<i>Note</i>: When <tt>ios_base::failure</tt> is a synonym for another type 
it shall provide a nested type <tt>failure</tt>, to emulate the injected class name. &mdash; 
<i>end note</i>]</ins> The class <tt>failure</tt> defines the base class for the types of all 
objects thrown as exceptions, by functions in the iostreams library, to report errors detected 
during stream buffer operations.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2466" href="#2466">2466.</a> <tt>allocator_traits::max_size()</tt> default behavior is incorrect</h3>
<p><b>Section:</b> 17.6.3.5 [allocator.requirements], 20.7.8.2 [allocator.traits.members] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2015-01-17 <b>Last modified:</b> 2015-05-08</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 28 &mdash; "Allocator requirements" says that default behavior for <tt>a.max_size()</tt> is 
<tt>numeric_limits&lt;size_type&gt;::max()</tt>. And this is consistent with the matching statement 
for <tt>allocator_traits</tt> in 20.7.8.2 [allocator.traits.members]/p7:
</p>
<blockquote>
<pre>
static size_type max_size(const Alloc&amp; a) noexcept;
</pre>
<blockquote>
<p>
<i>Returns</i>: <tt>a.max_size()</tt> if that expression is well-formed; otherwise, 
<tt>numeric_limits&lt;size_type&gt;::max()</tt>.
</p>
</blockquote>
</blockquote>
<p>
However, when allocating memory, an allocator must allocate <tt>n*sizeof(value_type)</tt> bytes, for example:
</p>
<blockquote>
<pre>
value_type*
allocate(std::size_t n)
{
  return static_cast&lt;value_type*&gt;(::operator new (n * sizeof(value_type)));
}
</pre>
</blockquote>
<p>
When <tt>n == numeric_limits&lt;size_type&gt;::max(), n * sizeof(value_type)</tt> is <em>guaranteed</em> 
to overflow except when <tt>sizeof(value_type) == 1</tt>.
<p/>
A more useful default would be <tt>numeric_limits&lt;size_type&gt;::max() / sizeof(value_type)</tt>.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Marshall: Is this the right solution?<br/>
PJP: I think it's gilding the lily.<br/>
STL: I think this is right, and it doesn't interact with the incomplete container stuff because it's in a member function.<br/>
Marshall: Objections to this?<br/>
STL: Spaces around binary operators.<br/>
Hwrd: It's completely wrong without spaces.<br/>
Marshall: All in favor of Ready?<br/>
Lots. 
</p>


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

<ol>
<li><p>Change 17.6.3.5 [allocator.requirements], Table 28 &mdash; "Allocator requirements", as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 28 &mdash; Allocator requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
<th>Default</th>
</tr>

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

<tr>
<td>
<tt>a.max_size()</tt>
</td>
<td>
<tt>X::size_type</tt>
</td>
<td>
the largest value that can<br/>
meaningfully be passed to<br/>
<tt>X::allocate()</tt>
</td>
<td>
<tt>numeric_limits&lt;size_type&gt;::max()<ins>/sizeof(value_type)</ins></tt>
</td>
</tr>

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

</table>
</blockquote>

</li>

<li><p>Change 20.7.8.2 [allocator.traits.members]/p7 as indicated:</p>

<blockquote>
<pre>
static size_type max_size(const Alloc&amp; a) noexcept;
</pre>
<blockquote>
<p>
<i>Returns</i>: <tt>a.max_size()</tt> if that expression is well-formed; otherwise, 
<tt>numeric_limits&lt;size_type&gt;::max()<ins>/sizeof(value_type)</ins></tt>.
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2469" href="#2469">2469.</a> Wrong specification of Requires clause of <tt>operator[]</tt> for <tt>map</tt> and <tt>unordered_map</tt></h3>
<p><b>Section:</b> 23.4.4.3 [map.access], 23.5.4.3 [unord.map.elem] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2015-01-21 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all other</b> <a href="lwg-index.html#map.access">issues</a> in [map.access].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The "Requires:" clause for the <tt>operator[]</tt> for the <tt>unordered_map</tt> and <tt>map</tt>, are defining 
separate requirements for insertability into container of <tt>mapped_type</tt> and <tt>key_type</tt>.
<p/>
23.4.4.3 [map.access] p2: // <tt>T&amp; operator[](const key_type&amp; x);</tt>
<p/>
<i>Requires</i>: <tt>key_type</tt> shall be <tt>CopyInsertable</tt> and <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> 
into <tt>*this</tt>.
<p/>
23.4.4.3 [map.access] p6: // <tt>T&amp; operator[](key_type&amp;&amp; x)</tt>
<p/>
<i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>.
<p/>
23.5.4.3 [unord.map.elem] p1: // <tt>mapped_type&amp; operator[](const key_type&amp; k); 
mapped_type&amp; operator[](key_type&amp;&amp; k);</tt>
<p/>
<i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>. For the first operator, 
<tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>. For the second operator, <tt>key_type</tt> shall 
be <tt>MoveConstructible</tt>.
<p/>
Definition of the appropriate requirements: 23.2.1 [container.requirements.general] p15.
<p/>
<tt>T</tt> is <tt>DefaultInsertable</tt> into <tt>X</tt> means that the following expression is well-formed: //p15.1
<p/>
<tt>allocator_traits&lt;A&gt;::construct(m, p)</tt>
<p/>
<tt>T</tt> is <tt>MoveInsertable</tt> into <tt>X</tt> means that the following expression is well-formed:   //p15.3
<p/>
<tt>allocator_traits&lt;A&gt;::construct(m, p, rv)</tt>
<p/>
<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 following expression is well-formed: //p15.4
<p/>
<tt>allocator_traits&lt;A&gt;::construct(m, p, v)</tt>
<p/>
In the context of above definition the requirement "<tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>" 
would mean that the key element of the <tt>pair&lt;const key_type, mapped_type&gt;</tt> (<tt>value_type</tt> of the map) 
should be constructed using separate call to the <tt>construct</tt> method, the same applies for the <tt>mapped_type</tt>. 
Such behavior is explicitly prohibited by 23.2.1 [container.requirements.general] p3.
</p>
<blockquote><p>
For the components affected by this sub-clause that declare an allocator_type, objects stored in these 
components shall be constructed using the <tt>allocator_traits&lt;allocator_type&gt;::construct</tt> function and
destroyed using the <tt>allocator_traits&lt;allocator_type&gt;::destroy</tt> function (20.7.8.2). These functions
are called only for the container's element type, not for internal types used by the container.
</p></blockquote>
<p>
It clearly states that <tt>element_type</tt> of the map, must be constructed using allocator for value type, which 
disallows using of separate construction of first and second element, regardless of the fact if it can be actually 
performed without causing undefined behavior.
<p/>
That means that the <tt>MoveInsertable</tt> and similar requirements may only be expressed in terms of <tt>value_type</tt>, 
not its members types.
</p>

<p><i>[2015-02 Cologne]</i></p>

<p>
This issue is related to <a href="lwg-defects.html#2464">2464</a>.
<p/>
GR: Effects should say "returns ...". DK: Or just have a Returns clause? MC: A Returns clause is a directive to implementers.
<p/>
TK/DK: This PR fails to address the requirements about which it complained in the first place. DK: I can reword this. TK can help. 
</p> 

<p><i>[2015-03-29, Daniel provides improved wording]</i></p>

<p>
The revised wording fixes the proper usage of the magic "Equivalent to" wording, which automatically induces <i>Requires:</i>, 
<i>Returns:</i>, and <i>Complexity:</i> elements (and possibly more). This allows us to strike all the remaining
elements, because they fall out from the semantics of the wording defined by <a href="lwg-defects.html#2464">2464</a>. In particular it is important
to realize that the wording form
</p>
<blockquote>
<p>
<tt>value_type</tt> shall be <tt>EmplaceConstructible</tt> into <tt>map</tt> from <tt>piecewise_construct</tt>, 
<tt>forward_as_tuple(k)</tt>, <tt>forward_as_tuple(forward&lt;Args&gt;(args)...)</tt>
</p>
</blockquote>
<p>
degenerates for the empty pack expansion <tt>args</tt> to:
</p>
<blockquote>
<p>
<tt>value_type</tt> shall be <tt>EmplaceConstructible</tt> into <tt>map</tt> from <tt>piecewise_construct</tt>, 
<tt>forward_as_tuple(k)</tt>, <tt>forward_as_tuple()</tt>
</p>
</blockquote>
<p>
which again means that such a <tt>pair</tt> construction (assuming <tt>std::allocator</tt>) would copy <tt>k</tt>
into member <tt>first</tt> and would value-initialize member <tt>second</tt>.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N4296.</p>

<p>Accept resolution of the issue issue <a href="lwg-defects.html#2464">2464</a> and define <tt>operator[]</tt> as follows 
(This would also address issue <a href="lwg-defects.html#2274">2274</a>):</p>

<ol>
<li><p>Change 23.4.4.3 [map.access] as indicated:</p>

<blockquote>
<pre>
T&amp; operator[](const key_type&amp; x);
</pre>
<blockquote><p>
-1- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(x, T())</tt> 
into the map</del><ins>Equivalent to: <tt>try_emplace(x).first-&gt;second</tt></ins>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
T&amp; operator[](key_type&amp;&amp; x);
</pre>
<blockquote>
<p>
-5- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(std::move(x), T())</tt> 
into the map</del><ins>Equivalent to: <tt>try_emplace(move(x)).first-&gt;second</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.5.4.3 [unord.map.elem] as indicated:</p>

<blockquote>
<pre>
mapped_type&amp; operator[](const key_type&amp; k);
mapped_type&amp; operator[](key_type&amp;&amp; k);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-2- <i>Effects</i>: <del>If the <tt>unordered_map</tt> does not already contain an element whose key is equivalent to <tt>k</tt>, 
the first operator inserts the value <tt>value_type(k, mapped_type())</tt> and the second operator inserts the
value <tt>value_type(std::move(k), mapped_type())</tt></del><ins>For the first operator, equivalent to: 
<tt>try_emplace(k).first-&gt;second</tt>; for the second operator, equivalent to: 
<tt>try_emplace(move(k)).first-&gt;second</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N4296.</p>

<p>Accept resolution of the issue issue <a href="lwg-defects.html#2464">2464</a> and define <tt>operator[]</tt> as follows 
(This would also address issue <a href="lwg-defects.html#2274">2274</a>):</p>

<ol>
<li><p>Change 23.4.4.3 [map.access] as indicated:</p>

<blockquote>
<pre>
T&amp; operator[](const key_type&amp; x);
</pre>
<blockquote><p>
-1- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(x, T())</tt> 
into the map.</del><ins>Equivalent to: <tt>return try_emplace(x).first-&gt;second;</tt></ins>
<p/>
<del>-2- <i>Requires</i>: <tt>key_type</tt> shall be <tt>CopyInsertable</tt> and <tt>mapped_type</tt> shall be 
<tt>DefaultInsertable</tt> into <tt>*this</tt>.</del>
<p/>
<del>-3- <i>Returns</i>: A reference to the <tt>mapped_type</tt> corresponding to <tt>x</tt> in <tt>*this</tt>.</del>
<p/>
<del>-4- <i>Complexity</i>: Logarithmic.</del>
</p>
</blockquote>
<pre>
T&amp; operator[](key_type&amp;&amp; x);
</pre>
<blockquote>
<p>
-5- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(std::move(x), T())</tt> 
into the map.</del><ins>Equivalent to: <tt>return try_emplace(move(x)).first-&gt;second;</tt></ins>
<p/>
<del>-6- <i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>.</del>
<p/>
<del>-7- <i>Returns</i>: A reference to the <tt>mapped_type</tt> corresponding to <tt>x</tt> in <tt>*this</tt>.</del>
<p/>
<del>-8- <i>Complexity</i>: Logarithmic.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.5.4.3 [unord.map.elem] as indicated:</p>

<blockquote>
<pre>
mapped_type&amp; operator[](const key_type&amp; k);
mapped_type&amp; operator[](key_type&amp;&amp; k);
</pre>
<blockquote>
<p>
<del>-1- <i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>. For the first operator, 
<tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>. For the second operator, <tt>key_type</tt> shall 
be <tt>MoveConstructible</tt>.</del>
<p/>
-2- <i>Effects</i>: <del>If the <tt>unordered_map</tt> does not already contain an element whose key is equivalent to <tt>k</tt>, 
the first operator inserts the value <tt>value_type(k, mapped_type())</tt> and the second operator inserts the
value <tt>value_type(std::move(k), mapped_type())</tt></del><ins>For the first operator, equivalent to:</ins>
</p>
<blockquote>
<pre> 
<ins>return try_emplace(k).first-&gt;second;</ins>
</pre>
</blockquote>
<p>
<ins>for the second operator, equivalent to:</ins>
</p>
<blockquote>
<pre>
<ins>return try_emplace(move(k)).first-&gt;second;</ins>
</pre>
</blockquote>
<p>
<del>-3- <i>Returns</i>: A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element whose key is equivalent to 
<tt>k</tt>.</del>
<p/>
<del>-4- <i>Complexity</i>: Average case &#x1d4aa;(<tt>1</tt>), worst case &#x1d4aa;(<tt>size()</tt>).</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>


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

<p>Accept resolution of the issue issue <a href="lwg-defects.html#2464">2464</a> and define <tt>operator[]</tt> as follows 
(This would also address issue <a href="lwg-defects.html#2274">2274</a>):</p>

<ol>
<li><p>Change 23.4.4.3 [map.access] as indicated:</p>

<blockquote>
<pre>
T&amp; operator[](const key_type&amp; x);
</pre>
<blockquote><p>
-1- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(x, T())</tt> 
into the map.</del><ins>Equivalent to: <tt>return try_emplace(x).first-&gt;second;</tt></ins>
<p/>
<del>-2- <i>Requires</i>: <tt>key_type</tt> shall be <tt>CopyInsertable</tt> and <tt>mapped_type</tt> shall be 
<tt>DefaultInsertable</tt> into <tt>*this</tt>.</del>
<p/>
<del>-3- <i>Returns</i>: A reference to the <tt>mapped_type</tt> corresponding to <tt>x</tt> in <tt>*this</tt>.</del>
<p/>
<del>-4- <i>Complexity</i>: Logarithmic.</del>
</p>
</blockquote>
<pre>
T&amp; operator[](key_type&amp;&amp; x);
</pre>
<blockquote>
<p>
-5- <i>Effects</i>: <del>If there is no key equivalent to <tt>x</tt> in the map, inserts <tt>value_type(std::move(x), T())</tt> 
into the map.</del><ins>Equivalent to: <tt>return try_emplace(move(x)).first-&gt;second;</tt></ins>
<p/>
<del>-6- <i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>.</del>
<p/>
<del>-7- <i>Returns</i>: A reference to the <tt>mapped_type</tt> corresponding to <tt>x</tt> in <tt>*this</tt>.</del>
<p/>
<del>-8- <i>Complexity</i>: Logarithmic.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.5.4.3 [unord.map.elem] as indicated:</p>

<blockquote>
<pre>
mapped_type&amp; operator[](const key_type&amp; k);
<del>mapped_type&amp; operator[](key_type&amp;&amp; k);</del>
</pre>
<blockquote>
<p>
<del>-1- <i>Requires</i>: <tt>mapped_type</tt> shall be <tt>DefaultInsertable</tt> into <tt>*this</tt>. For the first operator, 
<tt>key_type</tt> shall be <tt>CopyInsertable</tt> into <tt>*this</tt>. For the second operator, <tt>key_type</tt> shall 
be <tt>MoveConstructible</tt>.</del>
<p/>
-2- <i>Effects</i>: <ins>Equivalent to <tt>return try_emplace(k).first-&gt;second;</tt></ins><del>If the <tt>unordered_map</tt> 
does not already contain an element whose key is equivalent to <tt>k</tt>, 
the first operator inserts the value <tt>value_type(k, mapped_type())</tt> and the second operator inserts the
value <tt>value_type(std::move(k), mapped_type())</tt></del>
</p>
<p>
<del>-3- <i>Returns</i>: A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element whose key is equivalent to 
<tt>k</tt>.</del>
<p/>
<del>-4- <i>Complexity</i>: Average case &#x1d4aa;(<tt>1</tt>), worst case &#x1d4aa;(<tt>size()</tt>).</del>
</p>
</blockquote>

<pre>
<ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: Equivalent to <tt>return try_emplace(move(k)).first-&gt;second;</tt></ins>
</p>
</blockquote>

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





<hr>
<h3><a name="2473" href="#2473">2473.</a> <tt>basic_filebuf</tt>'s relation to C <tt>FILE</tt> semantics</h3>
<p><b>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Aaron Ballman <b>Opened:</b> 2015-02-09 <b>Last modified:</b> 2015-10-20</p>
<p><b>View all other</b> <a href="lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The restrictions on reading and writing a sequence controlled by an object of class 
<tt>basic_filebuf&lt;charT, traits&gt;</tt> are the same as for reading and writing with 
the Standard C library <tt>FILE</tt>s. One of the restrictions placed by C is on the behavior of 
a stream that is opened for input and output. See the C99 standard, 7.19.5.3p6 for more 
details, but the gist is that when opened in update mode, reads and writes must have an 
intervening file positioning or flushing call to not trigger UB.
</p>

<p>
27.9.1.5 [filebuf.virtuals] p13 specifies that <tt>basic_filebuf::seekoff()</tt> calls 
<tt>std::fseek()</tt>. However, there is no mention of <tt>std::fseek()</tt> in 
<tt>basic_filebuf::seekpos()</tt>, and no mention of <tt>std::fflush()</tt> in
<tt>basic_filebuf::sync()</tt>, which seem like an oversight.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N4296.</p>

<ol>
<li>
<p>Change 27.9.1.5 [filebuf.virtuals] p16 as follows [Editorial note: A footnote referring to <tt>fseek</tt> is not needed,
because this is already covered by the existing footnote 334]:</p>
<blockquote>
<p>
-16- Alters the file position, if possible, to correspond to the position stored in <tt>sp</tt> (as described below).
Altering the file position performs as follows:
</p>
<ol>
<li><p>if <tt>(om &amp; ios_base::out) != 0</tt>, then update the output sequence and write any unshift sequence;</p></li>
<li><p>set the file position to <tt>sp</tt> <ins>as if by calling <tt>std::fseek(file, sp, SEEK_SET)</tt></ins>;</p></li>
<li><p>if <tt>(om &amp; ios_base::in) != 0</tt>, then update the input sequence;</p></li>
</ol>
<p>
where <tt>om</tt> is the open mode passed to the last call to <tt>open()</tt>. The operation fails if 
<tt>is_open()</tt> returns false.
</p>
</blockquote>
</li>

<li>
<p>Change 27.9.1.5 [filebuf.virtuals] p19 as follows and add a new footnote that mimics comparable footnotes in
27.9.1.4 [filebuf.members] and 27.9.1.5 [filebuf.virtuals]:</p>
<blockquote>
<p>
-19- <i>Effects</i>: If a put area exists, calls <tt>filebuf::overflow</tt> to write the characters to the file<ins>, then
flushes the file as if by calling <tt>std::fflush(file)</tt> [Footnote: The function signature <tt>fflush(FILE*)</tt> 
is declared in <tt>&lt;cstdio&gt;</tt> (27.9.2).]</ins>. If a get area exists, the effect is implementation-defined.
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Aaron provides improved wording by removing the params from <tt>std::fseek()</tt> due to the concerns
regarding the parameters on systems where <tt>fseek</tt> uses 32-bit parameters.
<p/>
Second wording improvement, replacing the new one see below. It
</p>
<ol>
<li><p>drops the <tt>std::</tt></p></li>
<li><p>drops the footnote for <tt>fflush</tt></p></li>
<li><p>replaces <tt>fseek</tt> with <tt>fsetpos</tt></p></li>
</ol>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N4431.</p>

<ol>
<li>
<p>Change 27.9.1.5 [filebuf.virtuals] p16 as follows [Editorial note: A footnote referring to <tt>fseek</tt> is not needed,
because this is already covered by the existing footnote 334]:</p>
<blockquote>
<p>
-16- Alters the file position, if possible, to correspond to the position stored in <tt>sp</tt> (as described below).
Altering the file position performs as follows:
</p>
<ol>
<li><p>if <tt>(om &amp; ios_base::out) != 0</tt>, then update the output sequence and write any unshift sequence;</p></li>
<li><p>set the file position to <tt>sp</tt> <ins>as if by a call to <tt>std::fseek</tt></ins>;</p></li>
<li><p>if <tt>(om &amp; ios_base::in) != 0</tt>, then update the input sequence;</p></li>
</ol>
<p>
where <tt>om</tt> is the open mode passed to the last call to <tt>open()</tt>. The operation fails if 
<tt>is_open()</tt> returns false.
</p>
</blockquote>
</li>

<li>
<p>Change 27.9.1.5 [filebuf.virtuals] p19 as follows and add a new footnote that mimics comparable footnotes in
27.9.1.4 [filebuf.members] and 27.9.1.5 [filebuf.virtuals]:</p>
<blockquote>
<p>
-19- <i>Effects</i>: If a put area exists, calls <tt>filebuf::overflow</tt> to write the characters to the file<ins>, then
flushes the file as if by calling <tt>std::fflush(file)</tt> [Footnote: The function signature <tt>fflush(FILE*)</tt> 
is declared in <tt>&lt;cstdio&gt;</tt> (27.9.2).]</ins>. If a get area exists, the effect is implementation-defined.
</p>
</blockquote>
</li>
</ol>
</blockquote>


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

<ol>
<li>
<p>Change 27.9.1.5 [filebuf.virtuals] p16 as follows:</p>
<blockquote>
<p>
-16- Alters the file position, if possible, to correspond to the position stored in <tt>sp</tt> (as described below).
Altering the file position performs as follows:
</p>
<ol>
<li><p>if <tt>(om &amp; ios_base::out) != 0</tt>, then update the output sequence and write any unshift sequence;</p></li>
<li><p>set the file position to <tt>sp</tt> <ins>as if by a call to <tt>fsetpos</tt></ins>;</p></li>
<li><p>if <tt>(om &amp; ios_base::in) != 0</tt>, then update the input sequence;</p></li>
</ol>
<p>
where <tt>om</tt> is the open mode passed to the last call to <tt>open()</tt>. The operation fails if 
<tt>is_open()</tt> returns false.
</p>
</blockquote>
</li>

<li>
<p>Change 27.9.1.5 [filebuf.virtuals] p19 as follows:</p>
<blockquote>
<p>
-19- <i>Effects</i>: If a put area exists, calls <tt>filebuf::overflow</tt> to write the characters to the file<ins>, then
flushes the file as if by calling <tt>fflush(file)</tt></ins>. If a get area exists, the effect is implementation-defined.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2476" href="#2476">2476.</a> <tt>scoped_allocator_adaptor</tt> is not assignable</h3>
<p><b>Section:</b> 20.13.1 [allocator.adaptor.syn] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-03-02 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The class definition in 20.13.1 [allocator.adaptor.syn] declares a move
constructor, which means that the copy assignment operator is defined
as deleted, and no move assignment operator is declared.
<p/>
This means a <tt>scoped_allocator_adaptor</tt> is not assignable, and a
container using <tt>scoped_allocator_adaptor&lt;A...&gt;</tt> may not be
<tt>CopyAssignable</tt> or <tt>MoveAssignable</tt> (depending on the
<tt>propagate_on_container_xxxx_assignment</tt> traits of the outer and inner
allocator types).
</p>

<p><i>[2015-04-03 Howard comments]</i></p>

<p>
If the contained allocators are not assignable, I think we need the ability of <tt>= default</tt> to automagically become 
<tt>= delete</tt>. My concern is that <tt>is_copy_assignable&lt;scoped_allocator_adaptor&lt;CustomAllocator&gt;&gt;::value</tt> 
get the right answer for both cases:
</p>
<ol>
<li><p><tt>is_copy_assignable&lt;CustomAllocator&gt;::value</tt> is <tt>true</tt>.</p></li>
<li><p><tt>is_copy_assignable&lt;CustomAllocator&gt;::value</tt> is <tt>false</tt>.</p></li>
</ol>
<p>
If we allow the vendor to declare and provide the copy assignment operator, the chance of getting #2 correct goes to zero.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N4296.</p>

<ol>
<li>
<p>Add to the synopsis in 20.13.1 [allocator.adaptor.syn]/1 [<i>Editorial remark</i>: The proposed wording
does not explicitly specify the semantics of the added copy/move assignment operators, based on 
17.5.2.2 [functions.within.classes] p1, which says:
<p/>
"For the sake of exposition, Clauses 18 through 30 and Annex D do not describe copy/move constructors,
assignment operators, or (non-virtual) destructors with the same apparent semantics as those that can be
generated by default (12.1, 12.4, 12.8)."
<p/>
&mdash; <i>end remark</i>]:
</p>
<blockquote>
<pre>
[&hellip;]
template &lt;class OuterA2&gt;
  scoped_allocator_adaptor(
    scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp;&amp; other) noexcept;
<ins>
scoped_allocator_adaptor&amp; operator=(const scoped_allocator_adaptor&amp;);
scoped_allocator_adaptor&amp; operator=(scoped_allocator_adaptor&amp;&amp;);
</ins>
~scoped_allocator_adaptor();
[&hellip;]
</pre>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Move to Immediate.
</p>


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

<ol>
<li>
<p>Add to the synopsis in 20.13.1 [allocator.adaptor.syn]/1:
</p>
<blockquote>
<pre>
[&hellip;]
template &lt;class OuterA2&gt;
  scoped_allocator_adaptor(
    scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp;&amp; other) noexcept;
<ins>
scoped_allocator_adaptor&amp; operator=(const scoped_allocator_adaptor&amp;) = default;
scoped_allocator_adaptor&amp; operator=(scoped_allocator_adaptor&amp;&amp;) = default;
</ins>
~scoped_allocator_adaptor();
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2477" href="#2477">2477.</a> Inconsistency of wordings in <tt>std::vector::erase()</tt> and <tt>std::deque::erase()</tt></h3>
<p><b>Section:</b> 23.3.3.4 [deque.modifiers], 23.3.6.5 [vector.modifiers] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Anton Savin <b>Opened:</b> 2015-03-03 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all other</b> <a href="lwg-index.html#deque.modifiers">issues</a> in [deque.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the latest draft N4296, and in all drafts up to at least N3337:
<p/>
23.3.3.4 [deque.modifiers]/5 (regarding <tt>deque::erase()</tt>):
</p>
<blockquote>
<p>
<i>Complexity</i>: The number of calls to the destructor is the same as the number of elements erased, but
the number of calls to the <span style="color:#C80000;font-weight:bold">assignment operator</span> is no more 
than the lesser of the number of elements before the erased elements and the number of elements after the erased elements.
</p>
</blockquote>
<p>
23.3.6.5 [vector.modifiers]/4 (regarding <tt>vector::erase()</tt>):
</p>
<blockquote>
<p>
<i>Complexity</i>: The destructor of <tt>T</tt> is called the number of times equal to the number of the elements
erased, but the <span style="color:#C80000;font-weight:bold">move assignment operator</span> of <tt>T</tt> is called 
the number of times equal to the number of elements in the vector after the erased elements.
</p>
</blockquote>
<p>
Is there any reason for explicit mentioning of move assignment for <tt>std::vector::erase()</tt>? 
Shouldn't these two wordings be the same with this regard?
<p/>
Also, for <tt>std::deque</tt>, it's not clear from the text which destructors and assignment operators are called.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Move to Immediate.
</p>


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

<ol>
<li><p>Change 23.3.3.4 [deque.modifiers]/5 to:</p>

<p>
-5- <i>Complexity</i>: The number of calls to the destructor <ins>of <tt>T</tt></ins> is the same as the number of 
elements erased, but the number of calls to the assignment operator <ins>of <tt>T</tt></ins> is no more than the 
lesser of the number of elements before the erased elements and the number of elements after the erased elements.
</p>
</li>

<li><p>Change 23.3.6.5 [vector.modifiers]/4 to:</p>

<p>
-4- <i>Complexity</i>: The destructor of <tt>T</tt> is called the number of times equal to the number of the elements
erased, but the <del>move</del> assignment operator of <tt>T</tt> is called the number of times equal to the number of
elements in the vector after the erased elements.
</p>
</li>
</ol>






<hr>
<h3><a name="2483" href="#2483">2483.</a> <tt>throw_with_nested()</tt> should use <tt>is_final</tt></h3>
<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
<p><b>View all other</b> <a href="lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2559.htm">N2559</a> was voted into the Working Paper, 
it said "This function template must take special case to handle non-class types, unions and <tt>[[final]]</tt> classes that cannot 
be derived from, and [...]".  However, its Standardese didn't handle <tt>final</tt> classes, and this was never revisited. Now that 
we have <tt>is_final</tt>, we can achieve this proposal's original intention.
<p/>
Additionally, we need to handle the case where <tt>U</tt> is <tt>nested_exception</tt> itself. <tt>is_base_of</tt>'s wording 
handles this and ignores <i>cv</i>-qualifiers. (Note that <tt>is_class</tt> detects "non-union class type".)
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
STL, MC and JW already do this<br/>
MC: move to Ready, bring to motion on Friday<br/>
7 in favor, none opposed 
</p>


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

<ol>
<li><p>Change 18.8.6 [except.nested] as depicted:</p>

<blockquote>
<pre>
template &lt;class T&gt; [[noreturn]] void throw_with_nested(T&amp;&amp; t);
</pre>
<blockquote>
<p>
-6- Let <tt>U</tt> be <tt>remove_reference_t&lt;T&gt;</tt>.
<p/>
-7- Requires: <tt>U</tt> shall be <tt>CopyConstructible</tt>.
<p/>
-8- Throws: if <del><tt>U</tt> is a non-union class type not derived from 
<tt>nested_exception</tt></del><ins><tt>is_class&lt;U&gt;::value &amp;&amp; !is_final&lt;U&gt;::value &amp;&amp; 
!is_base_of&lt;nested_exception, U&gt;::value</tt> is <tt>true</tt></ins>, an exception of unspecified type that 
is publicly derived from both <tt>U</tt> and <tt>nested_exception</tt> and constructed from 
<tt>std::forward&lt;T&gt;(t)</tt>, otherwise <tt>std::forward&lt;T&gt;(t)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2484" href="#2484">2484.</a> <tt>rethrow_if_nested()</tt> is doubly unimplementable</h3>
<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
<p><b>View all other</b> <a href="lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>rethrow_if_nested()</tt> wants to determine "If the dynamic type of <tt>e</tt> is publicly and unambiguously derived 
from <tt>nested_exception</tt>", but 5.2.7 [expr.dynamic.cast] specifies that <tt>dynamic_cast</tt> has a couple 
of limitations.
<p/>
First, nonpolymorphic inputs. These could be non-classes, or nonpolymorphic classes. The Standardese handles non-classes, 
although implementers need special logic. (If <tt>E</tt> is <tt>int</tt>, the dynamic type can't possibly derive from 
<tt>nested_exception</tt>. Implementers need to detect this and avoid <tt>dynamic_cast</tt>, which would be ill-formed 
due to 5.2.7 [expr.dynamic.cast]/2.) The Standardese is defective when <tt>E</tt> is a nonpolymorphic class.  
Consider the following example:
</p>
<blockquote>
<pre>
struct Nonpolymorphic { };
struct MostDerived : Nonpolymorphic, nested_exception { };
MostDerived md;
const Nonpolymorphic&amp; np = md;
rethrow_if_nested(np);
</pre>
</blockquote>
<p>
According to 1.3.8 [defns.dynamic.type], the dynamic type of <tt>np</tt> is <tt>MostDerived</tt>. However, it's 
physically impossible to discover this, and attempting to do so will lead to an ill-formed <tt>dynamic_cast</tt> 
(5.2.7 [expr.dynamic.cast]/6). The Standardese must be changed to say that if <tt>E</tt> is nonpolymorphic, nothing happens.
<p/>
Second, statically good but dynamically bad inputs. Consider the following example:
</p>
<blockquote>
<pre>
struct Nested1 : nested_exception { };
struct Nested2 : nested_exception { };
struct Ambiguous : Nested1, Nested2 { };
Ambiguous amb;
const Nested1&amp; n1 = amb;
rethrow_if_nested(n1);
</pre>
</blockquote>
<p>
Here, the static type <tt>Nested1</tt> is good (i.e. publicly and unambiguously derived from <tt>nested_exception</tt>), but 
the dynamic type <tt>Ambiguous</tt> is bad. The Standardese currently says that we have to detect the dynamic badness, but 
<tt>dynamic_cast</tt> won't let us. 5.2.7 [expr.dynamic.cast]/3 and /5 are special cases (identity-casting and upcasting, 
respectively) that activate before the "run-time check" behavior that we want (/6 and below). Statically good inputs succeed 
(regardless of the dynamic type) and statically bad inputs are ill-formed (implementers must use type traits to avoid this).
<p/>
It might be possible to implement this with clever trickery involving virtual base classes, but implementers shouldn't be asked 
to do that.  It would definitely be possible to implement this with a compiler hook (a special version of <tt>dynamic_cast</tt>), 
but implementers shouldn't be asked to do so much work for such an unimportant case. (This case is pathological because the 
usual way of adding <tt>nested_exception</tt> inheritance is <tt>throw_with_nested()</tt>, which avoids creating bad inheritance.)  
The Standardese should be changed to say that statically good inputs are considered good.
<p/>
Finally, we want <tt>is_base_of</tt>'s "base class or same class" semantics. If the static type is <tt>nested_exception</tt>, 
we have to consider it good due to <tt>dynamic_cast</tt>'s identity-casting behavior. And if the dynamic type is 
<tt>nested_exception</tt>, it is definitely good.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
WB: so the <tt>is_polymorphic</tt> trait must be used?<br/>
STL and JW: yes, that must be used to decide whether to try using <tt>dynamic_cast</tt> or not.<br/>
JW: I'd already made this fix in our implementation<br/>
STL: the harder case also involves <tt>dynamic_cast</tt>. should not try using <tt>dynamic_cast</tt> if we can 
statically detect it is OK, doing the <tt>dynamic_cast</tt> might fail.<br/>
STL: finally, want "is the same or derived from" behaviour of <tt>is_base_of</tt><br/>
WB: should there be an "else no effect" at the end? We have "Otherwise, if ..." and nothing saying what if the condition is false.<br/>
TP I agree.<br/>
MC: move to Ready and bring to motion on Friday<br/>
7 in favor, none opposed 
</p>


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

<ol>
<li><p>Change 18.8.6 [except.nested] as depicted:</p>

<blockquote>
<pre>
template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
</pre>
<blockquote>
<p>
-9- <i>Effects</i>: If <ins><tt>E</tt> is not a polymorphic class type, there is no effect. Otherwise, if the static 
type or</ins> the dynamic type of <tt>e</tt> <ins>is <tt>nested_exception</tt> or</ins> is publicly and unambiguously 
derived from <tt>nested_exception</tt>, calls <tt>dynamic_cast&lt;const nested_exception&amp;&gt;(e).rethrow_nested()</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2485" href="#2485">2485.</a> <tt>get()</tt> should be overloaded for <tt>const tuple&amp;&amp;</tt></h3>
<p><b>Section:</b> 20.4.2.6 [tuple.elem] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.elem">issues</a> in [tuple.elem].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>const</tt> rvalues are weird, but they're part of the type system. Consider the following code:
</p>
<blockquote>
<pre>
#include &lt;functional&gt;
#include &lt;string&gt;
#include &lt;tuple&gt;

using namespace std; 

string str1() { return "one"; }
const string str2() { return "two"; }
tuple&lt;string&gt; tup3() { return make_tuple("three"); }
const tuple&lt;string&gt; tup4() { return make_tuple("four"); }

int main() {
  // cref(str1()); // BAD, properly rejected
  // cref(str2()); // BAD, properly rejected
  // cref(get&lt;0&gt;(tup3())); // BAD, properly rejected
  cref(get&lt;0&gt;(tup4())); // BAD, but improperly accepted!
}
</pre>
</blockquote>
<p>
As <tt>tuple</tt> is a fundamental building block (and the only convenient way to have variadic data members), it should 
not open a hole in the type system. <tt>get()</tt> should imitate 5.2.5 [expr.ref]'s rules for accessing data members.  
(This is especially true for <tt>pair</tt>, where both <tt>get&lt;0&gt;()</tt> and <tt>.first</tt> are available.)
<p/>
While we're in the neighborhood, we can dramatically simplify the wording here. All we need to do is follow 
20.4.2.6 [tuple.elem]/9's example of saying "Returns: A reference to STUFF", and allow implementers to figure out how 
to achieve that with the given return types.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
TP: for the existing overloads there's no change to the code, just descriptions?<br/>
STL: right.<br/>
JW: I love it<br/>
MC: in favor of moving to Ready and bringing up for vote on Friday<br/>
7 in favor, none opposed 
</p>


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

<ol>
<li><p>Change 20.2 [utility]/2 "Header <tt>&lt;utility&gt;</tt> synopsis" as depicted:</p>

<blockquote>
<pre>
[&hellip;]
template&lt;size_t I, class T1, class T2&gt;
  constexpr tuple_element_t&lt;I, pair&lt;T1, T2&gt;&gt;&amp;
    get(pair&lt;T1, T2&gt;&amp;) noexcept;
template&lt;size_t I, class T1, class T2&gt;
  constexpr tuple_element_t&lt;I, pair&lt;T1, T2&gt;&gt;&amp;&amp;
    get(pair&lt;T1, T2&gt;&amp;&amp;) noexcept;
template&lt;size_t I, class T1, class T2&gt;
  constexpr const tuple_element_t&lt;I, pair&lt;T1, T2&gt;&gt;&amp;
    get(const pair&lt;T1, T2&gt;&amp;) noexcept;
<ins>template&lt;size_t I, class T1, class T2&gt;
  constexpr const tuple_element_t&lt;I, pair&lt;T1, T2&gt;&gt;&amp;&amp;
    get(const pair&lt;T1, T2&gt;&amp;&amp;) noexcept;</ins>
template &lt;class T, class U&gt;
  constexpr T&amp; get(pair&lt;T, U&gt;&amp; p) noexcept;
template &lt;class T, class U&gt;
  constexpr const T&amp; get(const pair&lt;T, U&gt;&amp; p) noexcept;
template &lt;class T, class U&gt;
  constexpr T&amp;&amp; get(pair&lt;T, U&gt;&amp;&amp; p) noexcept;
<ins>template &lt;class T, class U&gt;
  constexpr const T&amp;&amp; get(const pair&lt;T, U&gt;&amp;&amp; p) noexcept;</ins>
template &lt;class T, class U&gt;
  constexpr T&amp; get(pair&lt;U, T&gt;&amp; p) noexcept;
template &lt;class T, class U&gt;
  constexpr const T&amp; get(const pair&lt;U, T&gt;&amp; p) noexcept;
template &lt;class T, class U&gt;
  constexpr T&amp;&amp; get(pair&lt;U, T&gt;&amp;&amp; p) noexcept;
<ins>template &lt;class T, class U&gt;
  constexpr const T&amp;&amp; get(const pair&lt;U, T&gt;&amp;&amp; p) noexcept;</ins>
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Change 20.4.1 [tuple.general]/2 "Header <tt>&lt;tuple&gt;</tt> synopsis" as depicted:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 20.4.2.6, element access:</i>
template &lt;size_t I, class... Types&gt;
constexpr tuple_element_t&lt;I, tuple&lt;Types...&gt;&gt;&amp;
get(tuple&lt;Types...&gt;&amp;) noexcept;
template &lt;size_t I, class... Types&gt;
constexpr tuple_element_t&lt;I, tuple&lt;Types...&gt;&gt;&amp;&amp;
get(tuple&lt;Types...&gt;&amp;&amp;) noexcept;
template &lt;size_t I, class... Types&gt;
constexpr const tuple_element_t&lt;I, tuple&lt;Types...&gt;&gt;&amp;
get(const tuple&lt;Types...&gt;&amp;) noexcept;
<ins>template &lt;size_t I, class... Types&gt;
constexpr const tuple_element_t&lt;I, tuple&lt;Types...&gt;&gt;&amp;&amp;
get(const tuple&lt;Types...&gt;&amp;&amp;) noexcept;</ins>
template &lt;class T, class... Types&gt;
constexpr T&amp; get(tuple&lt;Types...&gt;&amp; t) noexcept;
template &lt;class T, class... Types&gt;
constexpr T&amp;&amp; get(tuple&lt;Types...>&amp;&amp; t) noexcept;
template &lt;class T, class... Types&gt;
constexpr const T&amp; get(const tuple&lt;Types...&gt;&amp; t) noexcept;
<ins>template &lt;class T, class... Types&gt;
constexpr const T&amp;&amp; get(const tuple&lt;Types...&gt;&amp;&amp; t) noexcept;</ins>
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Change 23.3.1 [sequences.general]/2 "Header <tt>&lt;array&gt;</tt> synopsis" as depicted:</p>

<blockquote>
<pre>
[&hellip;]
template &lt;size_t I, class T, size_t N&gt;
constexpr T&amp; get(array&lt;T, N&gt;&amp;) noexcept;
template &lt;size_t I, class T, size_t N&gt;
constexpr T&amp;&amp; get(array&lt;T, N&gt;&amp;&amp;) noexcept;
template &lt;size_t I, class T, size_t N&gt;
constexpr const T&amp; get(const array&lt;T, N&gt;&amp;) noexcept;
<ins>template &lt;size_t I, class T, size_t N&gt;
constexpr const T&amp;&amp; get(const array&lt;T, N&gt;&amp;&amp;) noexcept;</ins>
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Change 20.3.4 [pair.astuple] as depicted:</p>

<blockquote>
<pre>
template&lt;size_t I, class T1, class T2&gt;
constexpr tuple_element_t&lt;I, pair&lt;T1, T2&gt;&gt;&amp;
get(pair&lt;T1, T2&gt;&amp; p) noexcept;
template&lt;size_t I, class T1, class T2&gt;
constexpr const tuple_element_t&lt;I, pair&lt;T1, T2&gt;&gt;&amp;
get(const pair&lt;T1, T2&gt;&amp; p) noexcept;
</pre>
<blockquote>
<p>
<del>-3- <i>Returns</i>: If <tt>I == 0</tt> returns <tt>p.first</tt>; if <tt>I == 1</tt> returns <tt>p.second</tt>; 
otherwise the program is ill-formed.</del>
</p>
</blockquote>
<pre>
template&lt;size_t I, class T1, class T2&gt;
constexpr tuple_element_t&lt;I, pair&lt;T1, T2&gt;&gt;&amp;&amp;
get(pair&lt;T1, T2&gt;&amp;&amp; p) noexcept;
<ins>template&lt;size_t I, class T1, class T2&gt;
constexpr const tuple_element_t&lt;I, pair&lt;T1, T2&gt;&gt;&amp;&amp;
get(const pair&lt;T1, T2&gt;&amp;&amp; p) noexcept;</ins>
</pre>
<blockquote>
<p>
-4- <i>Returns</i>: If <tt>I == 0</tt> returns <ins>a reference to</ins> 
<tt><del>std::forward&lt;T1&amp;&amp;&gt;(</del>p.first<del>)</del></tt>; if <tt>I == 1</tt> 
returns <ins>a reference to</ins> <tt><del>std::forward&lt;T2&amp;&amp;&gt;(</del>p.second<del>)</del></tt>; 
otherwise the program is ill-formed.
</p>
</blockquote>
<pre>
template &lt;class T, class U&gt;
constexpr T&amp; get(pair&lt;T, U&gt;&amp; p) noexcept;
template &lt;class T, class U&gt;
constexpr const T&amp; get(const pair&lt;T, U&gt;&amp; p) noexcept;
</pre>
<blockquote>
<p>
<del>-5- Requires: <tt>T</tt> and <tt>U</tt> are distinct types. Otherwise, the program is ill-formed.</del>
<p/>
<del>-6- Returns: <tt>get&lt;0&gt;(p)</tt>;</del>
</p>
</blockquote>
<pre>
template &lt;class T, class U&gt;
constexpr T&amp;&amp; get(pair&lt;T, U&gt;&amp;&amp; p) noexcept;
<ins>template &lt;class T, class U&gt;
constexpr const T&amp;&amp; get(const pair&lt;T, U&gt;&amp;&amp; p) noexcept;</ins>
</pre>
<blockquote>
<p>
-7- Requires: <tt>T</tt> and <tt>U</tt> are distinct types. Otherwise, the program is ill-formed.
<p/>
-8- Returns: <ins>A reference to <tt>p.first</tt>.</ins><del><tt>get&lt;0&gt;(std::move(p))</tt>;</del>
</p>
</blockquote>
<pre>
template &lt;class T, class U&gt;
constexpr T&amp; get(pair&lt;U, T&gt;&amp; p) noexcept;
template &lt;class T, class U&gt;
constexpr const T&amp; get(const pair&lt;U, T&gt;&amp; p) noexcept;
</pre>
<blockquote>
<p>
<del>-9- Requires: <tt>T</tt> and <tt>U</tt> are distinct types. Otherwise, the program is ill-formed.</del>
<p/>
<del>-10- Returns: <tt>get&lt;1&gt;(p)</tt>;</del>
</p>
</blockquote>
<pre>
template &lt;class T, class U&gt;
constexpr T&amp;&amp; get(pair&lt;U, T&gt;&amp;&amp; p) noexcept;
<ins>template &lt;class T, class U&gt;
constexpr const T&amp;&amp; get(const pair&lt;U, T&gt;&amp;&amp; p) noexcept;</ins>
</pre>
<blockquote>
<p>
-11- Requires: <tt>T</tt> and <tt>U</tt> are distinct types. Otherwise, the program is ill-formed.
<p/>
-12- Returns: <ins>A reference to <tt>p.second</tt>.</ins><del><tt>get&lt;1&gt;(std::move(p))</tt>;</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.4.2.6 [tuple.elem] as depicted:</p>

<blockquote>
<pre>
template &lt;size_t I, class... Types&gt;
  constexpr tuple_element_t&lt;I, tuple&lt;Types...&gt; &gt;&amp; get(tuple&lt;Types...&gt;&amp; t) noexcept;
</pre>
<blockquote>
<p>
<del>-1- <i>Requires</i>: <tt>I &lt; sizeof...(Types)</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.</del>
<p/>
<del>-2- <i>Returns</i>: A reference to the <tt>I</tt>th element of <tt>t</tt>, where indexing is zero-based.</del>
</p>
</blockquote>
<pre>
template &lt;size_t I, class... Types&gt;
  constexpr tuple_element_t&lt;I, tuple&lt;Types...&gt; &gt;&amp;&amp; get(tuple&lt;Types...&gt;&amp;&amp; t) noexcept; <ins><i>// Note A</i></ins>
</pre>
<blockquote>
<p>
<del>-3- <i>Effects</i>: Equivalent to return std::forward&lt;typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp;&gt;(get&lt;I&gt;(t));</del>
<p/>
<del>-4- <i>Note</i>: if a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&amp;</tt>, the return type is <tt>X&amp;</tt>, not 
<tt>X&amp;&amp;</tt>. However, if the element type is a non-reference type <tt>T</tt>, the return type is <tt>T&amp;&amp;</tt>.</del>
</p>
</blockquote>
<pre>
template &lt;size_t I, class... Types&gt;
  constexpr tuple_element_t&lt;I, tuple&lt;Types...&gt; &gt; const&amp; get(const tuple&lt;Types...&gt;&amp; t) noexcept; <ins><i>// Note B</i></ins>
<ins>template &lt;size_t I, class... Types&gt;
  constexpr const tuple_element_t&lt;I, tuple&lt;Types...&gt; &gt;&amp;&amp; get(const tuple&lt;Types...&gt;&amp;&amp; t) noexcept;</ins>  
</pre>
<blockquote>
<p>
-5- <i>Requires</i>: <tt>I &lt; sizeof...(Types)</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.
<p/>
-6- <i>Returns</i>: A <del>const</del> reference to the <tt>I</tt>th element of <tt>t</tt>, where indexing is zero-based.
<p/>
<ins>-?- [<i>Note A</i>: if a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&amp;</tt>, the return type is <tt>X&amp;</tt>, 
not <tt>X&amp;&amp;</tt>. However, if the element type is a non-reference type <tt>T</tt>, the return type is <tt>T&amp;&amp;</tt>. 
&mdash; <i>end note</i>]</ins>
<p/>
-7- [<i>Note <ins>B</ins></i>: Constness is shallow. If a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&amp;</tt>, 
the return type is <tt>X&amp;</tt>, not <tt>const X&amp;</tt>. However, if the element type is non-reference type <tt>T</tt>, 
the return type is <tt>const T&amp;</tt>. This is consistent with how constness is defined to work for member variables of 
reference type. &mdash; <i>end note</i>]
</p>
</blockquote>
<pre>
template &lt;class T, class... Types&gt;
  constexpr T&amp; get(tuple&lt;Types...&gt;&amp; t) noexcept;
template &lt;class T, class... Types&gt;
  constexpr T&amp;&amp; get(tuple&lt;Types...&gt;&amp;&amp; t) noexcept;
template &lt;class T, class... Types&gt;
  constexpr const T&amp; get(const tuple&lt;Types...&gt;&amp; t) noexcept;
<ins>template &lt;class T, class... Types&gt;
  constexpr const T&amp;&amp; get(const tuple&lt;Types...&gt;&amp;&amp; t) noexcept;</ins>
</pre>
<blockquote>
<p>
-8- <i>Requires</i>: The type <tt>T</tt> occurs exactly once in <tt>Types...</tt>. Otherwise, the program is ill-formed.
<p/>
-9- <i>Returns</i>: A reference to the element of <tt>t</tt> corresponding to the type <tt>T</tt> in <tt>Types...</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.3.2.9 [array.tuple] as depicted:</p>

<blockquote>
<pre>
template &lt;size_t I, class T, size_t N&gt;
<ins>  </ins>constexpr T&amp; get(array&lt;T, N&gt;&amp; a) noexcept;
</pre>
<blockquote>
<p>
<del>-3- <i>Requires</i>: <tt>I &lt; N</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.</del>
<p/>
<del>-4- <i>Returns</i>: A reference to the <tt>I</tt>th element of <tt>a</tt>, where indexing is zero-based.</del>
</p>
</blockquote>
<pre>
template &lt;size_t I, class T, size_t N&gt;
<ins>  </ins>constexpr T&amp;&amp; get(array&lt;T, N&gt;&amp;&amp; a) noexcept;
</pre>
<blockquote>
<p>
<del>-5- <i>Effects</i>: Equivalent to <tt>return std::move(get&lt;I&gt;(a));</tt></del>
</p>
</blockquote>
<pre>
template &lt;size_t I, class T, size_t N&gt;
<ins>  </ins>constexpr const T&amp; get(const array&lt;T, N&gt;&amp; a) noexcept;
<ins>template &lt;size_t I, class T, size_t N&gt;
  constexpr const T&amp;&amp; get(const array&lt;T, N&gt;&amp;&amp; a) noexcept;</ins>
</pre>
<blockquote>
<p>
-6- <i>Requires</i>: <tt>I &lt; N</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.
<p/>
-7- <i>Returns</i>: A <del>const</del> reference to the <tt>I</tt>th element of <tt>a</tt>, where indexing is zero-based.
</p>
</blockquote>
</blockquote>
</li>


</ol>






<hr>
<h3><a name="2486" href="#2486">2486.</a> <tt>mem_fn()</tt> should be required to use perfect forwarding</h3>
<p><b>Section:</b> 20.9.2 [func.require] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.9.2 [func.require]/4 defines "simple call wrapper" and "forwarding call wrapper". Only <tt>mem_fn()</tt> is 
specified to be a "simple call wrapper", by 20.9.11 [func.memfn]/1: "A simple call wrapper (20.9.1) <tt>fn</tt> 
such that the expression <tt>fn(t, a2, ..., aN)</tt> is equivalent to <tt>INVOKE(pm, t, a2, ..., aN)</tt> (20.9.2)."
<p/>
This suggests, but doesn't outright state, that perfect forwarding is involved. It matters for PMFs like 
<tt>R (T::*)(Arg)</tt> where <tt>Arg</tt> is passed by value &mdash; if the <tt>mem_fn()</tt> wrapper's function call 
operator takes <tt>Arg</tt> by value, an extra copy/move will be observable. We should require perfect forwarding here.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Move to Immediate.
</p>



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

<ol>
<li><p>Change 20.9.2 [func.require] as depicted [<i>Editorial remark</i>: This simply adds "A simple call wrapper 
is a <ins>forwarding</ins> call wrapper", then moves the sentence. &mdash; <i>end of remark</i>]:</p>

<blockquote>
<p>
-4- Every call wrapper (20.9.1) shall be <tt>MoveConstructible</tt>. <del>A <i>simple call wrapper</i> is a call wrapper that is
<tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> and whose copy constructor, move constructor, and assignment
operator do not throw exceptions.</del> A <i>forwarding call wrapper</i> is a call wrapper that can be called with
an arbitrary argument list and delivers the arguments to the wrapped callable object as references. This
forwarding step shall ensure that rvalue arguments are delivered as rvalue-references and lvalue arguments
are delivered as lvalue-references. <ins>A <i>simple call wrapper</i> is a forwarding call wrapper that is <tt>CopyConstructible</tt> 
and <tt>CopyAssignable</tt> and whose copy constructor, move constructor, and assignment operator do not throw exceptions.</ins> 
[<i>Note</i>: In a typical implementation [&hellip;] &mdash; <i>end note</i>]
</p>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2487" href="#2487">2487.</a> <tt>bind()</tt> should be <tt>const</tt>-overloaded, not <i>cv</i>-overloaded</h3>
<p><b>Section:</b> 20.9.10.3 [func.bind.bind] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The Standard currently requires <tt>bind()</tt> to return something with a <i>cv</i>-overloaded function call operator.  
<tt>const</tt> is great, but <tt>volatile</tt> is not. First, the Library almost always ignores <tt>volatile</tt>'s 
existence (with <tt>&lt;type_traits&gt;</tt> and <tt>&lt;atomic&gt;</tt> being rare exceptions). Second, implementations 
typically store bound arguments in a <tt>tuple</tt>, but <tt>get()</tt> isn't overloaded for <tt>volatile tuple</tt>. Third, 
when a bound argument is a <tt>reference_wrapper</tt>, we have to call <tt>tid.get()</tt>, but that won't compile for a 
<tt>volatile reference_wrapper</tt>. Finally, <tt>const</tt> and <tt>volatile</tt> don't always have to be handled symmetrically 
&mdash; for example, lambda function call operators are <tt>const</tt> by default, but they can't ever be <tt>volatile</tt>.
<p/>
Implementers shouldn't be required to provide <i>cv</i>-overloading here. (They can provide it as a conforming extension if 
they want.)
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
JW: why would a <tt>reference_wrapper</tt> be volatile?<br/>
STL: if a bound argument is a <tt>reference_wrapper</tt> then in a volatile-qualified operator() that 
member will be volatile so you can't call get() on it<br/>
STL: worded like this it's a conforming extension to kep overloading on volatile<br/>
HH: libc++ doesn't overload on volatile<br/>
JW: libstdc++ does overload for volatile<br/>
MC: move to Ready and bring motion on Friday<br/>
10 in favor, none opposed 
</p>


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

<ol>
<li><p>Change 20.9.10.3 [func.bind.bind] as depicted:</p>

<blockquote>
<pre>
template&lt;class F, class... BoundArgs&gt;
  <i>unspecified</i> bind(F&amp;&amp; f, BoundArgs&amp;&amp;... bound_args);
</pre>
<blockquote>
<p>
-2- <i>Requires</i>: <tt>is_constructible&lt;FD, F&gt;::value</tt> shall be <tt>true</tt>. For each <tt>Ti</tt> 
in <tt>BoundArgs</tt>, <tt>is_constructible&lt;TiD, Ti&gt;::value</tt> shall be <tt>true</tt>. 
<tt><i>INVOKE</i>(fd, w1, w2, ..., wN)</tt> (20.9.2) shall be a valid expression for some values <tt>w1</tt>, <tt>w2</tt>, 
..., <tt>wN</tt>, where <tt>N == sizeof...(bound_args)</tt>. <ins>The <i>cv</i>-qualifiers <i>cv</i> of the call 
wrapper <tt>g</tt>, as specified below, shall be neither <tt>volatile</tt> nor <tt>const volatile</tt>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class R, class F, class... BoundArgs&gt;
  <i>unspecified</i> bind(F&amp;&amp; f, BoundArgs&amp;&amp;... bound_args);
</pre>
<blockquote>
<p>
-6- <i>Requires</i>: <tt>is_constructible&lt;FD, F&gt;::value</tt> shall be <tt>true</tt>. For each <tt>Ti</tt> 
in <tt>BoundArgs</tt>, <tt>is_constructible&lt;TiD, Ti&gt;::value</tt> shall be <tt>true</tt>. 
<tt><i>INVOKE</i>(fd, w1, w2, ..., wN)</tt> shall be a valid expression for some values <tt>w1</tt>, <tt>w2</tt>, 
..., <tt>wN</tt>, where <tt>N == sizeof...(bound_args)</tt>. <ins>The <i>cv</i>-qualifiers <i>cv</i> of the call 
wrapper <tt>g</tt>, as specified below, shall be neither <tt>volatile</tt> nor <tt>const volatile</tt>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2489" href="#2489">2489.</a> <tt>mem_fn()</tt> should be <tt>noexcept</tt></h3>
<p><b>Section:</b> 20.9.11 [func.memfn] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2015-03-27 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all other</b> <a href="lwg-index.html#func.memfn">issues</a> in [func.memfn].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>mem_fn()</tt> is wide contract and doesn't do anything that could throw exceptions, so it should be marked <tt>noexcept</tt>.
<p/>
Note that <tt>mem_fn()</tt> is perfectly happy to wrap a null PMF/PMD, it just can't be invoked later. This is exactly like 
<tt>std::function</tt>, which can be constructed from null PMFs/PMDs. Therefore, <tt>mem_fn()</tt> will remain wide contract forever.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Move to Immediate.
</p>



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

<ol>
<li><p>Change 20.9 [function.objects] p2 "Header <tt>&lt;functional&gt;</tt> synopsis" as depicted:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 20.9.11, member function adaptors:</i>
template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::*) <ins>noexcept</ins>;
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Change 20.9.11 [func.memfn] as depicted:</p>

<blockquote>
<pre>
template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::* pm) <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
<del>-4- <i>Throws</i>: Nothing.</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2492" href="#2492">2492.</a> Clarify requirements for <tt>comp</tt></h3>
<p><b>Section:</b> 25.4 [alg.sorting] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Anton Savin <b>Opened:</b> 2015-04-14 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
N4296 25.4 [alg.sorting]/3 reads:
</p>
<blockquote><p>
For all algorithms that take <tt>Compare</tt>, there is a version that uses <tt>operator&lt;</tt> instead. That is, 
<tt>comp(*i,*j) != false</tt> defaults to <tt>*i &lt; *j != false</tt>. For algorithms other than those described in 
25.4.3  to work correctly, <tt>comp</tt>  has to induce a strict weak ordering on the values.
</p></blockquote>
<p>
So it's not specified clearly what happens if <tt>comp</tt> or <tt>operator&lt;</tt> don't induce a strict weak ordering. 
Is it undefined or implementation-defined behavior? It seems that it should be stated more clearly that the behavior is 
undefined.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Move to Immediate.
</p>


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

<ol>
<li><p>Change 25.4 [alg.sorting]/3 to the following:</p>
<blockquote>
<p>
For all algorithms that take <tt>Compare</tt>, there is a version that uses <tt>operator&lt;</tt> instead. That is, <tt>comp(*i,
*j) != false</tt> defaults to <tt>*i &lt; *j != false</tt>. For algorithms other than those described in 25.4.3 <del>to work
correctly</del>, <tt>comp</tt> <ins>shall</ins><del>has to</del> induce a strict weak ordering on the values.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2494" href="#2494">2494.</a> [fund.ts.v2] <tt>ostream_joiner</tt> needs <tt>noexcept</tt></h3>
<p><b>Section:</b> X [iterator.ostream.joiner] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Nate Wilson <b>Opened:</b> 2015-05-03 <b>Last modified:</b> 2015-05-08</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
In Library Fundamentals 2 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4481.html#iterator.ostream.joiner.ops">N4481</a>, 
[iterator.ostream.joiner], all operations are no-ops other than the assignment operator.
<p/>
So, they should be marked as <tt>noexcept</tt>.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
Move to Immediate.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4481 in regard to fundamental-ts-2 changes.</p>

<ol>
<li><p>Change class template <tt>ostream_joiner</tt> synopsis, [iterator.ostream.joiner] p2, as indicated:</p>

<blockquote>
<pre>
namespace std {
namespace experimental {
inline namespace fundamentals_v2 {

template &lt;class DelimT, class charT = char, class traits = char_traits&lt;charT&gt; &gt;
  class ostream_joiner {
  public:
    [&hellip;]
    ostream_joiner&lt;DelimT, charT,traits&gt;&amp; operator*() <ins>noexcept</ins>;
    ostream_joiner&lt;DelimT, charT,traits&gt;&amp; operator++() <ins>noexcept</ins>;
    ostream_joiner&lt;DelimT, charT,traits&gt;&amp; operator++(int) <ins>noexcept</ins>;
    [&hellip;]
  };

} // inline namespace fundamentals_v2
} // namespace experimental
} // namespace std
</pre>
</blockquote>
</li>

<li><p>Change [iterator.ostream.joiner.ops] p3+5, as indicated:</p>

<blockquote>
<pre>
ostream_joiner&lt;DelimT, charT, traits&gt;&amp; operator*() <ins>noexcept</ins>;
</pre>
<p>
[&hellip;]
</p>
<pre>
ostream_joiner&lt;DelimT, charT, traits&gt;&amp; operator++() <ins>noexcept</ins>;
ostream_joiner&lt;DelimT, charT, traits&gt;&amp; operator++(int) <ins>noexcept</ins>;
</pre>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2495" href="#2495">2495.</a> There is no such thing as an <i>Exception Safety</i> element</h3>
<p><b>Section:</b> 20.8.2.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-05-05 <b>Last modified:</b> 2015-08-03</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.8.2.2.1 [util.smartptr.shared.const] includes several "Exception safety"
elements, but that is not one of the elements defined in 17.5.1.4
17.5.1.4 [structure.specifications]. We should either define what it means, or
just move those sentences into the <i>Effects:</i> clause.
</p>

<p><i>[2015-06, Telecom]</i></p>

<p>
Move to Tentatively Ready.
</p>


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

<ol>
<li><p>Change 20.8.2.2.1 [util.smartptr.shared.const] as follows:</p>

<blockquote>
<pre>
template&lt;class Y&gt; explicit shared_ptr(Y* p);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-4- <i>Effects</i>: Constructs a <tt>shared_ptr</tt> object that <i>owns</i> the pointer <tt>p</tt>. <ins>If an exception 
is thrown, <tt>delete p</tt> is called.</ins>
<p/>
[&hellip;]
<p/>
<del>-7- <i>Exception safety</i>: If an exception is thrown, <tt>delete p</tt> is called.</del>
</p>
</blockquote>
<pre>
template &lt;class Y, class D&gt; shared_ptr(Y* p, D d);
template &lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
template &lt;class D&gt; shared_ptr(nullptr_t p, D d);
template &lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-9- <i>Effects</i>: Constructs a <tt>shared_ptr</tt> object that owns the object <tt>p</tt> and the deleter <tt>d</tt>. 
The second and fourth constructors shall use a copy of <tt>a</tt> to allocate memory for internal use. <ins>If an exception 
is thrown, <tt>d(p)</tt> is called.</ins>
<p/>
[&hellip;]
<p/>
<del>-12- <i>Exception safety</i>: If an exception is thrown, <tt>d(p)</tt> is called.</del>
</p>
</blockquote>
[&hellip;]
<pre>
template &lt;class Y&gt; explicit shared_ptr(const weak_ptr&lt;Y&gt;&amp; r);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-24- <i>Effects</i>: Constructs a <tt>shared_ptr</tt> object that shares ownership with <tt>r</tt> and stores a copy of the pointer
stored in <tt>r</tt>. <ins>If an exception is thrown, the constructor has no effect.</ins>
<p/>
[&hellip;]
<p/>
<del>-27- <i>Exception safety</i>: If an exception is thrown, the constructor has no effect.</del>
</p>
</blockquote>
<pre>
template &lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-29- <i>Effects</i>: Equivalent to <tt>shared_ptr(r.release(), r.get_deleter())</tt> when <tt>D</tt> is not a reference type,
otherwise <tt>shared_ptr(r.release(), ref(r.get_deleter()))</tt>. <ins>If an exception is thrown, the constructor has no effect.</ins>
<p/>
<del>-30- <i>Exception safety</i>: If an exception is thrown, the constructor has no effect.</del>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2500" href="#2500">2500.</a> [fund.ts.v2] fundts.memory.smartptr.shared.obs/6 should apply to <i>cv</i>-unqualified <tt>void</tt></h3>
<p><b>Section:</b> X [memory.smartptr.shared.obs] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2015-05-11 <b>Last modified:</b> 2015-09-14</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
S. B. Tam reported this <a href="https://github.com/cplusplus/fundamentals-ts/issues/51">here</a>.
<p/>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3920.html">N3920</a> changed <tt>operator*()</tt> in 
[util.smartptr.shared.obs] as:
</p>
<blockquote>
<p>
<i>Remarks</i>: When <tt>T</tt> is <ins>an array type or <i>cv</i>-qualified</ins> <tt>void</tt>, it
is unspecified whether this member function is declared. &hellip;
</p>
</blockquote>
<p>
This excludes <i>cv</i>-unqualified <tt>void</tt>, which is probably unintended.
</p>

<p><i>[2015-09-11, Telecom]</i></p>

<p>
Move to Tentatively Ready
</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li><p>In the <a href="https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#memory.smartptr.shared.obs.6">library 
fundamentals v2</a>, [memory.smartptr.shared.obs] p2, change as indicated:</p>
<blockquote>
<p>
<i>Remarks</i>: When <tt>T</tt> is an array type or <ins>(possibly</ins> <i>cv</i>-qualified<ins>)</ins> 
<tt>void</tt>, it is unspecified whether this
member function is declared. If it is declared, it is unspecified what
its return type is, except that the declaration (although not
necessarily the definition) of the function shall be well formed.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2510" href="#2510">2510.</a> Tag types should not be <tt>DefaultConstructible</tt></h3>
<p><b>Section:</b> 18.6 [support.dynamic], 20.2 [utility], 20.3.5 [pair.piecewise], 20.7.2 [memory.syn], 20.7.6 [allocator.tag], 30.4 [thread.mutex] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2015-06-13 <b>Last modified:</b> 2015-08-03</p>
<p><b>View all other</b> <a href="lwg-index.html#support.dynamic">issues</a> in [support.dynamic].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::experimental::optional</tt>, for certain reasons, specifies its <tt>nullopt</tt> type
to not be <tt>DefaultConstructible</tt>. It doesn't do so for its tag type <tt>in_place_t</tt>
and neither does the standard proper for any of its tag types. That turns
out to be very unfortunate, consider the following:
</p>
<blockquote><pre>
#include &lt;memory&gt;
#include &lt;array&gt;

void f(std::array&lt;int, 1&gt;, int) {} // #1
void f(std::allocator_arg_t, int) {} // #2

int main()
{
  f({}, 666); // #3
}
</pre></blockquote>
<p>
The call at #3 is ambiguous. What's even worse is that if the overload #1
is removed, the call works just fine. The whole point of a tag type is that
it either needs to mentioned in a call or it needs to be a forwarded argument,
so being able to construct a tag type like that makes no sense.
<p/>
Making the types have an <em>explicit default constructor</em> might have helped, but 
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1518">CWG 1518</a>
is going against that idea.
<p/>
[optional.nullopt]/3 solves this problem for <tt>nullopt</tt>:
</p>
<blockquote>
<p>
Type <tt>nullopt_t</tt> shall not have a default constructor. It shall be a
literal type. Constant <tt>nullopt</tt> shall be initialized with an argument
of literal type.
</p>
</blockquote>

<p><i>[2015-06, Telecom]</i></p>

<p>
Move to Tentatively Ready.
</p>


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

<ol>
<li><p>In 18.6 [support.dynamic]/1, change the header <tt>&lt;new&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
struct nothrow_t <del>{}</del>; <ins><i>see below</i></ins>
extern const nothrow_t nothrow;
[&hellip;]
</pre></blockquote>
</li>
<li><p>Add a new paragraph after 18.6 [support.dynamic]/1 (<em>following</em> the header <tt>&lt;new&gt;</tt> synopsis):</p>

<blockquote>
<p>
<ins>-?- Type <tt>nothrow_t</tt> shall not have a default constructor.</ins>
</p>
</blockquote>
</li>
<li><p>In 20.2 [utility]/2, change the header <tt>&lt;utility&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
// <i>20.3.5, pair piecewise construction</i>
struct piecewise_construct_t <del>{ }</del>; <ins><i>see below</i></ins>
constexpr piecewise_construct_t piecewise_construct{ <ins><i>unspecified</i></ins> };
[&hellip;]
</pre></blockquote>
</li>
<li><p>Add a new paragraph after 20.2 [utility]/2 (<em>following</em> the header <tt>&lt;utility&gt;</tt> synopsis):</p>

<blockquote>
<p>
<ins>-?- Type <tt>piecewise_construct_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>piecewise_construct</tt> shall be initialized with an argument of literal type.</ins>
</p>
</blockquote>
</li>
<li><p>In 20.3.5 [pair.piecewise], apply the following edits:</p>

<blockquote><pre>
struct piecewise_construct_t <del>{ }</del>;
constexpr piecewise_construct_t piecewise_construct{ <ins><i>unspecified</i></ins> };
</pre></blockquote>
</li>
<li><p>In 20.7.2 [memory.syn]/1, change the header <tt>&lt;memory&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
// <i>20.7.6, allocator argument tag</i>
struct allocator_arg_t <del>{ }</del>; <ins><i>see below</i></ins>
constexpr allocator_arg_t allocator_arg{ <ins><i>unspecified</i></ins> };
[&hellip;]
</pre></blockquote>
</li>
<li><p>Add a new paragraph after 20.7.2 [memory.syn]/1 (<em>following</em> the header <tt>&lt;memory&gt;</tt> synopsis):</p>

<blockquote>
<p>
<ins>-?- Type <tt>allocator_arg_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>allocator_arg</tt> shall be initialized with an
argument of literal type.</ins>
</p>
</blockquote>
</li>
<li><p>In 20.7.6 [allocator.tag], apply the following edits:</p>

<blockquote><pre>
namespace std {
  struct allocator_arg_t <del>{ }</del>;
  constexpr allocator_arg_t allocator_arg{ <ins><i>unspecified</i></ins> };
}
</pre></blockquote>
<blockquote class="note">
<p>
Editorial drive-by: <tt>piecewise_construct_t</tt> is written, in 20.3.5 [pair.piecewise] like
</p>
<blockquote><pre>
struct piecewise_construct_t { };
constexpr piecewise_construct_t piecewise_construct{};
</pre></blockquote>
<p>
whereas other tag types such as <tt>allocator_construct_t</tt> are, in e.g.
20.7.6 [allocator.tag], written like
</p>
<blockquote><pre>
namespace std {
  struct allocator_arg_t { };
  constexpr allocator_arg_t allocator_arg{};
}
</pre></blockquote>
<p>
We should decide whether or not to write out the <tt>std</tt> namespace in such
paragraphs. I would suggest not to write it out.
</p>
</blockquote>

</li>
<li><p>In 30.4 [thread.mutex]/1, change the header <tt>&lt;mutex&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
struct defer_lock_t <del>{ }</del>; <ins><i>see below</i></ins>
struct try_to_lock_t <del>{ }</del>; <ins><i>see below</i></ins>
struct adopt_lock_t <del>{ }</del>; <ins><i>see below</i></ins>

constexpr defer_lock_t defer_lock { <ins><i>unspecified </i></ins> };
constexpr try_to_lock_t try_to_lock { <ins><i>unspecified </i></ins> };
constexpr adopt_lock_t adopt_lock { <ins><i>unspecified </i></ins> };
[&hellip;]
</pre></blockquote>
</li>
<li><p>Add three new paragraphs after [thread.mutex]/1 (<em>following</em> the header <tt>&lt;mutex&gt;</tt> synopsis):</p>

<blockquote>
<p>
<ins>-?- Type <tt>defer_lock_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>defer_lock</tt> shall be initialized with an
argument of literal type.</ins>
<p/>
<ins>-?- Type <tt>try_to_lock_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>try_to_lock</tt> shall be initialized with an
argument of literal type.</ins>
<p/>
<ins>-?- Type <tt>adopt_lock_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>adopt_lock</tt> shall be initialized with an
argument of literal type.</ins>
</p>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2515" href="#2515">2515.</a> [fund.ts.v2] Certain comparison operators of <tt>observer_ptr</tt> do not match synopsis</h3>
<p><b>Section:</b> X [memory.observer.ptr.special] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-07-07 <b>Last modified:</b> 2015-08-03</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html">N4529</a> 
[memory.observer.ptr.special] paragraphs 15, 17 and 19, the <tt>&gt;</tt>, <tt>&lt;=</tt> and 
<tt>&gt;=</tt> operators of <tt>observer_ptr</tt> are shown as
</p>
<blockquote><pre>
template &lt;class W&gt; 
bool operator>(observer_ptr&lt;W&gt; p1, observer_ptr&lt;W&gt; p2);
</pre></blockquote>
<p>
whereas in [header.memory.synop] they are shown as
</p>
<blockquote><pre>
template &lt;class W1, class W2&gt; 
bool operator>(observer_ptr&lt;W1&gt; p1, observer_ptr&lt;W2&gt; p2);
</pre></blockquote>
<p>
Given that the specification of <tt>operator&lt;</tt> took special care to support hetergeneous types, 
presumably the second version is intended.
</p>

<p><i>[2015-07, Telecom]</i></p>

<p>
Move to Tentatively Ready.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html">N4529</a>.
</p>

<ol>
<li><p>Edit X [memory.observer.ptr.special] as indicated:</p>

<blockquote>
<pre>-15- template &lt;class W<ins>1, class W2</ins>&gt;
bool operator&gt;(observer_ptr&lt;W<ins>1</ins>&gt; p1, observer_ptr&lt;W<ins>2</ins>&gt; p2);
</pre>
<blockquote><p>
[&hellip;]
</p></blockquote>
<pre>
-17- template &lt;class W<ins>1, class W2</ins>&gt;
bool operator&lt;=(observer_ptr&lt;W<ins>1</ins>&gt; p1, observer_ptr&lt;W<ins>2</ins>&gt; p2);
</pre>
<blockquote><p>
[&hellip;]
</p></blockquote>
<pre>
-19- template &lt;class W<ins>1, class W2</ins>&gt;
bool operator&gt;=(observer_ptr&lt;W<ins>1</ins>&gt; p1, observer_ptr&lt;W<ins>2</ins>&gt; p2);
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2517" href="#2517">2517.</a> [fund.ts.v2] Two <tt>propagate_const</tt> assignment operators have incorrect return type</h3>
<p><b>Section:</b> X [propagate_const.assignment] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-07-08 <b>Last modified:</b> 2015-08-03</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html">N4529</a> 
[propagate_const.assignment] depicts the two <tt>operator=</tt>s described as returning by value. 
This is obviously incorrect. The class synopsis correctly shows them as returning by reference.
</p>

<p><i>[2015-06, Telecom]</i></p>

<p>
Move to Tentatively Ready.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html">N4529</a>.
</p>

<ol>
<li><p>Edit [propagate_const.assignment] as indicated:</p>
<blockquote>
<pre>
-1- template &lt;class U&gt;
constexpr propagate_const<ins>&amp;</ins> operator=(propagate_const&lt;U&gt;&amp;&amp; pu)
</pre>
<blockquote>
<p>
[&hellip;]
</p>
</blockquote>
<pre>
-5- template &lt;class U&gt;
constexpr propagate_const<ins>&amp;</ins> operator=(U&amp;&amp; u)
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2526" href="#2526">2526.</a> [fund.ts] Incorrect precondition for <tt>experimental::function::swap</tt></h3>
<p><b>Section:</b> 20.9.12.2.2 [func.wrap.func.mod] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-08-04 <b>Last modified:</b> 2015-09-14</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.mod">issues</a> in [func.wrap.func.mod].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts</b></p>
<p>
20.9.12.2.2 [func.wrap.func.mod] says that the precondition of <tt>swap</tt> is
</p>
<blockquote><pre>
this-&gt;get_memory_resource() == other-&gt;get_memory_resource()
</pre></blockquote>
<p>
That compares two pointers and so requires the memory resource used by <tt>*this</tt> and <tt>other</tt> to be 
the exact same object. That doesn't seem correct (for one, it would essentially outlaw swapping all <tt>function</tt>s 
constructed with "plain" allocators, since they would each have their own <tt>resource_adaptor</tt> object 
and so the pointers will not compare equal). Presumably the intent is to compare the <tt>memory_resource</tt>s for equality.
</p>
<p>
Also, <tt>other</tt> is a reference, not a pointer.
</p>

<p><i>[2015-09-11, Telecom]</i></p>

<p>
Move to Tentatively Ready
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html">N4480</a>.
</p>

<ol>
<li><p>Edit 20.9.12.2.2 [func.wrap.func.mod] as indicated:</p>
<blockquote>
<pre>
void swap(function&amp; other);
</pre>
<blockquote>
<p>
-2- <i>Requires</i>: <tt><ins>*</ins>this-&gt;get_memory_resource() == <ins>*</ins>other<del>-&gt;</del><ins>.</ins>get_memory_resource()</tt>. 
<p/>
-3- <i>Effects</i>: Interchanges the targets of <tt>*this</tt> and <tt>other</tt>.
<p/>
-4- <i>Remarks</i>: The allocators of <tt>*this</tt> and <tt>other</tt> are not interchanged. 
</p>
</blockquote>
</blockquote>
</li>
</ol>





</body>
</html>
