<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta charset="utf-8">
<title>C++ Standard Library Issues to be moved in Jacksonville</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}
  table {border-collapse: collapse;}
</style>
</head>
<body>
<h1>C++ Standard Library Issues to be moved in Jacksonville</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P0165R1</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2016-02-12 at 23:02:13 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="2192" href="#2192">2192.</a> Validity and return type of <tt>std::abs(0u)</tt> is unclear</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-10-02 <b>Last modified:</b> 2015-11-04</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</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>
In C++03 the following two programs are invalid:
</p>
<ol style="list-style-type:upper-alpha"><li>
<blockquote><pre>
#include &lt;cmath&gt;

int main() {
  std::abs(0u);
}
</pre></blockquote>
</li>
<li>
<blockquote><pre>
#include &lt;cstdlib&gt;

int main() {
  std::abs(0u);
}
</pre></blockquote>
</li>
</ol>
<p>
because none of the <tt>std::abs()</tt> overloads is a best match.
</p>
<p>
In C++11 the additional "sufficient overload" rule from 26.8 [c.math] p11 (see also LWG
<a href="lwg-defects.html#2086">2086</a>) can be read to be applicable to the <tt>std::abs()</tt> overloads as well, which
can lead to the following possible conclusions:
<p/>
<ol>
<li><p>The program</p>
<blockquote><pre>
#include &lt;type_traits&gt;
#include &lt;cmath&gt;

static_assert(std::is_same&lt;decltype(std::abs(0u)), double&gt;(), "Oops");

int main() {
  std::abs(0u); // Calls std::abs(double)
}
</pre></blockquote>
<p>
is required to be well-formed, because of sub-bullet 2 ("[..] or an integer type [..]") of 
26.8 [c.math] p11 (Note that the current resolution of LWG <a href="lwg-defects.html#2086">2086</a> doesn't
fix this problem).
</p>
</li>
<li><p>Any translation unit including both <tt>&lt;cmath&gt;</tt> and <tt>&lt;cstdlib&gt;</tt>
might be ill-formed because of two conflicting requirements for the return type of the overload
<tt>std::abs(int)</tt>.
</p>
</li>
</ol>
</p>

<p>
It seems to me that at least the second outcome is not intended, personally I think that both
are unfortunate: In contrast to all other floating-point functions explicitly listed in sub-clause 
26.8 [c.math], the <tt>abs</tt> overloads have a special and well-defined meaning for 
signed integers and thus have explicit overloads returning a signed integral type. I also believe that 
there is no problem accepting that <tt>std::fabs(0u)</tt> is well-defined with return type <tt>double</tt>, 
because the leading 'f' clearly signals that we have a floating point function here. But the expected 
return type of <tt>std::abs(0u)</tt> seems less than clear to me. A very reasonable answer could be that 
this has the same type as its argument type, alternatively it could be a reasonably chosen signed 
integer type, or a floating point type. It should also be noted, that the corresponding
"generic type function" rule set from C99/C1x in 7.25 p2+3 is restricted to the floating-point functions
from <tt>&lt;math.h&gt;</tt> and <tt>&lt;complex.h&gt;</tt>, so cannot be applied to the <tt>abs</tt>
functions (but to the <tt>fabs</tt> functions!).
<p/>
Selecting a signed integer return type for unsigned input values can also problematic: The directly
corresponding signed integer type would give half of the possible argument values an implementation-defined
result value. Choosing the first signed integer value that can represent all positive values would solve this
problem for <tt>unsigned int</tt>, but there would be no clear answer for the input type <tt>std::uintmax_t</tt>.
</p>
<p>
Based on this it seems to me that the C++03 state in regard to unsigned integer values was the better
situation, alerting the user that this code is ambigious at the moment (This might be change with different core-language
rules as described in N3387).
</p>

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


<p>
Resolution: leave as new and bring it back in Chicago. 
</p>

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

<p>
This issue also relates to LWG <a href="lwg-active.html#2294">2294</a>
<p/> 
STL: these two issues should be bundled 
<p/>
Stefanus: do what Pete says, and add overloads for unsigned to return directly 
<p/>
STL: agree Consensus that this is an issue 
<p/>
Walter: motion to move to Open 
<p/>
STL: no wording for <a href="lwg-active.html#2294">2294</a> 
<p/>
Stefanus: move to open and note the 2 issues are related and should be moved together 
<p/>
Stefanus: add and define unsigned versions of <tt>abs()</tt>
</p>

<p><i>[2014-02-03 Howard comments]</i></p>

<p>
Defining <tt>abs()</tt> for unsigned integers is a bad idea. Doing so would turn compile time errors into run time errors, 
especially in C++ where we have templates, and the types involved are not always apparent to the programmer at design time.  
For example, consider:
</p>
<blockquote><pre>
template &lt;class Int&gt;
Int
analyze(Int x, Int y)
{
  // ...
  if (std::abs(<span style="color:#C80000;font-weight:bolder">x - y</span>) &lt; threshold)
  {
    // ...
  }
  // ...
}
</pre></blockquote>
<p>
<tt>std::abs(<i>expr</i>)</tt> is often used to ask: Are these two numbers sufficiently close?  When the assumption is that 
the two numbers are signed (either signed integral, or floating point), the logic is sound. But when the same logic is 
accidentally used with an arithmetic type not capable of representing negative numbers, and especially if unsigned overflow 
will silently happen, then the logic is no longer correct:
</p>
<blockquote><pre>
auto i = analyze(20u, 21u);  // Today a compile time error
    // But with <tt>abs(unsigned)</tt> becomes a run time error
</pre></blockquote>
<p>
This is not idle speculation. Search the net for "<tt>abs unsigned</tt>" 
<a href="http://www.avrfreaks.net/index.php?name=PNphpBB2&amp;file=printview&amp;t=35514&amp;start=0">here</a> or 
<a href="http://fischerlaender.de/mysql/surprising-mysql-behaviour-using-unsigned-int">here</a>.
<p/>
In C++11, <tt>chrono</tt> <tt>duration</tt>s and <tt>time_point</tt>s are allowed to be based on unsigned integers. Taking the 
absolute value of the difference of two such <tt>time_point</tt>s would be easy to accidentally do (say in code templated on 
<tt>time_point</tt>s), and would certainly be a logic bug, caught at compile time unless we provide the error prone <tt>abs(unsigned)</tt>.
</p>

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

<p>
GR: Do we want to make the changes to both <tt>&lt;cmath&gt;</tt> and <tt>&lt;cstdlib&gt;</tt>?<br/> 
AM: I think so; we should provide consistent overloads.<br/> 
GR: Then we're imposing restrictions on what users put in the global namespace.<br/> 
AM: I'm not so worried about that. Users already know not to use C library names.<br/>
VV: So what are we going to do about unsigned integers? AM: We will say that they are ill-formed.<br/>
AM: Does anyone volunteer to send updated wording to Daniel? GR, can you do it? GR: Sure.<br/>
GR: To clarify: we want to make unsigned types ill-formed?<br/> 
AM: With promotion rank at least <tt>unsigned int</tt>.<br/>
GR: And NL suggests to just list those types.
<p/>
Conclusion: Merge the resolution into a single issue. 
</p>

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

<ol>
<li><p>Change 26.8 [c.math] p11 as indicated:</p>
<blockquote><p>
-11- Moreover<ins>, except for the <tt>abs</tt> functions</ins>, there shall be additional overloads sufficient to ensure:
<p/>
[&hellip;]
</p></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-03-03, Geoffrey Romer provides improved wording]</i></p>

<p>
In the following I've drafted combined wording to resolve LWG <a href="lwg-active.html#2192">2192</a> and <a href="lwg-active.html#2294">2294</a>. Note that the first 
two paragraphs are taken verbatim from the P/R of LWG <a href="lwg-active.html#2294">2294</a>, but the third is newly drafted:
</p>

<p><i>[2015-05-05 Lenexa: Howard to draft updated wording]</i></p>


<p><i>[2015-09-11: Howard updated wording]</i></p>


<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>HH: abs() for unsigned types is really dangerous. People often use abs(x - y), which would be a disaster. </p>
<p>TK: That's why you need a two-argument abs_diff(x, y), especially for unsigned types. </p>
<p>JW: Lawrence has a proposal for abs_diff in the mailing.</p>
<p>STL: As an alternative to considering promotions, I would just ban all unsigned types, even unsigned char.</p>
<p>STL: Does the PR change any implementation? Is the final paragraph just a consequence? </p><p>HH: It's a consequence. It could just be a note. </p><p>VV: Ship it as is.</p>
<p>STL: Editorial: capitalize the first letter in the Note.</p>
<p>Move to Tentatively ready.</p>



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

<ol>
<li><p>Insert the following new paragraphs after 26.8 [c.math] p7:</p>
<blockquote>
<p>
-6- In addition to the <tt>int</tt> versions of certain math functions in <tt>&lt;cstdlib&gt;</tt>, C++ adds <tt>long</tt> 
and <tt>long long</tt> overloaded versions of these functions, with the same semantics.
<p/>
-7- The added signatures are:
</p>
<blockquote>
<pre>
long abs(long); <i>// labs()</i>
long long abs(long long); <i>// llabs()</i>
ldiv_t div(long, long); <i>// ldiv()</i>
lldiv_t div(long long, long long); <i>// lldiv()</i>
</pre>
</blockquote>
<p>
<ins>-?- To avoid ambiguities, C++ also adds the following overloads of <tt>abs()</tt> to <tt>&lt;cstdlib&gt;</tt>, 
with the semantics defined in <tt>&lt;cmath&gt;</tt>:</ins>
</p>
<blockquote>
<pre>
<ins>float abs(float);
double abs(double);
long double abs(long double);</ins>
</pre>
</blockquote>
<p>
<ins>-?- To avoid ambiguities, C++ also adds the following overloads of <tt>abs()</tt> to <tt>&lt;cmath&gt;</tt>, 
with the semantics defined in <tt>&lt;cstdlib&gt;</tt>:</ins>
</p>
<blockquote>
<pre>
<ins>int abs(int);
long abs(long);
long long abs(long long);</ins>
</pre>
</blockquote>
<p>
<ins>-?- If <tt>abs()</tt> is called with an argument of type <tt>X</tt> for which
<tt>is_unsigned&lt;X&gt;::value</tt> is <tt>true</tt> and if <tt>X</tt> cannot be converted to
<tt>int</tt> by integral promotion (4.5 [conv.prom]), the program is ill-formed.
[<i>Note</i>: arguments that can be promoted to <tt>int</tt> are permitted for
compatibility with C. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2253" href="#2253">2253.</a> [arrays.ts] <tt>dynarray</tt> should state which container requirements aren't met</h3>
<p><b>Section:</b> 99 [arrays.ts::dynarray.overview] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-04-23 <b>Last modified:</b> 2016-02-12</p>
<p><b>Priority: </b>0
</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: arrays.ts</b></p>

<p>
99 [dynarray.overview] p2 says:
</p>
<blockquote>
<p>
"Unless otherwise specified, all <tt>dynarray</tt> operations have the same requirements and semantics as specified in
99 [container.requirements]."
</p>
</blockquote>
<p>
Some differences from 99 [container.requirements] are not explicitly specified, including at
least the lack of a default constructor, copy assignment and <tt>swap</tt> member.
<p/>
The wording could be similar to 23.3.7.1 [array.overview] which says "An array satisfies all of the requirements 
of a container and of a reversible container (99 [container.requirements]), except that a default constructed 
array object is not empty and that <tt>swap</tt> does not have constant complexity."
</p>

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

<p>
Move to Deferred. This feature will ship after C++14 and should be revisited then.
</p>

<p><i>[2014-06-06 pre-Rapperswil]</i></p>

<p>
This issue has been reopened as arrays-ts.
</p>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready
</p>

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

<p>
Held at Ready status, pending clarification of Arrays TS
</p>



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

<ol>
<li><p>Add to 99 [dynarray.overview] p2:</p>
<p>
-2- <ins>A <tt>dynarray</tt> satisfies all of the requirements of a container and of a reversible container 
(99 [container.requirements]), except for default construction, assignment and <tt>swap</tt>.</ins> Unless 
otherwise specified, all <tt>dynarray</tt> operations have the same requirements and semantics as specified in 
99 [container.requirements].
</p>
</li>
</ol>






<hr>
<h3><a name="2255" href="#2255">2255.</a> [arrays.ts] <tt>dynarray</tt> constructor ambiguity</h3>
<p><b>Section:</b> 99 [arrays.ts::dynarray.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-04-23 <b>Last modified:</b> 2016-02-12</p>
<p><b>Priority: </b>0
</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: arrays.ts</b></p>

<p>
These constructors can interact badly::
</p>
<blockquote><pre>
template&lt;class Alloc&gt;
  dynarray(size_type c, const Alloc&amp; alloc);
dynarray(size_type c, const T&amp; v);
</pre></blockquote>
<p>
Unless the second argument is a value of exactly the type <tt>T</tt> you will get the first constructor, i.e. 
all of these will fail to compile:
</p>
<blockquote><pre>
dynarray&lt;long&gt; dlong(1, 1);   // 1 is not long
dynarray&lt;float&gt; dflt(1, 1.0);  // 1.0 is not float
dynarray&lt;int*&gt; dptr(1, nullptr);  // nullptr is not int*
dynarray&lt;void*&gt; doh(1, 0);  // 0 is not void*
</pre></blockquote>
<p>
The <tt>nullptr</tt> case is particularly annoying, a user trying to do the right thing by saying <tt>nullptr</tt> 
instead of <tt>NULL</tt> still gets the wrong result.
<p/>
The constructor taking an allocator requires that "<tt>Alloc</tt> shall meet the requirements for an Allocator" 
but doesn't actually say "shall not participate in overload resolution unless ..."
<p/>
I believe we have no precedent for using SFINAE to check "the requirements for an Allocator" because it's 
a pretty complicated set of requirements. We could say it shall not participate in overload resolution if <tt>Alloc</tt> 
is implicitly convertible to <tt>value_type</tt>.
<p/>
Alternatively, we could follow the same approach used by other types that can be constructed with an unconstrained 
allocator type and use <tt>std::allocator_arg_t</tt> as the first argument instead of adding an allocator after the 
other arguments.
</p>

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

<p>
Move to Deferred. This feature will ship after C++14 and should be revisited then.
</p>

<p><i>[2014-06-06 pre-Rapperswil]</i></p>

<p>
This issue has been reopened as arrays-ts.
</p>

<p><i>[2014-06-16 Rapperswil]</i></p>

<p>
Move to Ready for alternative A
</p>

<strong>Previous resolution [SUPERSEDED]:</strong>
<p/>
<blockquote class="note"> 
<ol style="list-style-type:upper-alpha">
<li>
<p>
<em>Either</em> use the correct way to unambiguously call a constructor taking any type of allocator, i.e. change the 
constructors to take <tt>dynarray(std::allocator_arg_t, const Alloc&amp;, ...)</tt> by modifying both the synopsis
99 [dynarray.overview] p2 and 99 [dynarray.cons] before p9 like so:</p>

<blockquote><pre>
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>size_type c<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>size_type c, const T&amp; v<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>const dynarray&amp; d<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>initializer_list&lt;T&gt;<del>, const Alloc&amp; alloc</del>);
</pre></blockquote>

</li>

<li><p><em>or</em> constrain the problematic constructor by adding a new paragraph to 99 [dynarray.cons]:</p>
<blockquote><pre>
template &lt;class Alloc&gt;
  dynarray(size_type c, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
  dynarray(size_type c, const T&amp; v, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
  dynarray(const dynarray&amp; d, const Alloc&amp; alloc);
template &lt;class Alloc&gt;
  dynarray(initializer_list&lt;T&gt;, const Alloc&amp; alloc);
</pre><blockquote>
<p>
-9- <i>Requires</i>: <tt>Alloc</tt> shall meet the requirements for an Allocator (17.6.3.5 [allocator.requirements]).
<p/>
-10- <i>Effects</i>: Equivalent to the preceding constructors except that each element is constructed with uses-allocator
construction (20.7.7.2 [allocator.uses.construction]).
<p/>
<ins>-?- <i>Remarks</i>: The first constructor shall not participate in overload resolution unless <tt>Alloc</tt> is not 
implicitly convertible to <tt>T</tt>.</ins>
</p>
</blockquote></blockquote>
</li>
</ol>
</blockquote>

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

<p>
Held at Ready status, pending clarification of Arrays TS
</p>



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

<ol>
<li>
<p>
Use the correct way to unambiguously call a constructor taking any type of allocator, i.e. change the 
constructors to take <tt>dynarray(std::allocator_arg_t, const Alloc&amp;, ...)</tt> by modifying both the synopsis
99 [dynarray.overview] p2 and 99 [dynarray.cons] before p9 like so:</p>

<blockquote><pre>
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>size_type c<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>size_type c, const T&amp; v<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>const dynarray&amp; d<del>, const Alloc&amp; alloc</del>);
template &lt;class Alloc&gt;
  dynarray(<ins>allocator_arg_t, const Alloc&amp; a, </ins>initializer_list&lt;T&gt;<del>, const Alloc&amp; alloc</del>);
</pre></blockquote>

</li>
</ol>






<hr>
<h3><a name="2276" href="#2276">2276.</a> Missing requirement on <tt>std::promise::set_exception</tt></h3>
<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-07-30 <b>Last modified:</b> 2016-02-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#futures">issues</a> in [futures].</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 does not specify the behaviour of this program:
</p>

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

struct NonTrivial
{
  NonTrivial() : init(true) { }
  ~NonTrivial() { assert(init); }
  bool init;
};

int main()
{
  std::promise&lt;NonTrivial&gt; p;
  auto f = p.get_future();
  p.set_exception(std::exception_ptr());
  f.get();
}
</pre></blockquote>

<p>
The standard doesn't forbid making the state ready with a null
<tt>exception_ptr</tt>, so what should <tt>get()</tt> return?  There's no stored
exception to throw, but it can't return a value because none was initialized.
<p/>
A careful reading of the standard shows 30.6.4 [futures.state] p8 says
"A shared state is <em>ready</em> only if it holds a value or an exception
ready for retrieval." One can infer from the fact that <tt>set_exception()</tt>
makes the state ready that it must store a value or exception, so
cannot store "nothing", but that isn't explicit.
<p/>
The <tt>promise::set_exception()</tt> and <tt>promise::set_exception_at_thread_exit()</tt> 
members should require <tt>p != nullptr</tt> or should state the type of exception thrown 
if <tt>p</tt> is null.
</p>

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

<p>Handed over to SG1.</p>

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

<p>SG1 provides P/R and requests move to SG1-OK status: Add Requires clauses for promise (30.6.5 [futures.promise]) set_exception (before p18) and set_exception_at_thread_exit (before p24): Requires: p is not null.</p>

<p><i>[2015-10, Kona issue prioritization]</i></p>

<p>Priority 0, move to Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4431.
</p>
Add Requires clauses for promise (30.6.5 [futures.promise]) <tt>set_exception</tt> (before p18) and 
<tt>set_exception_at_thread_exit</tt> (before p24): <i>Requires</i>: <tt>p</tt> is not null.

<ol>
<li><p>Change 30.6.5 [futures.promise] as depicted:</p>

<blockquote>
<pre>
void set_exception(exception_ptr p);
</pre>
<blockquote>
<p>
<ins>-??- <i>Requires:</i> <tt>p</tt> is not null. </ins>
</p>
<p>
-18- <i>Effects:</i> atomically stores the exception pointer <tt>p</tt> in the shared state and makes that state ready (30.6.4).
</p>
</blockquote>
</blockquote>

<blockquote>
<pre>
void set_exception_at_thread_exit(exception_ptr p);
</pre>
<blockquote>
<p>
<ins>-??- <i>Requires:</i> <tt>p</tt> is not null. </ins>
</p>
<p>
-24- <i>Effects:</i> Stores the exception pointer <tt>p</tt> in the shared state without making that state ready immediately. [&hellip;]
</p>
</blockquote>
</blockquote>
</li></ol>






<hr>
<h3><a name="2450" href="#2450">2450.</a> <tt>(greater|less|greater_equal|less_equal)&lt;void&gt;</tt> do not yield a total order for pointers</h3>
<p><b>Section:</b> 20.9.6 [comparisons] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Joaqu&iacute;n M L&oacute;pez Mu&ntilde;oz <b>Opened:</b> 2014-10-30 <b>Last modified:</b> 2015-11-04</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#comparisons">active issues</a> in [comparisons].</p>
<p><b>View all other</b> <a href="lwg-index.html#comparisons">issues</a> in [comparisons].</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>less&lt;void&gt;::operator(t, u)</tt> (and the same applies to the rest of <tt>void</tt> specializations for standard 
comparison function objects) returns <tt>t &lt; u</tt> even if <tt>t</tt> and <tt>u</tt> are pointers, which by 
5.9 [expr.rel]/3 is undefined except if both pointers point to the same array or object. This might be 
regarded as a specification defect since the intention of N3421 is that <tt>less&lt;&gt;</tt> can substitute for 
<tt>less&lt;T&gt;</tt> in any case where the latter is applicable. <tt>less&lt;void&gt;</tt> can be rewritten in 
the following manner to cope with pointers:
</p>
<blockquote><pre>
template&lt;&gt; struct less&lt;void&gt;
{

  typedef <i>unspecified</i> is_transparent;

  template &lt;class T, class U&gt;
  struct pointer_overload : std::is_pointer&lt;std::common_type_t&lt;T, U&gt;&gt;
  {};

  template &lt;
    class T, class U,
    typename std::enable_if&lt;!pointer_overload&lt;T, U&gt;::value&gt;::type* = nullptr
  &gt;
  auto operator()(T&amp;&amp; t, U&amp;&amp; u) const
    -&gt; decltype(std::forward&lt;T&gt;(t) &lt; std::forward&lt;U&gt;(u))
  {
    return std::forward&lt;T&gt;(t) &lt; std::forward&lt;U&gt;(u);
  } 

  template &lt;
    class T, class U,
    typename std::enable_if&lt;pointer_overload&lt;T, U>::value>::type* = nullptr
  &gt;
  auto operator()(T&amp;&amp; t, U&amp;&amp; u) const
    -&gt; decltype(std::declval&lt;std::less&lt;std::common_type_t&lt;T, U&gt;&gt;&gt;()(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u)))
  {
    std::less&lt;std::common_type_t&lt;T, U&gt;&gt; l;
    return l(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u));
  }

};
</pre></blockquote>

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

<ol>
<li><p>Change 20.9.6 [comparisons] p14 as indicated:</p>
<blockquote><p>
-14- For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the specializations 
for any pointer type yield a total order, even if the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, 
<tt>&gt;=</tt> do not. <ins>For template specializations <tt>greater&lt;void&gt;</tt>, <tt>less&lt;void&gt;</tt>, 
<tt>greater_equal&lt;void&gt;</tt>, and <tt>less_equal&lt;void&gt;</tt>, the call operator with arguments whose common 
type <tt><i>CT</i></tt> is a pointer yields the same value as the corresponding comparison function object class 
specialization for <tt><i>CT</i></tt>.</ins>
</p></blockquote>
</li>
</ol>
</blockquote>

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

<p>
AM: Is there any way this will be resolved elsewhere? VV: No. AM: Then we should bite the bullet and deal with it here.
<p/>
MC: These diamond operators are already ugly. Making them more ugly isn't a big problem.
<p/>
JY found some issue with types that are convertible, and will reword. 
<p/>
Jeffrey suggests improved wording.
</p>

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

<p>
STL: when diamond functions designed, this was on purpose<br/>
STL: this does go against the original design<br/>
STL: library is smarter and can give a total order<br/>
MC: given that the original design rejected this, give back to LEWG<br/>
STL: original proposal did not talk about total order<br/>
STL: don't feel strongly about changing the design<br/>
STL: no objections to taking this issue with some wording changes if people want it<br/>
MC: not happy with wording, comparing pointers &mdash; what does that mean?<br/>
STL: needs careful attention to wording<br/>
STL: want to guarantee that <tt>nullptr</tt> participates in total ordering<br/>
STL: all hooks into composite pointer type<br/>
MC: move from new to open with better wording<br/>
STL: to check updates to issue after Lenexa 
</p>

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

<p>
MC: STL on the hook to update. He's shipping something today so not here.<br/>
MC: also add link to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4229.pdf">N4229</a><br/>
</p>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>
STL was on the hook for wording, but STL: I don't care. The architecture on which this is an issue does not exist.<br/>
STL: We will also need to incorporate nullptr. TK: I think that's implied, since the wording is in terms of the resulting operation, not the deduced types. <br/>
STL: Seems legit. MC: I guess I'm OK with this. TK: I'm weakly in favour, so that we can get people to use transparent comparators without worrying. <br/>
STL: There's no change to implementations.<br/>
Move to Tentatively ready.
</p>


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

<ol>
<li><p>Change 20.9.6 [comparisons] p14 as indicated:</p>
<blockquote><p>
-14- For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the specializations 
for any pointer type yield a total order, even if the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, 
<tt>&gt;=</tt> do not. <ins>For template specializations <tt>greater&lt;void&gt;</tt>, <tt>less&lt;void&gt;</tt>, 
<tt>greater_equal&lt;void&gt;</tt>, and <tt>less_equal&lt;void&gt;</tt>, if the call operator calls a built-in operator 
comparing pointers, the call operator yields a total order.</ins>
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2520" href="#2520">2520.</a> N4089 broke initializing <tt>unique_ptr&lt;T[]&gt;</tt> from a <tt>nullptr</tt></h3>
<p><b>Section:</b> 20.8.1.3.1 [unique.ptr.runtime.ctor] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2015-07-19 <b>Last modified:</b> 2015-11-04</p>
<p><b>Priority: </b>2
</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>
According to the wording in 20.8.1.3.1 [unique.ptr.runtime.ctor]/1,
this won't work:
</p>
<blockquote><pre>
unique_ptr&lt;int[], DeleterType&gt; x{nullptr, DeleterType{}};
</pre></blockquote>
<p>
<tt>U</tt> is not the same type as <tt>pointer</tt>, so the first bullet will not do.<br/>
<tt>U</tt> is not a pointer type, so the second bullet will not do.
<p/>
An easy fix would be to add a new bullet after the first bullet, like so:
</p>
<ul>
<li><p><tt>U</tt> is the same type as <tt>pointer</tt>, or</p></li>
<li><p><ins><tt>U</tt> is <tt>nullptr_t</tt>, or</ins></p></li>
<li><p><tt>pointer</tt> is the same type as <tt>element_type*</tt>, [&hellip;]</p></li>
</ul>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>MC: Is it the right fix? </p>
<p>GR: It'd be awefully surprising if we had an interface that accepts null pointer values but not std::nullptr_t. I think the PR is good.</p>
<p>STL: Are any of the assignments and reset affected? [No, they don't operate on explicit {pointer, deleter} pairs.]</p>
<p>VV: This is already shipping, has been implemented, has been tested and works fine.</p>
<p>Move to Tentatively ready.</p>


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

<ol>
<li><p>Change 20.8.1.3.1 [unique.ptr.runtime.ctor] as indicated:</p>
<blockquote>
<pre>
template &lt;class U&gt; explicit unique_ptr(U p) noexcept;
template &lt;class U&gt; unique_ptr(U p, <i>see below</i> d) noexcept;
template &lt;class U&gt; unique_ptr(U p, <i>see below</i> d) noexcept;
</pre>
<blockquote>
<p>
-1- These constructors behave the same as the constructors that take a <tt>pointer</tt> parameter in the primary
template except that they shall not participate in overload resolution unless either
</p>
<ul>
<li><p><tt>U</tt> is the same type as <tt>pointer</tt>, or</p></li>
<li><p><ins><tt>U</tt> is <tt>nullptr_t</tt>, or</ins></p></li>
<li><p><tt>pointer</tt> is the same type as <tt>element_type*</tt>, <tt>U</tt> is a pointer type <tt>V*</tt>, and 
<tt>V(*)[]</tt> is convertible to <tt>element_type(*)[]</tt>.</p></li>
</ul>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2522" href="#2522">2522.</a> [fund.ts.v2] Contradiction in <tt>set_default_resource</tt> specification</h3>
<p><b>Section:</b> 99 [fund.ts.v2::memory.resource.global] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-07-28 <b>Last modified:</b> 2015-11-04</p>
<p><b>Priority: </b>2
</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>
[memory.resource.global]/p7-8 says that the effects of <tt>set_default_resource(r)</tt> are
</p>
<blockquote><p>
If <tt>r</tt> is non-null, sets the value of the default memory resource pointer to <tt>r</tt>, otherwise sets the default memory 
resource pointer to <tt>new_delete_resource()</tt>.
</p></blockquote>
<p>
and the operation has the postcondition 
</p>
<blockquote><p>
<tt>get_default_resource() == r</tt>.
</p></blockquote>
<p>
When <tt>r</tt> is null, however, the postcondition cannot be met, since the call sets the default memory resource pointer to 
<tt>new_delete_resource()</tt>, and so <tt>get_default_resource()</tt> would return the value of <tt>new_delete_resource()</tt>, which 
is obviously not null and so cannot compare equal to <tt>r</tt>.
</p>

<strong>Previous resolution from Tim Song [SUPERSEDED]:</strong>
<blockquote class = "note">
<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 [memory.resource.global]/p8 as follows:</p>
<blockquote>
<pre>
<em>-6-</em> memory_resource* set_default_resource(memory_resource* r) noexcept;
</pre>
<blockquote>
<p>
-7- <i>Effects</i>: If <tt>r</tt> is non-null, sets the value of the default memory resource pointer to <tt>r</tt>, 
otherwise sets the default memory resource pointer to <tt>new_delete_resource()</tt>. 
<p/>
-8- <i>Postconditions</i>: <tt>get_default_resource() == r</tt> <ins>if <tt>r</tt> is non-null; otherwise, 
<tt>get_default_resource() == new_delete_resource()</tt></ins>. 
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-09-15 Geoffrey Romer comments and suggests alternative wording]</i></p>

<p>
 Let's just strike 99 [memory.resource.global]/p8. The problem is that p8 is restating p7 incorrectly, 
 but the solution is not to restate p7 correctly, it's to stop trying to restate p7 at all.
</p>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>Move to Tentatively ready</p>

<p><i>[2015-10-26]</i></p>

<p>Daniel adjusts wording to lib. fund. v2.</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 [memory.resource.global]/p8 as follows:</p>
<blockquote>
<pre>
<em>-6-</em> memory_resource* set_default_resource(memory_resource* r) noexcept;
</pre>
<blockquote>
<p>
-7- <i>Effects</i>: If <tt>r</tt> is non-null, sets the value of the default memory resource pointer to <tt>r</tt>, 
otherwise sets the default memory resource pointer to <tt>new_delete_resource()</tt>. 
<p/>
<del>-8- <i>Postconditions</i>: <tt>get_default_resource() == r</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2523" href="#2523">2523.</a> <tt>std::promise</tt> synopsis shows two <tt>set_value_at_thread_exit()</tt>'s for no apparent reason</h3>
<p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-07-31 <b>Last modified:</b> 2015-11-04</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.promise">issues</a> in [futures.promise].</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 30.6.5 [futures.promise], the class synopsis shows
</p>
<blockquote><pre>
void set_value_at_thread_exit(const R&amp; r);
void set_value_at_thread_exit(<i>see below</i>);
</pre></blockquote>
<p>
There's no apparent reason for having <tt>void set_value_at_thread_exit(const R&amp; r);</tt>, especially as that 
signature isn't really present in the specializations (particularly <tt>promise&lt;void&gt;</tt>). Note that the similar 
<tt>set_value</tt> only has a <tt>void set_value(<i>see below</i>);</tt>
</p>
<p>
While we are here, 30.6.5 [futures.promise]/p1 says that the specializations "differ only in the argument type of the 
member function <tt>set_value</tt>", which missed <tt>set_value_at_thread_exit</tt>.
</p>

<p><i>[2015-10, Kona issue prioritization]</i></p>

<p>Priority 0, move to Ready</p>


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

<ol>
<li><p>Edit 30.6.5 [futures.promise], class template <tt>promise</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
  template &lt;class R&gt;
  class promise {
  public:
    [&hellip;]

    <i>// setting the result</i>
    void set_value(<i>see below</i>);
    void set_exception(exception_ptr p);
    
    <i>// setting the result with deferred notification</i>
    <del>void set_value_at_thread_exit(const R&amp; r);</del>
    void set_value_at_thread_exit(<i>see below</i>);
    void set_exception_at_thread_exit(exception_ptr p);
  };
}
</pre>
</blockquote>
</li>

<li><p>Edit 30.6.5 [futures.promise]/1 as indicated:</p>
<blockquote>
<p>
-1- The implementation shall provide the template <tt>promise</tt> and two specializations, <tt>promise&lt;R&amp;&gt;</tt> and 
<tt>promise&lt;void&gt;</tt>. These differ only in the argument type of the member function<ins>s</ins> <tt>set_value</tt>
<ins>and <tt>set_value_at_thread_exit</tt></ins>, as set out in <del>its description</del><ins>their descriptions</ins>, below.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2537" href="#2537">2537.</a> Constructors for <code>priority_queue</code> taking allocators should call <code>make_heap</code></h3>
<p><b>Section:</b> 23.6.5.2 [priqueue.cons.alloc] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Eric Schmidt <b>Opened:</b> 2015-09-19 <b>Last modified:</b> 2015-11-04</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<code>priority_queue</code> constructors taking both <code>Container</code> and <code>Alloc</code> arguments should 
finish by calling <code>make_heap</code>, just as with the constructors that do not have allocator parameters.
<p/>
The current reading of 23.6.5.2 [priqueue.cons.alloc], if followed strictly, would effectively require calling 
code to ensure that the container argument is already a heap, which is probably not what was intended.
</p>

<p><i>[2015-10, Kona issue prioritization]</i></p>

<p>Priority 0, move to Ready</p>


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

<ol>
<li><p>Change 23.6.5.2 [priqueue.cons.alloc] as indicated:</p>
<blockquote>
<pre>
template &lt;class Alloc&gt;
priority_queue(const Compare&amp; compare, const Container&amp; cont, const Alloc&amp; a);
</pre>
<blockquote>
<p>
-4- <i>Effects</i>: Initializes <tt>c</tt> with <tt>cont</tt> as the first argument and <tt>a</tt> as the second 
argument, and initializes <tt>comp</tt> with <tt>compare</tt><ins>; calls <code>make_heap(c.begin(), c.end(), comp)</code></ins>.
</p>
</blockquote>
<pre>
template &lt;class Alloc&gt;
priority_queue(const Compare&amp; compare, Container&amp;&amp; cont, const Alloc&amp; a);
</pre>
<blockquote>
<p>
-5- <i>Effects</i>: Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as the first argument and <tt>a</tt> as the second 
argument, and initializes <tt>comp</tt> with <tt>compare</tt><ins>; calls <code>make_heap(c.begin(), c.end(), comp)</code></ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2539" href="#2539">2539.</a> [fund.ts.v2] <tt>invocation_trait</tt> definition definition doesn't work for surrogate call functions</h3>
<p><b>Section:</b> 99 [fund.ts.v2::meta.trans.other] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2015-09-25 <b>Last modified:</b> 2015-11-04</p>
<p><b>Priority: </b>Not Prioritized
</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 Library Fundamentals 2 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html">N4529</a>) 
3.3.2p3 [meta.trans.other], the definition of invocation traits for a class object <tt>f</tt> considers when <tt>f</tt> 
is called via a function call operator that is matched by the arguments but ignores the possibility that <tt>f</tt> 
may be called via a surrogate call function (C++14 13.3.1.1.2 [over.call.object] p2), in which case, the definition 
of the invocation parameters may be either incorrect or even unsatisfiable.
</p>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>AM: Do we have this trait yet? JW: No, it cannot be implemented without compiler support.</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>In Library Fundamentals 2, change [meta.trans.other] as indicated:</p>
<blockquote>
<p>
-3- Within this section, define the <i>invocation parameters</i> of <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows, 
in which <tt>T1</tt> is the possibly <i>cv</i>-qualified type of <tt>t1</tt> and <tt>U1</tt> denotes <tt>T1&amp;</tt> if 
<tt>t1</tt> is an lvalue or <tt>T1&amp;&amp;</tt> if <tt>t1</tt> is an rvalue: 
</p>
<ul>
<li><p>[&hellip;]</p></li>
<li><p>If <tt>f</tt> is a class object, the <i>invocation parameters</i> are the parameters matching <tt>t1, ..., tN</tt> 
of the best viable function (C++14 &sect;13.3.3) for the arguments <tt>t1, ..., tN</tt> among the function call operators 
<ins>and surrogate call functions</ins> of <tt>f</tt>. </p></li>
<li><p>[&hellip;]</p></li>
</ul>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2545" href="#2545">2545.</a> Simplify wording for <tt>bind</tt> without explicitly specified return type</h3>
<p><b>Section:</b> 20.9.10.3 [func.bind.bind] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2015-10-05 <b>Last modified:</b> 2016-01-04</p>
<p><b>Priority: </b>3
</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specification of the <tt>bind</tt> overload without return type as of 20.9.10.3 [func.bind.bind] p3, 
uses the following expression <tt><i>INVOKE</i>(fd, std::forward&lt;V1&gt;(v1), std::forward&lt;V2&gt;(v2), ..., 
std::forward&lt;VN&gt;(vN), result_of_t&lt;FD <i>cv</i> &amp; (V1, V2, ..., VN)&gt;)</tt> to describe effects of 
invocation of returned function.
<p/>
According to the definition from 20.10.7.6 [meta.trans.other] <tt>result_of_t&lt;FD cv &amp; (V1, V2, ..., VN)></tt> 
is equivalent to 
<tt>decltype(INVOKE(declval&lt;FD <i>cv</i> &amp;&gt;(), declval&lt;V1&gt;(), declval&lt;V2&gt;(), ..., declval&lt;VN&gt;()))</tt>. 
When combined with the definition of <tt><i>INVOKE</i></tt> from 20.9.2 [func.require] p2, the expression 
<tt><i>INVOKE</i>(fd, std::forward&lt;V1&gt;(v1), std::forward&lt;V2&gt;(v2), ..., std::forward&lt;VN&gt;(vN), 
result_of_t&lt;FD <i>cv</i> &amp; (V1, V2, ...., VN)&gt;)</tt> is equivalent to <tt><i>INVOKE</i>(fd, 
std::forward&lt;V1&gt;(v1), std::forward&lt;V2&gt;(v2), ..., std::forward&lt;VN&gt;(vN))</tt> implicitly converted 
to <tt>decltype(<i>INVOKE</i>(declval&lt;FD <i>cv</i> &amp;&gt;(), declval&lt;V1&gt;(), declval&lt;V2&gt;(), ..., 
declval&lt;VN&gt;()))</tt> (itself).
<p/>
It is also worth to notice that specifying the result type (<tt>R</tt>) in <tt><i>INVOKE</i>(f, args..., R)</tt> does 
not in any way affect the selected call. As a consequence the use of wording of the form
<tt><i>INVOKE</i>(fd, std::forward&lt;V1&gt;(v1), std::forward&lt;V2&gt;(v2), ..., std::forward&lt;VN&gt;(vN), 
result_of_t&lt;FD <i>cv</i> &amp; (V1, V2, ..., VN)&gt;)</tt> does not and cannot lead to call of different overload 
than one invoked by <tt><i>INVOKE</i>(fd, std::forward&lt;V1&gt;(v1), std::forward&lt;V2&gt;(v2), ..., 
std::forward&lt;VN&gt;(vN))</tt>.
<p/>
In summary the form <tt><i>INVOKE</i>(fd, std::forward&lt;V1&gt;(v1), std::forward&lt;V2&gt;(v2), ..., 
std::forward&lt;VN&gt;(vN), result_of_t&lt;FD <i>cv</i> &amp; (V1, V2, ..., VN)&gt;)</tt> is a convoluted way of expressing 
<tt><i>INVOKE</i>(fd, std::forward&lt;V1&gt;(v1), std::forward&lt;V2&gt;(v2), ..., std::forward&lt;VN&gt;(vN))</tt>, 
that only confuses reader.
</p>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>STL: I most recently reimplemented std::bind from scratch, and I think this issue is correct and the solution is good.</p>
<p>Move to Tentatively ready.</p>


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

<ol>
<li>
<p>Change 20.9.10.3 [func.bind.bind] p3 as indicated:</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>
[&hellip;]
<p/>
-3- <i>Returns</i>: A forwarding call wrapper <tt>g</tt> with a weak result type (20.9.2). The effect of 
<tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(fd, std::forward&lt;V1&gt;(v1), std::forward&lt;V2&gt;(v2), 
..., std::forward&lt;VN&gt;(vN)<del>, result_of_t&lt;FD <i>cv</i> &amp; (V1, V2, ..., VN)&gt;</del>)</tt>, where <del><tt><i>cv</i></tt>
represents the <i>cv</i>-qualifiers of <tt>g</tt> and</del> the values and types of the bound arguments <tt>v1, v2, ..., vN</tt> 
are determined as specified below. The copy constructor and move constructor of the forwarding call wrapper shall 
throw an exception if and only if the corresponding constructor of <tt>FD</tt> or of any of the types <tt>TiD</tt> 
throws an exception.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2557" href="#2557">2557.</a> Logical operator traits are broken in the zero-argument case</h3>
<p><b>Section:</b> 20.10.8 [meta.logical] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2015-11-05 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.logical">active issues</a> in [meta.logical].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.logical">issues</a> in [meta.logical].</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 conjunction trait in 20.10.8 [meta.logical] seems intended to support invocation with zero arguments, e.g. 
<tt>conjunction&lt;&gt;::value</tt>, which is likely to be a useful feature. However, the specification doesn't 
actually make sense in the zero-argument case. See 20.10.8 [meta.logical]/p3:
</p>
<blockquote><p>
The BaseCharacteristic of a specialization <tt>conjunction&lt;B1, &hellip;, BN&gt;</tt> is the first type <tt>B</tt> in 
the list <tt>true_type</tt>, <tt>B1</tt>, &hellip;, <tt>BN</tt> for which <tt>B::value == false</tt>, or if every 
<tt>B::value != false</tt> the BaseCharacteristic is <tt>BN</tt>.
</p></blockquote>
<p>
If "<tt>B1, ..., BN</tt>" is an empty list, then every <tt>B::value != false</tt>, so the BaseCharacteristic is <tt>BN</tt>, 
but there is no <tt>BN</tt> in this case. 
<p/>
(If LWG concludes that <tt>conjunction</tt> intentionally requires at least one argument, I would appreciate their confirmation that 
I can editorially remove the mention of <tt>true_type</tt>, which seems to have no normative impact outside the zero-argument case.)
<p/>
Similar comments apply to the <tt>disjunction</tt> trait, and to the corresponding traits in the Fundamentals working 
paper, see LWG <a href="lwg-active.html#2558">2558</a>.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Revise 20.10.8 [meta.logical] as follows:</p>

<blockquote>
<pre>
template&lt;class... B&gt; struct conjunction : <i>see below</i> { };
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- The BaseCharacteristic of a specialization <tt>conjunction&lt;B1, ..., BN&gt;</tt> is the first type <tt>Bi</tt> in the
list <tt>true_type, B1, ..., BN</tt> for which <tt>Bi::value == false</tt>, or if every <tt>Bi::value != false</tt>, the
BaseCharacteristic is <del><tt>BN</tt></del><ins>the last type in the list</ins>. [<i>Note</i>: This means a specialization 
of <tt>conjunction</tt> does not necessarily have a BaseCharacteristic of either <tt>true_type</tt> or <tt>false_type</tt>. 
&mdash; <i>end note</i>]
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class... B&gt; struct disjunction : <i>see below</i> { };
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-6- The BaseCharacteristic of a specialization <tt>disjunction&lt;B1, ..., BN&gt;</tt> is the first type <tt>Bi</tt> in the
list <tt>false_type, B1, ..., BN</tt> for which <tt>Bi::value != false</tt>, or if every <tt>Bi::value == false</tt>, the
BaseCharacteristic is <del><tt>BN</tt></del><ins>the last type in the list</ins>. [<i>Note</i>: This means a specialization 
of <tt>disjunction</tt> does not necessarily have a BaseCharacteristic of either <tt>true_type</tt> or <tt>false_type</tt>. 
&mdash; <i>end note</i>]
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2558" href="#2558">2558.</a> [fund.ts.v2] Logical operator traits are broken in the zero-argument case</h3>
<p><b>Section:</b> 99 [fund.ts.v2::meta.logical] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2015-11-05 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fund.ts.v2::meta.logical">active issues</a> in [fund.ts.v2::meta.logical].</p>
<p><b>View all other</b> <a href="lwg-index.html#fund.ts.v2::meta.logical">issues</a> in [fund.ts.v2::meta.logical].</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>
The conjunction trait in 99 [meta.logical] seems intended to support invocation with zero arguments, e.g. 
<tt>conjunction&lt;&gt;::value</tt>, which is likely to be a useful feature. However, the specification doesn't 
actually make sense in the zero-argument case. See 99 [meta.logical]/p3:
</p>
<blockquote><p>
The BaseCharacteristic of a specialization <tt>conjunction&lt;B1, &hellip;, BN&gt;</tt> is the first type <tt>B</tt> in 
the list <tt>true_type</tt>, <tt>B1</tt>, &hellip;, <tt>BN</tt> for which <tt>B::value == false</tt>, or if every 
<tt>B::value != false</tt> the BaseCharacteristic is <tt>BN</tt>.
</p></blockquote>
<p>
If "<tt>B1, ..., BN</tt>" is an empty list, then every <tt>B::value != false</tt>, so the BaseCharacteristic is <tt>BN</tt>, 
but there is no <tt>BN</tt> in this case. 
<p/>
(If LWG concludes that <tt>conjunction</tt> intentionally requires at least one argument, I would appreciate their confirmation that 
I can editorially remove the mention of <tt>true_type</tt>, which seems to have no normative impact outside the zero-argument case.)
<p/>
Similar comments apply to the <tt>disjunction</tt> trait, and to the corresponding traits in the C++ working paper,
see LWG <a href="lwg-active.html#2557">2557</a>.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; 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/n4562.html">N4562</a>.</p>

<ol>
<li><p>Revise 99 [meta.logical] as follows:</p>

<blockquote>
<pre>
template&lt;class... B&gt; struct conjunction : <i>see below</i> { };
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- The BaseCharacteristic of a specialization <tt>conjunction&lt;B1, ..., BN&gt;</tt> is the first type <tt>Bi</tt> in the
list <tt>true_type, B1, ..., BN</tt> for which <tt>Bi::value == false</tt>, or if every <tt>Bi::value != false</tt>, the
BaseCharacteristic is <del><tt>BN</tt></del><ins>the last type in the list</ins>. [<i>Note</i>: This means a specialization 
of <tt>conjunction</tt> does not necessarily have a BaseCharacteristic of either <tt>true_type</tt> or <tt>false_type</tt>. 
&mdash; <i>end note</i>]
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class... B&gt; struct disjunction : <i>see below</i> { };
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-6- The BaseCharacteristic of a specialization <tt>disjunction&lt;B1, ..., BN&gt;</tt> is the first type <tt>Bi</tt> in the
list <tt>false_type, B1, ..., BN</tt> for which <tt>Bi::value != false</tt>, or if every <tt>Bi::value == false</tt>, the
BaseCharacteristic is <del><tt>BN</tt></del><ins>the last type in the list</ins>. [<i>Note</i>: This means a specialization 
of <tt>disjunction</tt> does not necessarily have a BaseCharacteristic of either <tt>true_type</tt> or <tt>false_type</tt>. 
&mdash; <i>end note</i>]
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2559" href="#2559">2559.</a> Error in LWG 2234's resolution</h3>
<p><b>Section:</b> 19.3 [assertions] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-11-07 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</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>
The resolution of LWG <a href="lwg-defects.html#2234">2234</a> says that <tt>assert(E)</tt> is a constant subexpression if "<tt>NDEBUG</tt> is defined 
at the point where <tt>assert(E)</tt> appears".
<p/>
This is incorrect, as noted in one of STL's comments in that issue's discussion, but was apparently overlooked.
<p/>
The proposed resolution below just borrows STL's phrasing from the discussion.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Change 19.3 [assertions] p2 as indicated:</p>

<blockquote>
<p>
An expression <tt>assert(E)</tt> is a constant subexpression (17.3.28 [defns.const.subexpr]), if
</p>
<ul>
<li><p><tt>NDEBUG</tt> is defined at the point where <del><tt>assert(E)</tt> appears</del><ins><tt>assert</tt> is last 
defined or redefined</ins>, or</p></li>
<li><p>[&hellip;]</p></li>
</ul>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2560" href="#2560">2560.</a> <tt>is_constructible</tt> underspecified when applied to a function type</h3>
<p><b>Section:</b> 20.10.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2015-11-14 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
What is <tt>is_constructible&lt;void()&gt;::value</tt>? Per 20.10.4.3 [meta.unary.prop] p8:
</p>
<blockquote>
<p>
The 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(declval&lt;Args&gt;()...);
</pre></blockquote>
<p>
[<i>Note</i>: These tokens are never interpreted as a function declaration. &mdash; <i>end note</i>]
</p>
</blockquote>
<p>
The problem here is that substituting in <tt>T</tt> as a function type doesn't give a variable definition that's not well-formed 
(by 1.3.27 [defns.well.formed], well-formed means that it doesn't violate any syntactic or diagnosable semantic rules, and 
it does not). Instead, it gives a logical absurdity: this wording forces us to imagine a variable of function type, which contradicts 
the definition of "variable" in 3/6, but does so without violating any diagnosable language rule. So presumably the result must 
be undefined behavior.
<p/>
It seems that we need an explicit rule requiring <tt>T</tt> to be an object or reference type.
<p/>
<b>Daniel:</b>
<p/>
As one of the authors of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">N3142</a> I would like
to express that at least according to my mental model the intention for this trait was to be well-defined for <tt>T</tt> being
a function type with the result of <tt>false</tt> regardless of what the other type arguments are. It would seem like a very 
unfortunate and unnecessary complication to keep the result as being undefined. First, this result value is symmetric to
the result of <tt>is_destructible&lt;T&gt;::value</tt> (where the word covers function types explicitly). Second, if such a
resolution would be applied to the working paper, it wouldn't break existing implementations. I have tested clang 3.8.0,
gcc 5.x until gcc 6.0, and Visual Studio 2015, all of these implementations evaluate <tt>is_constructible&lt;void()&gt;::value</tt>
to <tt>false</tt>. 
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

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

<blockquote>
<table border="1">
<caption>Table 49 &mdash; Type property predicates</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Preconditions</th>
</tr>

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

<tr>
<td>
<tt>template &lt;class T, class... Args&gt;<br/>
struct is_constructible;</tt>
</td>

<td>
<ins>For a function type <tt>T</tt>,<br/> 
<tt>is_constructible&lt;T, Args...&gt;::value</tt><br/>
is <tt>false</tt>, otherwise</ins> <i>see below</i>
</td>

<td align="center">
<tt>T</tt> and all types in the<br/>
parameter pack <tt>Args</tt> shall<br/>
be complete types,<br/>
(possibly <i>cv</i>-qualified)<br/>
<tt>void</tt>, or arrays of<br/>
unknown bound.
</td>
</tr>

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

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





<hr>
<h3><a name="2565" href="#2565">2565.</a> <tt>std::function</tt>'s move constructor should guarantee nothrow for <tt>reference_wrapper</tt>s and function pointers</h3>
<p><b>Section:</b> 20.9.12.2.1 [func.wrap.func.con] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-05 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.9.12.2.1 [func.wrap.func.con]/5 guarantees that copying a <tt>std::function</tt> whose "target is a callable object passed 
via <tt>reference_wrapper</tt> or a function pointer" does not throw exceptions, but the standard doesn't provide this guarantee for the move constructor, 
which makes scant sense.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<blockquote class="note">
<p>
[<i>Drafting note</i>: The inserted paragraph is a copy of 20.9.12.2.1 [func.wrap.func.con]/5, only changing "copy constructor" 
to "copy or move constructor". It does not attempt to fix the issue identified in LWG <a href="lwg-active.html#2370">2370</a>, whose P/R will likely 
need updating if this wording is adopted.]
</p>
</blockquote>

<ol>
<li><p>Insert after 20.9.12.2.1 [func.wrap.func.con]/6:</p>

<blockquote>
<pre>
function(function&amp;&amp; f);
template &lt;class A&gt; function(allocator_arg_t, const A&amp; a, function&amp;&amp; f);
</pre>
<blockquote>
<p>
-6- <i>Effects</i>: If <tt>!f</tt>, <tt>*this</tt> has no target; otherwise, move-constructs the target of <tt>f</tt> into the 
target of <tt>*this</tt>, leaving <tt>f</tt> in a valid state with an unspecified value.
<p/>
<ins>-?- <i>Throws</i>: Shall not throw exceptions if <tt>f</tt>'s target is a callable object passed via <tt>reference_wrapper</tt> 
or a function pointer. Otherwise, may throw <tt>bad_alloc</tt> or any exception thrown by the copy or move constructor of the stored 
callable object. [<i>Note</i>: Implementations are encouraged to avoid the use of dynamically allocated memory for small callable 
objects, for example, where <tt>f</tt>'s target is an object holding only a pointer or reference to an object and a member function 
pointer. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2566" href="#2566">2566.</a> Requirements on the first template parameter of container adaptors</h3>
<p><b>Section:</b> 23.6 [container.adaptors] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-08 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</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>
As noted in <a href="http://stackoverflow.com/questions/34128782/what-is-the-use-of-first-template-parameter-in-priority-queue">this 
StackOverflow question</a>, 23.6 [container.adaptors] doesn't seem to place any requirement on the first template parameter 
(<tt>T</tt>) of <tt>stack</tt>, <tt>queue</tt>, and <tt>priority_queue</tt>: the only use of <tt>T</tt> is in the default template 
argument (which need not be used) for the second template parameter (<tt>Container</tt>), while all of the operations of the adaptors 
are defined using <tt>Container</tt>'s member typedefs.
<p/>
This permits confusing and arguably nonsensical types like <tt>queue&lt;double, deque&lt;std::string&gt;&gt;</tt> or 
<tt>priority_queue&lt;std::nothrow_t, vector&lt;int&gt;&gt;</tt>, which presumably wasn't intended.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Edit 23.6.1 [container.adaptors.general]/2 as indicated:</p>

<blockquote>
<p>
-2- The container adaptors each take a <tt>Container</tt> template parameter, and each constructor takes a <tt>Container</tt>
reference argument. This container is copied into the <tt>Container</tt> member of each adaptor. If the container
takes an allocator, then a compatible allocator may be passed in to the adaptor's constructor. Otherwise,
normal copy or move construction is used for the container argument. <ins>The first template parameter <tt>T</tt> of the container 
adaptors shall denote the same type as <tt>Container::value_type</tt>.</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2571" href="#2571">2571.</a> &sect;[map.modifiers]/2 imposes nonsensical requirement on <tt>insert(InputIterator, InputIterator)</tt></h3>
<p><b>Section:</b> 23.4.4.4 [map.modifiers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-12 <b>Last modified:</b> 2016-02-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#map.modifiers">issues</a> in [map.modifiers].</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 initial paragraphs of 23.4.4.4 [map.modifiers] currently read:
</p>
<blockquote>
<pre>
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);
template &lt;class P&gt; iterator insert(const_iterator position, P&amp;&amp; x);
template &lt;class InputIterator&gt;
void insert(InputIterator first, InputIterator last);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: The first form is equivalent to <tt>return emplace(std::forward&lt;P&gt;(x))</tt>. The second form is
equivalent to <tt>return emplace_hint(position, std::forward&lt;P&gt;(x))</tt>.
<p/>
-2- <i>Remarks</i>: These signatures shall not participate in overload resolution unless <tt>std::is_constructible&lt;value_type,
P&amp;&amp;&gt;::value</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
<p>
Clearly, p2's requirement makes no sense for <tt>insert(InputIterator, InputIterator)</tt> - it doesn't even have 
a template parameter called <tt>P</tt>.
<p/>
This paragraph used to have text saying "The signature taking <tt>InputIterator</tt> parameters does not require 
<tt>CopyConstructible</tt> of either <tt>key_type</tt> or <tt>mapped_type</tt> if the dereferenced <tt>InputIterator</tt> 
returns a non-<tt>const</tt> rvalue <tt>pair&lt;key_type,mapped_type&gt;</tt>. Otherwise <tt>CopyConstructible</tt> is 
required for both <tt>key_type</tt> and <tt>mapped_type</tt>", but that was removed by LWG <a href="lwg-defects.html#2005">2005</a>, whose PR 
was written as if that overload didn't exist in the text.
<p/>
It looks like the text addressing this overload is redundant to the requirements on <tt>a.insert(i, j)</tt> in Table 102 
that <tt>value_type</tt> be <tt>EmplaceConstructible</tt> from <tt>*i</tt>. If so, then the signature should just be 
deleted from this section.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Edit 23.4.4.4 [map.modifiers] as indicated:</p>

<blockquote>
<pre>
template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);
template &lt;class P&gt; iterator insert(const_iterator position, P&amp;&amp; x);
<del>template &lt;class InputIterator&gt;
void insert(InputIterator first, InputIterator last);</del>
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: The first form is equivalent to <tt>return emplace(std::forward&lt;P&gt;(x))</tt>. The second form is
equivalent to <tt>return emplace_hint(position, std::forward&lt;P&gt;(x))</tt>.
<p/>
-2- <i>Remarks</i>: These signatures shall not participate in overload resolution unless <tt>std::is_constructible&lt;value_type,
P&amp;&amp;&gt;::value</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2572" href="#2572">2572.</a> The remarks for <tt>shared_ptr::operator*</tt> should apply to <i>cv</i>-qualified <tt>void</tt> as well</h3>
<p><b>Section:</b> 20.8.2.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-13 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared.obs">active issues</a> in [util.smartptr.shared.obs].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</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.5 [util.smartptr.shared.obs]/4 says for <tt>shared_ptr::operator*</tt>
</p>
<blockquote>
<p>
<i>Remarks</i>: When <tt>T</tt> is <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>
<p>
This remark should also apply when <tt>T</tt> is <i>cv</i>-qualified <tt>void</tt> (compare LWG <a href="lwg-defects.html#2500">2500</a>).
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Edit 20.8.2.2.5 [util.smartptr.shared.obs]/4 as indicated:</p>

<blockquote>
<pre>
T&amp; operator*() const noexcept;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-4- <i>Remarks</i>: When <tt>T</tt> is <ins>(possibly <i>cv</i>-qualified)</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>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2574" href="#2574">2574.</a> [fund.ts.v2] <tt>std::experimental::function::operator=(F&amp;&amp;)</tt> should be constrained</h3>
<p><b>Section:</b> 99 [fund.ts.v2::func.wrap.func.con] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-05 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fund.ts.v2::func.wrap.func.con">active issues</a> in [fund.ts.v2::func.wrap.func.con].</p>
<p><b>View all other</b> <a href="lwg-index.html#fund.ts.v2::func.wrap.func.con">issues</a> in [fund.ts.v2::func.wrap.func.con].</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>
LWG <a href="lwg-defects.html#2132">2132</a> constrained <tt>std::function</tt>'s constructor and assignment operator from callable objects for C++14. 
The constructors of <tt>std::experimental::function</tt> isn't separately specified in the fundamentals TS and so inherited the 
constraints from C++14, but the assignment operator is separately specified and presumably needs to be constrained.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; 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/n4562.html">N4562</a>.
</p>

<ol>
<li><p>Insert a paragraph after 99 [func.wrap.func.con]/15 as indicated:</p>

<blockquote>
<pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
-14- <i>Effects</i>: <tt>function(allocator_arg, <i>ALLOCATOR_OF</i>(*this), std::forward&lt;F&gt;(f)).swap(*this);</tt>
<p/>
-15- <i>Returns</i>: <tt>*this</tt>. 
<p/>
<ins>-?- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless 
<tt>declval&lt;decay_t&lt;F&gt;&amp;&gt;()</tt> is Callable (C++14 &sect;20.9.11.2) for argument types 
<tt>ArgTypes...</tt> and return type <tt>R</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2575" href="#2575">2575.</a> [fund.ts.v2] <tt>experimental::function::assign</tt> should be removed</h3>
<p><b>Section:</b> 99 [fund.ts.v2::func.wrap.func] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-20 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fund.ts.v2::func.wrap.func">active issues</a> in [fund.ts.v2::func.wrap.func].</p>
<p><b>View all other</b> <a href="lwg-index.html#fund.ts.v2::func.wrap.func">issues</a> in [fund.ts.v2::func.wrap.func].</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>
Following the lead of LWG <a href="lwg-defects.html#2385">2385</a>, the <tt>assign(F&amp;&amp;, const A&amp;)</tt> member function template in 
<tt>std::experimental::function</tt> makes no sense (it causes undefined behavior unless the allocator passed compares equal 
to the one already used by <tt>*this</tt>) and should be removed.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; 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/n4562.html">N4562</a>.
</p>

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

<blockquote>
<pre>
namespace std {
  namespace experimental {
  inline namespace fundamentals_v2 {
    [&hellip;]
    template&lt;class R, class... ArgTypes&gt;
    class function&lt;R(ArgTypes...)&gt; {
    public:
      [&hellip;]
      void swap(function&amp;);
      <del>template&lt;class F, class A&gt; void assign(F&amp;&amp;, const A&amp;);</del>
      [&hellip;]
    };
    [&hellip;]
  } // namespace fundamentals_v2
  } // namespace experimental
  [&hellip;]
} // namespace std
</pre>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2576" href="#2576">2576.</a> <tt>istream_iterator</tt> and <tt>ostream_iterator</tt> should use <tt>std::addressof</tt></h3>
<p><b>Section:</b> 24.6 [stream.iterators] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-01-01 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#stream.iterators">issues</a> in [stream.iterators].</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>
To defend against overloaded unary <tt>&amp;</tt>. This includes the constructors of both iterators, and 
<tt>istream_iterator::operator-&gt;</tt>.
<p/>
Note that <tt>{i,o}stream_type</tt> are specializations of <tt>basic_{i,o}stream</tt>, but the constructors might still 
pick up an overloaded <tt>&amp;</tt> via the <tt>traits</tt> template parameter. This change also provides consistency 
with <tt>std::experimental::ostream_joiner</tt> (which uses <tt>std::addressof</tt>).
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Edit 24.6.1.1 [istream.iterator.cons]/3+4 as indicated:</p>

<blockquote>
<pre>
istream_iterator(istream_type&amp; s);
</pre>
<blockquote>
<p>
-3- <i>Effects</i>: Initializes <tt>in_stream</tt> with <tt><del>&amp;s</del><ins>addressof(s)</ins></tt>. <tt>value</tt> 
may be initialized during construction or the first time it is referenced.
<p/>
-4- <i>Postcondition</i>: <tt>in_stream == <del>&amp;s</del><ins>addressof(s)</ins></tt>.
</p>
</blockquote>
</blockquote>

</li>

<li><p>Edit 24.6.1.2 [istream.iterator.ops]/2 as indicated:</p>

<blockquote>
<pre>
const T* operator-&gt;() const;
</pre>
<blockquote>
<p>
-2- <i>Returns</i>: <tt><del>&amp;</del><ins>addressof</ins>(operator*())</tt>.
</p>
</blockquote>
</blockquote>

</li>

<li><p>Edit 24.6.2.1 [ostream.iterator.cons.des]/1+2 as indicated:</p>

<blockquote>
<pre>
ostream_iterator(ostream_type&amp; s);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Initializes <tt>out_stream</tt> with <tt><del>&amp;s</del><ins>addressof(s)</ins></tt> and 
<tt>delim</tt> with null.
</p>
</blockquote>
<pre>
ostream_iterator(ostream_type&amp; s, const charT* delimiter);
</pre>
<blockquote>
<p>
-2- <i>Effects</i>: Initializes <tt>out_stream</tt> with <tt><del>&amp;s</del><ins>addressof(s)</ins></tt> and 
<tt>delim</tt> with <tt>delimiter</tt>.
</p>
</blockquote>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="2577" href="#2577">2577.</a> <tt>{shared,unique}_lock</tt> should use <tt>std::addressof</tt></h3>
<p><b>Section:</b> 30.4.2.2.1 [thread.lock.unique.cons], 30.4.2.3.1 [thread.lock.shared.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-01-01 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.lock.unique.cons">issues</a> in [thread.lock.unique.cons].</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>
So that they work with user-defined types that have overloaded unary <tt>&amp;</tt>.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Edit 30.4.2.2.1 [thread.lock.unique.cons] as indicated:</p>

<blockquote>
<pre>
explicit unique_lock(mutex_type&amp; m);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-5- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == true</tt>.
</p>
</blockquote>
<pre>
unique_lock(mutex_type&amp; m, defer_lock_t) noexcept;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-7- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == false</tt>.
</p>
</blockquote>
<pre>
unique_lock(mutex_type&amp; m, try_to_lock_t);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-10- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == res</tt>, 
where <tt>res</tt> is the value returned by the call to <tt>m.try_lock()</tt>.
</p>
</blockquote>
<pre>
unique_lock(mutex_type&amp; m, adopt_lock_t);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-13- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == true</tt>.
<p/>
-14- <i>Throws</i>: Nothing.
</p>
</blockquote>
<pre>
template &lt;class Clock, class Duration&gt;
  unique_lock(mutex_type&amp; m, const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-17- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == res</tt>, 
where <tt>res</tt> is the value returned by the call to <tt>m.try_lock_until(abs_time)</tt>.
</p>
</blockquote>
<pre>
template &lt;class Rep, class Period&gt;
  unique_lock(mutex_type&amp; m, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-20- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == res</tt>, 
where <tt>res</tt> is the value returned by the call to <tt>m.try_lock_for(rel_time)</tt>.
</p>
</blockquote>
</blockquote>

</li>

<li><p>Edit 30.4.2.3.1 [thread.lock.shared.cons] as indicated:</p>

<blockquote>
<pre>
explicit shared_lock(mutex_type&amp; m);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-5- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == true</tt>.
</p>
</blockquote>
<pre>
shared_lock(mutex_type&amp; m, defer_lock_t) noexcept;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-7- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == false</tt>.
</p>
</blockquote>
<pre>
shared_lock(mutex_type&amp; m, try_to_lock_t);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-10- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == res</tt> 
where <tt>res</tt> is the value returned by the call to <tt>m.try_lock_shared()</tt>.
</p>
</blockquote>
<pre>
shared_lock(mutex_type&amp; m, adopt_lock_t);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-13- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == true</tt>.
</p>
</blockquote>
<pre>
template &lt;class Clock, class Duration&gt;
  shared_lock(mutex_type&amp; m,
              const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-16- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == res</tt> 
where <tt>res</tt> is the value returned by the call to <tt>m.try_lock_shared_until(abs_time)</tt>.
</p>
</blockquote>
<pre>
template &lt;class Rep, class Period&gt;
  shared_lock(mutex_type&amp; m,
              const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-19- <i>Postconditions</i>: <tt>pm == <del>&amp;m</del><ins>addressof(m)</ins></tt> and <tt>owns == res</tt> 
where <tt>res</tt> is the value returned by the call to <tt>m.try_lock_shared_for(rel_time)</tt>.
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2579" href="#2579">2579.</a> Inconsistency wrt Allocators in <tt>basic_string</tt> assignment vs. <tt>basic_string::assign</tt></h3>
<p><b>Section:</b> 21.4.6.3 [string::assign] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2016-01-05 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</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>
In issue <a href="lwg-defects.html#2063">2063</a>, we changed the <i>Effects</i> of <tt>basic_string::assign(basic_string&amp;&amp;)</tt> to match the 
behavior of <tt>basic_string::operator=(basic_string&amp;&amp;)</tt>, making them consistent.
<p/>
We did not consider <tt>basic_string::assign(const basic_string&amp;)</tt>, and its <i>Effects</i> differ from 
<tt>operator=(const basic_string&amp;)</tt>.
<p/>
Given the following definition:
</p>
<blockquote><pre>
typedef std::basic_string&lt;char, std::char_traits&lt;char&gt;, MyAllocator&lt;char&gt;&gt; MyString;

MyAllocator&lt;char&gt; alloc1, alloc2;
MyString string1("Alloc1", alloc1);
MyString string2(alloc2);
</pre></blockquote>
<p>
the following bits of code are not equivalent:
</p>
<blockquote><pre>
string2 = string1;       // (a) calls operator=(const MyString&amp;)
string2.assign(string1); // (b) calls MyString::assign(const MyString&amp;)
</pre></blockquote>
<p>
What is the allocator for <tt>string2</tt> after each of these calls?
</p>
<ol style="list-style-type:lower-alpha">
<li><p>If <tt>MyAllocator&lt;char&gt;::propagate_on_container_copy_assignment</tt> is true, then it should be <tt>alloc2</tt>, 
otherwise it should be <tt>alloc1</tt>.</p></li>
<li><p><tt>alloc2</tt></p></li>
</ol>
<p>	
21.4.6.3 [string::assign]/1 says that (b) is equivalent to <tt>assign(string1, 0, npos)</tt>, which eventually calls 
<tt>assign(str.data() + pos, rlen)</tt>. No allocator transfer there.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

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

<blockquote>
<pre>
basic_string&amp; assign(const basic_string&amp; str);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Equivalent to <tt><ins>*this = str</ins><del>assign(str, 0, npos)</del></tt>.
<p/>
-2- <i>Returns</i>: <tt>*this</tt>.
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2581" href="#2581">2581.</a> Specialization of <tt>&lt;type_traits&gt;</tt> variable templates should be prohibited</h3>
<p><b>Section:</b> 20.10.2 [meta.type.synop] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-01-07 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</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.10.2 [meta.type.synop]/1 only prohibits adding specializations of class templates in <tt>&lt;type_traits&gt;</tt>. 
Now that we have <tt>_v</tt> variable templates, this prohibition should apply to them as well.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Edit 20.10.2 [meta.type.synop]/1 as indicated:</p>

<blockquote>
<p>
-1- The behavior of a program that adds specializations for any of the <del>class</del> templates defined in this subclause 
is undefined unless otherwise specified.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2582" href="#2582">2582.</a> &sect;[res.on.functions]/2's prohibition against incomplete types shouldn't apply to type traits</h3>
<p><b>Section:</b> 20.10 [meta] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-01-07 <b>Last modified:</b> 2016-02-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta">active issues</a> in [meta].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta">issues</a> in [meta].</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>
17.6.4.8 [res.on.functions]/2.5 says that the behavior is undefined "if an incomplete type is used as a template argument 
when instantiating a template component, unless specifically allowed for that component."
<p/>
This rule should not apply to type traits &mdash; a literal application would make <tt>is_same&lt;void, void&gt;</tt> 
undefined behavior, since nothing in 20.10 [meta] (or elsewhere) "specifically allows" instantiating <tt>is_same</tt> 
with incomplete types.
<p/>
Traits that require complete types are already explicitly specified as such, so the proposed wording below simply negates 
17.6.4.8 [res.on.functions]/2.5 for 20.10 [meta].
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Insert a new paragraph after 20.10.2 [meta.type.synop]/1:</p>

<blockquote>
<p>
<ins>-?- Unless otherwise specified, an incomplete type may be used to instantiate a template in this subclause.</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2583" href="#2583">2583.</a> There is no way to supply an allocator for <tt>basic_string(str, pos)</tt></h3>
<p><b>Section:</b> 21.4.2 [string.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2016-01-05 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.cons">active issues</a> in [string.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#string.cons">issues</a> in [string.cons].</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>
Container and <tt>string</tt> constructors in the standard follow two general rules:
</p>
<ol>
<li><p>Every constructor needs a version with and without an allocator argument (possibly through the use of 
default arguments).</p></li>
<li><p>Every constructor <em>except the copy constructor</em> for which an allocator is not provided uses a 
default-constructed allocator.</p></li>
</ol>
<p>
The first rule ensures emplacing a <tt>string</tt> into a container that uses a scoped allocator will correctly propagate 
the container's allocator to the new element.
<p/>
The current standard allows constructing a <tt>string</tt> as <tt>basic_string(str, pos)</tt> but not 
<tt>basic_string(str, pos, alloc)</tt>. This omission breaks the first rule and causes something like the following to fail:
</p>
<blockquote>
<pre>
typedef basic_string&lt;char, char_traits&lt;char&gt;, A&lt;char&gt;&gt; stringA;
vector&lt;stringA, scoped_allocator_adaptor&lt;A&lt;stringA&gt;&gt;&gt; vs;
stringA s;

vs.emplace_back(s, 2); // Ill-formed
</pre>
</blockquote>
<p>
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Change 21.4 [basic.string], class template <tt>basic_string</tt> synopsis, as indicated</p>

<blockquote>
<pre>
basic_string(const basic_string&amp; str, size_type pos, <del>size_type n = npos,</del>
             const Allocator&amp; a = Allocator());
<ins>basic_string(const basic_string&amp; str, size_type pos, size_type n,
             const Allocator&amp; a = Allocator());</ins>             
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
basic_string(const basic_string&amp; str,
             size_type pos, <del>size_type n = npos,</del>
             const Allocator&amp; a = Allocator());
</pre>
<blockquote>
<p>
-3- <i>Throws</i>: <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt>.
<p/>
-4- <i>Effects</i>: Constructs an object of class <tt>basic_string</tt> and determines the effective length <tt>rlen</tt> 
of the initial string value as <del>the smaller of <tt>n</tt> and</del> <tt>str.size() - pos</tt>, as indicated in Table 65.
</p>
</blockquote>
<pre>
<ins>basic_string(const basic_string&amp; str, size_type pos, size_type n,
             const Allocator&amp; a = Allocator());</ins>             
</pre>
<blockquote>
<p>
<ins>-?- <i>Throws</i>: <tt>out_of_range</tt> if <tt>pos &gt; str.size()</tt>.</ins>
<p/>
<ins>-?- <i>Effects</i>: Constructs an object of class <tt>basic_string</tt> and determines the effective length <tt>rlen</tt> 
of the initial string value as the smaller of <tt>n</tt> and <tt>str.size() - pos</tt>, as indicated in Table 65.</ins>
</p>
<table border="1">
<caption>Table 65 &mdash; <tt>basic_string(const basic_string&amp;, size_type, <del>size_type,</del> const Allocator&amp;)</tt> 
<ins>and <tt>basic_string(const basic_string&amp;, size_type, size_type, const Allocator&amp;)</tt></ins> effects</caption>

<tr>
<th>Element</th>
<th>Value</th>
</tr>

<tr>
<td><tt>data()</tt></td>
<td>points at the first element of an allocated copy of
<tt>rlen</tt> consecutive elements of the string controlled
by <tt>str</tt> beginning at position <tt>pos</tt></td>
</tr>

<tr>
<td><tt>size()</tt></td>
<td><tt>rlen</tt></td>
</tr>

<tr>
<td><tt>capacity()</tt></td>
<td>a value at least as large as <tt>size()</tt></td>
</tr>

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





<hr>
<h3><a name="2585" href="#2585">2585.</a> <tt>forward_list::resize(size_type, const value_type&amp;)</tt> effects incorrect</h3>
<p><b>Section:</b> 23.3.9.5 [forwardlist.modifiers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-01-14 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#forwardlist.modifiers">issues</a> in [forwardlist.modifiers].</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>
23.3.9.5 [forwardlist.modifiers]/29 says that the effects of <tt>forward_list::resize(size_type sz, const value_type&amp; c)</tt> 
are:
</p>
<blockquote class="note"><p>
<i>Effects</i>: If <tt>sz &lt; distance(begin(), end())</tt>, erases the last <tt>distance(begin(), end()) - sz</tt> elements
from the list. Otherwise, inserts <tt>sz - distance(begin(), end())</tt> elements at the end of
the list such that each new element, <tt>e</tt>, is initialized by a method equivalent to calling 
<tt>allocator_traits&lt;allocator_type&gt;::construct(get_allocator(), std::addressof(e), c)</tt>.
</p></blockquote>
<p>
In light of LWG <a href="lwg-defects.html#2218">2218</a>, the use of <tt>allocator_traits&lt;allocator_type&gt;::construct</tt> is incorrect, 
as a rebound allocator may be used. There's no need to repeat this information, in any event &mdash; no other specification 
of <tt>resize()</tt> does it.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Edit 23.3.9.5 [forwardlist.modifiers]/29 as indicated:</p>
<blockquote class="note">
<p>
[<i>Drafting note</i>: "copies of <tt>c</tt>" is the phrase used by <tt>vector::resize</tt> and <tt>deque::resize</tt>.]
</p>
</blockquote>

<blockquote>
<pre>
void resize(size_type sz, const value_type&amp; c);
</pre>
<blockquote>
<p>
-29- <i>Effects</i>: If <tt>sz &lt; distance(begin(), end())</tt>, erases the last <tt>distance(begin(), end()) - sz</tt> elements
from the list. Otherwise, inserts <tt>sz - distance(begin(), end())</tt> <del>elements</del><ins>copies of <tt>c</tt></ins> at 
the end of the list <del>such that each new element, <tt>e</tt>, is initialized by a method equivalent to calling 
<tt>allocator_traits&lt;allocator_type&gt;::construct(get_allocator(), std::addressof(e), c)</tt></del>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2586" href="#2586">2586.</a> Wrong value category used in <tt>scoped_allocator_adaptor::construct()</tt></h3>
<p><b>Section:</b> 20.13.4 [allocator.adaptor.members], 20.7.7.2 [allocator.uses.construction] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-01-15 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.adaptor.members">active issues</a> in [allocator.adaptor.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.adaptor.members">issues</a> in [allocator.adaptor.members].</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.13.4 [allocator.adaptor.members] p9 says that the <tt>is_constructible</tt>
tests are done using <tt>inner_allocator_type</tt>, which checks for
construction from an rvalue, but then the constructor is passed
<tt>inner_allocator()</tt> which returns a non-<tt>const</tt> lvalue reference. The
value categories should be consistent, otherwise this fails to
compile:
</p>
<blockquote><pre>
#include &lt;memory&gt;
#include &lt;scoped_allocator&gt;

struct X {
  using allocator_type = std::allocator&lt;X&gt;;
  X(std::allocator_arg_t, allocator_type&amp;&amp;) { }
  X(allocator_type&amp;) { }
};

int main() {
  std::scoped_allocator_adaptor&lt;std::allocator&lt;X&gt;&gt; sa;
  sa.construct(sa.allocate(1));
}
</pre></blockquote>
<p>
<tt>uses_allocator&lt;X, decltype(sa)::inner_allocator_type&gt;></tt> is true, because
it can be constructed from an rvalue of the allocator type, so bullet (9.1) doesn't apply.
<p/>
<tt>is_constructible&lt;X, allocator_arg_t, decltype(sa)::inner_allocator_type></tt> 
is true, so bullet (9.2) applies.
That means we try to construct the object passing it
<tt>sa.inner_allocator()</tt> which is an lvalue reference, so it fails.
<p/>
The <tt>is_constructible</tt> checks should use an lvalue reference, as that's
what's actually going to be used.
<p/>
I don't think the same problem exists in the related wording in
20.7.7.2 [allocator.uses.construction] if we assume that the value categories
of <tt>v1, v2, ..., vN</tt> and <tt>alloc</tt> are meant to be preserved, so that the
<tt>is_constructible</tt> traits and the initialization expressions match.
However, it does say "an allocator <tt>alloc</tt> of type <tt>Alloc</tt>" and if <tt>Alloc</tt>
is an reference type then it's not an allocator, so I suggest a small tweak there too.
</p>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
Strike first paragraph of PR, and move to Tentatively Ready.
</p>

<strong>Original Resolution [SUPERSEDED]:</strong>
<blockquote class="note">
<ol>
<li><p>Change 20.7.7.2 [allocator.uses.construction] p1:</p>
<blockquote>
<p>
-1- Uses-allocator construction with allocator <tt>Alloc</tt> refers to the construction of an object <tt>obj</tt> 
of type <tt>T</tt>, using constructor arguments <tt>v1, v2, ..., vN</tt> of types <tt>V1, V2, ..., VN</tt>, respectively, 
and an allocator <ins>(or reference to an allocator)</ins> <tt>alloc</tt> of type <tt>Alloc</tt>, according to the 
following rules:
</p>
</blockquote>
</li>

<li><p>Change the 2nd and 3rd bullets in 20.13.4 [allocator.adaptor.members] p9 to add two lvalue-references:</p>

<blockquote>
<ol style="list-style-type: none">
<li><p>(9.2) &mdash; Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T, allocator_arg_t, inner_allocator_type<ins>&amp;</ins>, Args...&gt;::value</tt> is <tt>true</tt>, calls 
<tt><i>OUTERMOST_ALLOC_TRAITS</i>(*this)::construct(<i>OUTERMOST</i>(*this), p, allocator_arg, inner_allocator(), 
std::forward&lt;Args&gt;(args)...)</tt>.</p></li>
<li><p>(9.3) &mdash; Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T, Args..., inner_allocator_type<ins>&amp;</ins>&gt;::value</tt> is <tt>true</tt>, calls 
<tt><i>OUTERMOST_ALLOC_TRAITS</i>(*this)::construct(<i>OUTERMOST</i>(*this), p, std::forward&lt;Args&gt;(args)...,
inner_allocator())</tt>.</p></li>
</ol>
</blockquote>
</li>

<li><p>Change the 2nd, 3rd, 6th, and 7th bullets in 20.13.4 [allocator.adaptor.members] p11 to
add four lvalue-references:</p>

<blockquote>
<ol style="list-style-type: none">
<li><p>(11.2) &mdash; Otherwise, if <tt>uses_allocator&lt;T1, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T1, allocator_arg_t, inner_allocator_type<ins>&amp;</ins>, Args1...&gt;::value</tt> is <tt>true</tt>, 
then <tt>xprime</tt> is <tt>tuple_cat(tuple&lt;allocator_arg_t, inner_allocator_type&amp;&gt;(allocator_arg, 
inner_allocator()), std::move(x))</tt>.</p></li>
<li><p>(11.3) &mdash; Otherwise, if <tt>uses_allocator&lt;T1, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T1, Args1..., inner_allocator_type<ins>&amp;</ins>&gt;::value</tt> is <tt>true</tt>, then 
<tt>xprime</tt> is <tt>tuple_cat(std::move(x), tuple&lt;inner_allocator_type&amp;&gt;(inner_allocator()))</tt>.</p></li>
<li><p>[&hellip;]</p></li>
<li><p>(11.6) &mdash; Otherwise, if <tt>uses_allocator&lt;T2, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T2, allocator_arg_t, inner_allocator_type<ins>&amp;</ins>, Args2...&gt;::value</tt> is <tt>true</tt>, 
then <tt>yprime</tt> is <tt>tuple_cat(tuple&lt;allocator_arg_t, inner_allocator_type&amp;&gt;(allocator_arg, 
inner_allocator()), std::move(y))</tt>.</p></li>
<li><p>(11.7) &mdash; Otherwise, if <tt>uses_allocator&lt;T2, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T2, Args2..., inner_allocator_type<ins>&amp;</ins>&gt;::value</tt> is <tt>true</tt>, then 
<tt>yprime</tt> is <tt>tuple_cat(std::move(y), tuple&lt;inner_allocator_type&amp;&gt;(inner_allocator()))</tt>.</p></li>
</ol>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Change the 2nd and 3rd bullets in 20.13.4 [allocator.adaptor.members] p9 to add two lvalue-references:</p>

<blockquote>
<ol style="list-style-type: none">
<li><p>(9.2) &mdash; Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T, allocator_arg_t, inner_allocator_type<ins>&amp;</ins>, Args...&gt;::value</tt> is <tt>true</tt>, calls 
<tt><i>OUTERMOST_ALLOC_TRAITS</i>(*this)::construct(<i>OUTERMOST</i>(*this), p, allocator_arg, inner_allocator(), 
std::forward&lt;Args&gt;(args)...)</tt>.</p></li>
<li><p>(9.3) &mdash; Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T, Args..., inner_allocator_type<ins>&amp;</ins>&gt;::value</tt> is <tt>true</tt>, calls 
<tt><i>OUTERMOST_ALLOC_TRAITS</i>(*this)::construct(<i>OUTERMOST</i>(*this), p, std::forward&lt;Args&gt;(args)...,
inner_allocator())</tt>.</p></li>
</ol>
</blockquote>
</li>

<li><p>Change the 2nd, 3rd, 6th, and 7th bullets in 20.13.4 [allocator.adaptor.members] p11 to
add four lvalue-references:</p>

<blockquote>
<ol style="list-style-type: none">
<li><p>(11.2) &mdash; Otherwise, if <tt>uses_allocator&lt;T1, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T1, allocator_arg_t, inner_allocator_type<ins>&amp;</ins>, Args1...&gt;::value</tt> is <tt>true</tt>, 
then <tt>xprime</tt> is <tt>tuple_cat(tuple&lt;allocator_arg_t, inner_allocator_type&amp;&gt;(allocator_arg, 
inner_allocator()), std::move(x))</tt>.</p></li>
<li><p>(11.3) &mdash; Otherwise, if <tt>uses_allocator&lt;T1, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T1, Args1..., inner_allocator_type<ins>&amp;</ins>&gt;::value</tt> is <tt>true</tt>, then 
<tt>xprime</tt> is <tt>tuple_cat(std::move(x), tuple&lt;inner_allocator_type&amp;&gt;(inner_allocator()))</tt>.</p></li>
<li><p>[&hellip;]</p></li>
<li><p>(11.6) &mdash; Otherwise, if <tt>uses_allocator&lt;T2, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T2, allocator_arg_t, inner_allocator_type<ins>&amp;</ins>, Args2...&gt;::value</tt> is <tt>true</tt>, 
then <tt>yprime</tt> is <tt>tuple_cat(tuple&lt;allocator_arg_t, inner_allocator_type&amp;&gt;(allocator_arg, 
inner_allocator()), std::move(y))</tt>.</p></li>
<li><p>(11.7) &mdash; Otherwise, if <tt>uses_allocator&lt;T2, inner_allocator_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_constructible&lt;T2, Args2..., inner_allocator_type<ins>&amp;</ins>&gt;::value</tt> is <tt>true</tt>, then 
<tt>yprime</tt> is <tt>tuple_cat(std::move(y), tuple&lt;inner_allocator_type&amp;&gt;(inner_allocator()))</tt>.</p></li>
</ol>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2590" href="#2590">2590.</a> Aggregate initialization for <tt>std::array</tt></h3>
<p><b>Section:</b> 23.3.7.1 [array.overview] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Robert Haberlach <b>Opened:</b> 2016-01-30 <b>Last modified:</b> 2016-02-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#array.overview">active issues</a> in [array.overview].</p>
<p><b>View all other</b> <a href="lwg-index.html#array.overview">issues</a> in [array.overview].</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>
Similar to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1270">core issue 1270's</a> resolution, 
23.3.7.1 [array.overview]/2 should cover aggregate-initialization in general. 
As it stands, that paragraph solely mentions copy-list-initialization &mdash; i.e. it is unclear whether the following 
notation is (guaranteed to be) well-formed:
</p>
<blockquote><pre>
std::array&lt;int, 1&gt; arr{0};
</pre></blockquote>

<p><i>[2016-02, Issues Telecon]</i></p>

<p>
P0; move to Tentatively Ready.
</p>


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

<ol>
<li><p>Change 23.3.7.1 [array.overview] p2 as indicated:</p>
<blockquote><p>
-2- An <tt>array</tt> is an aggregate (8.5.1) that can be <ins>list-</ins>initialized with <del>the syntax</del>
</p>
<blockquote><pre>
<del>array&lt;T, N&gt; a = { <i>initializer-list</i> };</del>
</pre></blockquote>
<p>
<del>where <i>initializer-list</i> is a comma-separated list of</del> up to <tt>N</tt> elements whose types are convertible to <tt>T</tt>.
</p>
</blockquote>
</li>
</ol>





</body>
</html>
