<!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 Kona</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table {border-collapse: collapse;}
</style>
</head>
<body>
<h1>C++ Standard Library Issues to be moved in Kona</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">R0165R4</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2017-02-06 at 04:02:09 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="2260" href="#2260">2260.</a> Missing requirement for <tt>Allocator::pointer</tt></h3>
<p><b>Section:</b> 17.5.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-05-14 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
For an allocator <tt>A&lt;T&gt;</tt> which defines <tt>A&lt;T&gt;::pointer</tt> to a class type,
i.e. not <tt>T*</tt>, I see no requirement that <tt>A&lt;T&gt;::pointer</tt> is convertible to
<tt>A&lt;U&gt;::pointer</tt>, even if <tt>T*</tt> is convertible to <tt>U*</tt>.  Such conversions are
needed in containers to convert from e.g. <tt>ListNodeBase*</tt> to <tt>ListNode&lt;T&gt;*</tt>.
</p>

<p>The obvious way to do such conversions appears to be
<tt>pointer_traits::pointer_to()</tt>, but that's ill-formed if the static
member function <tt>A&lt;T&gt;::pointer::pointer_to()</tt> doesn't exist and the
allocator requirements don't mention that function, so you need to
cast <tt>A&lt;T&gt;::pointer</tt> to <tt>A&lt;T&gt;::void_pointer</tt> then cast that to
<tt>A&lt;U&gt;::pointer</tt>.
</p>

<p>
Is converting via <tt>void_pointer</tt> really intended, or are we missing a requirement that 
<tt>pointer_traits&lt;A&lt;T&gt;::pointer&gt;::pointer_to()</tt> be well-formed?
</p>

<p>Proposed resolution:</p>

<p>Add to the Allocator requirements table the following requirement:</p>

<blockquote>
<p>
The expression <tt>pointer_traits&lt;XX::pointer&gt;::pointer_to(r)</tt> is well-defined.
</p>
</blockquote>

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

<p>
Pablo to come back with proposed wording
</p>

<p><i>[2015-07 Telecon]</i></p>

<p>
Marshall to ping Pablo for proposed wording and disable current wording.
</p>

<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class = "note">
<ol>
<li><p>
Edit Table 28 as indicated:
</p>

<blockquote>
<table border="1">
<caption>Table 28 &mdash; Allocator requirements (continued)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Default</th>
</tr>

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

<tr>
<td>
<tt>static_cast&lt;X::const_pointer&gt;(z)</tt>
</td>
<td>
<tt>X::const_pointer</tt>
</td>
<td>
<tt>static_cast&lt;X::const_pointer&gt;(z) == q</tt>
</td>
<td>
&nbsp;
</td>
</tr>

<tr>
<td>
<ins><tt>pointer_traits&lt;X::pointer&gt;::pointer_to(r)</tt></ins>
</td>
<td>
<ins><tt>X::pointer</tt></ins>
</td>
<td>
&nbsp;
</td>
<td>
&nbsp;
</td>
</tr>

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

</table>
</blockquote>


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


<p><i>[2016-11-12, Issaquah]</i></p>

<p>This is related to <a href="lwg-active.html#1521">1521</a>.</p>
<p>Sat PM: Restore original P/R and move to tentatively ready.</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li><p>
Edit Table 28 as indicated:
</p>

<blockquote>
<table border="1">
<caption>Table 28 &mdash; Allocator requirements (continued)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Default</th>
</tr>

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

<tr>
<td>
<tt>static_cast&lt;X::const_pointer&gt;(z)</tt>
</td>
<td>
<tt>X::const_pointer</tt>
</td>
<td>
<tt>static_cast&lt;X::const_pointer&gt;(z) == q</tt>
</td>
<td>
&nbsp;
</td>
</tr>

<tr>
<td>
<ins><tt>pointer_traits&lt;X::pointer&gt;::pointer_to(r)</tt></ins>
</td>
<td>
<ins><tt>X::pointer</tt></ins>
</td>
<td>
&nbsp;
</td>
<td>
&nbsp;
</td>
</tr>

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

</table>
</blockquote>


</li>
</ol>





<hr>
<h3><a name="2768" href="#2768">2768.</a> <tt>any_cast</tt> and move semantics</h3>
<p><b>Section:</b> 20.8.4 [any.nonmembers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2016-08-27 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#any.nonmembers">active issues</a> in [any.nonmembers].</p>
<p><b>View all other</b> <a href="lwg-index.html#any.nonmembers">issues</a> in [any.nonmembers].</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>
LWG <a href="lwg-defects.html#2509">2509</a> made two changes to the specification of <tt>any</tt> in v2 of the library fundamentals TS:
</p>

<ol>
<li>It altered the effects of the <tt>any_cast(any&amp;&amp;)</tt> overload to enable moving the value out of the <tt>any</tt> 
object and/or obtaining an rvalue reference to the contained value.</li>

<li>It made changes to support pathological copyable-but-not-movable contained values, which is madness.</li>
</ol>

<p>
Change 1 has very desirable effects; I propose that we apply the sane part of LWG <a href="lwg-defects.html#2509">2509</a> to <tt>any</tt> 
in the C++17 WP, for all of the reasons cited in the discussion of LWG <a href="lwg-defects.html#2509">2509</a>.
</p>

<p><i>[2016-09-09 Issues Resolution Telecon]</i></p>

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

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

<ol>
<li><p>In 20.8.4 [any.nonmembers] p5, edit as follows:</p>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  ValueType any_cast(const any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp;&amp; operand);
</pre>
<blockquote>
<p>
-4- <i>Requires</i>: <tt>is_reference_v&lt;ValueType&gt;</tt> is <tt>true</tt> or <tt>is_copy_constructible_v&lt;ValueType&gt;</tt> 
is <tt>true</tt>. Otherwise the program is ill-formed. 
</p>
<p>
-5- <i>Returns</i>: For the first form, <tt>*any_cast&lt;add_const_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)</tt>. 
For the second <del>and third</del> form<del>s</del>, <tt>*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand)</tt>. 
<ins>For the third form, <tt>std::forward&lt;ValueType&gt;(*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand))</tt>.</ins>
</p>
<p>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>

</blockquote>
<p><i>[Issues Telecon 16-Dec-2016]</i></p>

<p>Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
Resolved by the wording provided by LWG <a href="lwg-active.html#2769">2769</a>.
</p>






<hr>
<h3><a name="2769" href="#2769">2769.</a> Redundant <tt>const</tt> in the return type of <tt>any_cast(const any&amp;)</tt></h3>
<p><b>Section:</b> 20.8.4 [any.nonmembers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2016-09-02 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#any.nonmembers">active issues</a> in [any.nonmembers].</p>
<p><b>View all other</b> <a href="lwg-index.html#any.nonmembers">issues</a> in [any.nonmembers].</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 overload of <tt>any_cast</tt> that accepts a reference to constant <tt>any</tt>:
</p>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  ValueType any_cast(const any&amp; operand);
</pre>
</blockquote>
<p>
is specified to return <tt>*any_cast&lt;add_const_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)</tt> in [any.nonmembers]/5. This calls the pointer-to-constant overload of <tt>any_cast</tt>:
</p>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  const ValueType* any_cast(const any* operand) noexcept;
</pre>
</blockquote>
<p>
which is specified as:
</p>
<blockquote>
<i>Returns:</i> If <tt>operand != nullptr &amp;&amp; operand-&gt;type() == typeid(ValueType)</tt>, a pointer to the object contained by <tt>operand</tt>; otherwise, <tt>nullptr</tt>.
</blockquote>
<p>
Since <tt>typeid(T) == typeid(const T)</tt> for all types <tt>T</tt>, <tt>any_cast&lt;add_const_t&lt;T&gt;&gt;(&amp;operand)</tt> is equivalent to <tt>any_cast&lt;T&gt;(&amp;operand)</tt> for all types <tt>T</tt> when operand is a constant lvalue <tt>any</tt>. 
The <tt>add_const_t</tt> in the return specification of the first overload above is therefore redundant.
</p>

<p><i>[2016-09-09 Issues Resolution Telecon]</i></p>

<p>P0; move to Tentatively Ready</p>
<p>Casey will provide combined wording for this and <a href="lwg-active.html#2768">2768</a>, since they modify the same paragraph.</p>

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

<ol>
<li><p>Modify 20.8.4 [any.nonmembers] as indicated:</p>
<blockquote>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  ValueType any_cast(const any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp;&amp; operand);
</pre>
</blockquote>
<p>
-4- <i>Requires:</i> <tt>is_reference_v&lt;ValueType&gt;</tt> is <tt>true</tt> or 
<tt>is_copy_constructible_v&lt;ValueType&gt;</tt> is <tt>true</tt>. Otherwise the program is ill-formed.
<p/>
-5- <i>Returns:</i> <del>For the first form, 
<tt>*any_cast&lt;add_const_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)</tt>. 
For the second and third forms,</del> <tt>*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand)</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-09-09 Casey improves wording as determined by telecon]</i></p>

<p>
The presented resolution is intended as the common wording for both LWG <a href="lwg-active.html#2768">2768</a> and LWG <a href="lwg-active.html#2769">2769</a>.
</p>

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

<ol>
<li><p>Modify 20.8.4 [any.nonmembers] as indicated:</p>
<blockquote>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  ValueType any_cast(const any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp;&amp; operand);
</pre>
</blockquote>
<p>
-4- <i>Requires:</i> <tt>is_reference_v&lt;ValueType&gt;</tt> is <tt>true</tt> or 
<tt>is_copy_constructible_v&lt;ValueType&gt;</tt> is <tt>true</tt>. Otherwise the program is ill-formed.
<p/>
-5- <i>Returns:</i> For the first <del>form, 
<tt>*any_cast&lt;add_const_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)</tt>. 
For the</del> <ins>and</ins> second <del>and third</del> form<del>s</del>, 
<tt>*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand)</tt>. <ins>For the third form, 
<tt>std::forward&lt;ValueType&gt;(*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand))</tt>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-10-05, Tomasz and Casey reopen and improve the wording]</i></p>

<p>
The constraints placed on the non-pointer <tt>any_cast</tt> overloads are neither necessary nor sufficient to 
guarantee that the specified effects are well-formed. The current PR for LWG <a href="lwg-active.html#2769">2769</a> also makes it 
possible to retrieve a dangling lvalue reference to a temporary any with e.g. <tt>any_cast&lt;int&amp;&gt;(any{42})</tt>, 
which should be forbidden.
</p>

<p><i>[2016-10-16, Eric made some corrections to the wording]</i></p>


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

<ol>
<li><p>Modify 20.8.4 [any.nonmembers] as indicated:</p>
<blockquote>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  ValueType any_cast(const any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp;&amp; operand);
</pre>
</blockquote>
<p>
-4- <i>Requires:</i> <del><tt>is_reference_v&lt;ValueType&gt;</tt> is <tt>true</tt> or 
<tt>is_copy_constructible_v&lt;ValueType&gt;</tt> is <tt>true</tt>.</del><ins>For the first 
overload, <tt>is_constructible_v&lt;ValueType, const remove_cv_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&amp;&gt;</tt> 
is <tt>true</tt>. For the second overload, <tt>is_constructible_v&lt;ValueType, 
remove_cv_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&amp;&gt;</tt> is <tt>true</tt>. For the third overload, 
<tt>is_constructible_v&lt;ValueType, remove_cv_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;</tt> is 
<tt>true</tt>.</ins> Otherwise the program is ill-formed.
<p/>
-5- <i>Returns:</i> <del>For the first form, 
<tt>*any_cast&lt;add_const_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)</tt>. For the second and third 
forms, <tt>*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand)</tt>.</del><ins>For the first and second 
overload, <tt>static_cast&lt;ValueType&gt;(*any_cast&lt;remove_cv_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand))</tt>. For the third overload, <tt>static_cast&lt;ValueType&gt;(std::move(*any_cast&lt;remove_cv_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)))</tt>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-11-10, LWG asks for simplification of the wording]</i></p>

<p><i>[Issues Telecon 16-Dec-2016]</i></p>

<p>Move to Tentatively Ready</p>


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

<ol>
<li><p>Modify 20.8.4 [any.nonmembers] as indicated:</p>
<blockquote>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  ValueType any_cast(const any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp;&amp; operand);
</pre>
</blockquote>
<p>
<ins>-?- Let <tt>U</tt> be the type <tt>remove_cv_t&lt;remove_reference_t&lt;ValueType&gt;&gt;</tt>.</ins>
</p>
<p>
-4- <i>Requires:</i> <del><tt>is_reference_v&lt;ValueType&gt;</tt> is <tt>true</tt> or
<tt>is_copy_constructible_v&lt;ValueType&gt;</tt> is <tt>true</tt>.</del><ins>For the first
overload, <tt>is_constructible_v&lt;ValueType, const U&amp;&gt;</tt>
is <tt>true</tt>. For the second overload, <tt>is_constructible_v&lt;ValueType,
U&amp;&gt;</tt> is <tt>true</tt>. For the third overload,
<tt>is_constructible_v&lt;ValueType, U&gt;</tt> is
<tt>true</tt>.</ins> Otherwise the program is ill-formed.
<p/>
-5- <i>Returns:</i> <del>For the first form,
<tt>*any_cast&lt;add_const_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)</tt>. For the second and third
forms, <tt>*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand)</tt>.</del><ins>For the first and second
overload, <tt>static_cast&lt;ValueType&gt;(*any_cast&lt;U&gt;(&amp;operand))</tt>. For the third overload, <tt>static_cast&lt;ValueType&gt;(std::move(*any_cast&lt;U&gt;(&amp;operand)))</tt>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2781" href="#2781">2781.</a> Contradictory requirements for <tt>std::function</tt> and <tt>std::reference_wrapper</tt></h3>
<p><b>Section:</b> 20.14.13.2.1 [func.wrap.func.con] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-10-13 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func.con">active issues</a> in [func.wrap.func.con].</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>template&lt;class F&gt; function(F f)</tt> says that the effects are "<tt>*this</tt>
targets a copy of <tt>f</tt>" which seems pretty clear that if <tt>F</tt> is
<tt>reference_wrapper&lt;CallableType&gt;</tt> then the target is a
<tt>reference_wrapper&lt;CallableType&gt;</tt>.
<p/>
But the function copy and move constructors say "shall not throw
exceptions if <tt>f</tt>'s target is a callable object passed via
<tt>reference_wrapper</tt> or a function pointer." From the requirement above
it's impossible for the target to be "a callable object passed via
<tt>reference_wrapper</tt>" because if the function was constructed with such a
type then the target is the <tt>reference_wrapper</tt> not the callable object
it wraps.
<p/>
This matters because it affects the result of <tt>function::target_type()</tt>,
and we have implementation divergence. VC++ and libc++ store the
<tt>reference_wrapper</tt> as the target, but libstdc++ and Boost.Function
(both written by Doug Gregor) unwrap it, so the following fails:
</p>
<blockquote><pre>
#include &lt;functional&gt;
#include &lt;cassert&gt;

int main()
{
 auto f = []{};
 std::function&lt;void()&gt; fn(std::ref(f));
 assert(fn.target&lt;std::reference_wrapper&lt;decltype(f)&gt;&gt;() != nullptr);
}
</pre></blockquote>
<p>
If <tt>std::function</tt> is intended to deviate from <tt>boost::function</tt> this way
then the <i>Throws</i> element for the copy and move constructors is
misleading, and should be clarified.
</p>

<p><i>[2016-11-12, Issaquah]</i></p>

<p>Sat AM: Priority 0; move to Ready</p>


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

<ol>
<li><p>Modify 20.14.13.2.1 [func.wrap.func.con] p4 and p6 the same way, as shown:</p>

<blockquote>
<pre>
function(const function&amp; f);
</pre>
<blockquote>
<p>
-3- <i>Postconditions:</i> <tt>!*this</tt> if <tt>!f</tt>; otherwise, <tt>*this</tt> targets a copy of 
<tt>f.target()</tt>.
<p/>
-4- <i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a <del>callable object passed 
via</del><ins>specialization of</ins> <tt>reference_wrapper</tt> or a function pointer. Otherwise, may throw 
<tt>bad_alloc</tt> or any exception thrown by the copy 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>]
</p>
</blockquote>
<pre>
function(function&amp;&amp; f);
</pre>
<blockquote>
<p>
-5- <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/>
-6- <i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a <del>callable object passed 
via</del><ins>specialization of</ins> <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>]
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2782" href="#2782">2782.</a> <tt>scoped_allocator_adaptor</tt> constructors must be constrained</h3>
<p><b>Section:</b> 20.13.3 [allocator.adaptor.cnstr] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-10-14 <b>Last modified:</b> 2017-02-03</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>
The templated constructors of <tt>scoped_allocator_adaptor</tt> need to be constrained, otherwise uses-allocator 
construction gives the wrong answer and causes errors for code that should compile.
<p/>
Consider two incompatible allocator types:
</p>
<blockquote><pre>
template&lt;class T&gt; struct Alloc1 { ... };
template&lt;class T&gt; struct Alloc2 { ... };
static_assert(!is_convertible_v&lt;Alloc1&lt;int&gt;, Alloc2&lt;int&gt;&gt;);
</pre></blockquote>
<p>
The unconstrained constructors give this bogus answer:
</p>
<blockquote><pre>
template&lt;class T&gt; using scoped = scoped_allocator_adaptor&lt;T&gt;;
static_assert(is_convertible_v&lt;scoped&lt;Alloc1&lt;int&gt;&gt;, scoped&lt;Alloc2&lt;int&gt;&gt;&gt;);
</pre></blockquote>
<p>
This causes <tt>uses_allocator</tt> to give the wrong answer for any specialization involving incompatible 
<tt>scoped_allocator_adaptors</tt>, which makes <tt>scoped_allocator_adaptor::construct()</tt> take an ill-formed 
branch e.g.
</p>
<blockquote><pre>
struct X 
{
  using allocator_type = scoped&lt;Alloc2&lt;int&gt;&gt;;
  X(const allocator_type&amp;);
  X();
};
scoped&lt;Alloc1&lt;int&gt;&gt;{}.construct((X*)0);
</pre></blockquote>
<p>
This fails to compile, because <tt>uses_allocator&lt;X, scoped_allocator_adaptor&lt;Alloc2&lt;int&gt;&gt;&gt;</tt> is 
<tt>true</tt>, so the allocator is passed to the <tt>X</tt> constructor, but the conversion fails. The error is outside 
the immediate context, and so is a hard error.
</p>

<p><i>[2016-11-12, Issaquah]</i></p>

<p>Sat AM: Priority 0; move to Ready</p>
<p>Billy to open another issue about the confusion with the ctor</p>


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

<ol>
<li><p>Modify 20.13.3 [allocator.adaptor.cnstr] by converting "Requires" elements to "Remarks: shall not participate ..." constraints as shown:</p>

<blockquote>
<pre>
template &lt;class OuterA2&gt;
  scoped_allocator_adaptor(OuterA2&amp;&amp; outerAlloc,
                           const InnerAllocs&amp;... innerAllocs) noexcept;
</pre>
<blockquote>
<p>
<del>-2- <i>Requires:</i> <tt>OuterAlloc</tt> shall be constructible from <tt>OuterA2</tt>.</del>
<p/>
-3- <i>Effects:</i> Initializes the <tt>OuterAlloc</tt> base class with <tt>std::forward&lt;OuterA2&gt;(outerAlloc)</tt> and 
inner with <tt>innerAllocs...</tt> (hence recursively initializing each allocator within the adaptor with the
corresponding allocator from the argument list).
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;OuterAlloc, OuterA2&gt;</tt> is <tt>true</tt>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template &lt;class OuterA2&gt;
  scoped_allocator_adaptor(const scoped_allocator_adaptor&lt;OuterA2,
                           InnerAllocs...&gt;&amp; other) noexcept;
</pre>
<blockquote>
<p>
<del>-6- <i>Requires:</i> <tt>OuterAlloc</tt> shall be constructible from <tt>OuterA2</tt>.</del>
<p/>
-7- <i>Effects:</i> Initializes each allocator within the adaptor with the corresponding allocator from <tt>other</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;OuterAlloc, const OuterA2&amp;&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class OuterA2&gt;
  scoped_allocator_adaptor(scoped_allocator_adaptor&lt;OuterA2,
                           InnerAllocs...&gt;&amp;&amp; other) noexcept;
</pre>
<blockquote>
<p>
<del>-8- <i>Requires:</i> <tt>OuterAlloc</tt> shall be constructible from <tt>OuterA2</tt>.</del>
<p/>
-9- <i>Effects:</i> Initializes each allocator within the adaptor with the corresponding allocator rvalue from <tt>other</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;OuterAlloc, OuterA2&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2784" href="#2784">2784.</a> Resolution to LWG 2484 is missing "otherwise, no effects" and is hard to parse</h3>
<p><b>Section:</b> 18.8.7 [except.nested] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-10-15 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
<p><b>View all other</b> <a href="lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The discussion notes for LWG <a href="lwg-defects.html#2484">2484</a> point out there should be an "else, no effects" at the end, 
which didn't make it into the resolution. Without this it's unclear whether it should do nothing, or be ill-formed, 
or undefined.
<p/>
Additionally, the precise effects of the <i>Effects</i> are hard to determine, because the conditions on the 
static type and dynamic type are intermingled, but must actually be checked separately (the static checks must 
be done statically and the dynamic checks must be done dynamically!) Furthermore, the obvious way to know if 
"the dynamic type of <tt>e</tt> is <tt>nested_exception</tt> or is publicly and unambiguously derived from 
<tt>nested_exception</tt>" is to use <tt>dynamic_cast</tt>, so we have to use <tt>dynamic_cast</tt> to find out 
whether to perform the <tt>dynamic_cast</tt> expression specified in the <i>Effects</i>. It would make more sense 
to specify it in terms of a <tt>dynamic_cast</tt> to a pointer type, and only call <tt>rethrow_nested()</tt> if 
the result is not null.
<p/>
The entire spec can be expressed in C++17 as:
</p>
<blockquote><pre>
if constexpr(is_polymorphic_v&lt;E&gt; &amp;&amp; (!is_base_of_v&lt;nested_exception, E&gt; || is_convertible_v&lt;E*, nested_exception*&gt;))
  if (auto p = dynamic_cast&lt;const nested_exception*&gt;(addressof(e)))
    p->rethrow_nested();
</pre></blockquote>
<p>
This uses traits to perform checks on the static type, then uses <tt>dynamic_cast</tt> to perform the checks on the 
dynamic type. I think the spec would be clearer if it had the same structure.
</p>
<p><i>[2016-11-12, Issaquah]</i></p>

<p>Sat AM: Priority 0; move to Ready</p>


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

<ol>
<li><p>Modify 18.8.7 [except.nested] p9:</p>

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






<hr>
<h3><a name="2785" href="#2785">2785.</a> <tt>quoted</tt> should work with <tt>basic_string_view</tt></h3>
<p><b>Section:</b> 27.7.8 [quoted.manip] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2016-10-27 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#quoted.manip">issues</a> in [quoted.manip].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>Quoted output for strings was added for C++14. But when we merged <tt>string_view</tt>
from the Library Fundamentals TS, we did not add support for quoted output of
<tt>basic_string_view</tt></p>

<p><i>[2016-11-12, Issaquah]</i></p>

<p>Sat AM: Priority 0; move to Ready</p>
<p>13 -> 13 in paragraph modification; and T14 -> T15</p>


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

<p>Add to the end of the &lt;iomanip&gt; synopsis in [iostream.format.overview]</p>
<pre><ins>
template &lt;class charT, class traits&gt;
  T15 quoted(basic_string_view&lt;charT, traits&gt; s,
             charT delim = charT(’"’), charT escape = charT(’\\’));
</ins></pre>

<p>Add to [quoted.manip] at the end of p2:</p>
<pre><ins>
template &lt;class charT, class traits&gt;
  <i>unspecified</i> quoted(basic_string_view&lt;charT, traits&gt; s,
                            charT delim = charT(’"’), charT escape = charT(’\\’));
</ins></pre>

<p>Modify [quoted.manip]/3 as follows:</p>

<p>Returns: An object of unspecified type such that if out is an instance of
<tt>basic_ostream</tt> with member type <tt>char_type</tt> the same as <tt>charT</tt>
and with member type <tt>traits_type</tt> which in the second <ins>and third</ins> form<ins>s</ins>
is the same as <tt>traits</tt>, then the expression <tt>out &lt;&lt; quoted(s, delim, escape)</tt>
behaves as a formatted output function (27.7.3.6.1) of <tt>out</tt>. This forms a character
sequence <tt>seq</tt>, initially consisting of the following elements:</p>





<hr>
<h3><a name="2786" href="#2786">2786.</a> Annex C should mention <tt>shared_ptr</tt> changes for array support</h3>
<p><b>Section:</b> C.4.9 [diff.cpp14.utilities] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-10-18 <b>Last modified:</b> 2017-02-03</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>This is valid in C++11 and C++14:</p>
<blockquote><pre>
shared_ptr&lt;int&gt; s{unique_ptr&lt;int[]&gt;{new int[1]}};
</pre></blockquote>
<p>
The <tt>shared_ptr</tt> copies the <tt>default_delete&lt;int[]&gt;</tt> deleter from the <tt>unique_ptr</tt>, 
which does the right thing on destruction.
<p/>
In C++17 it won't compile, because <tt>!is_convertible_v&lt;int(*)[], int*&gt;</tt>.
<p/>
The solution is to use <tt>shared_ptr&lt;int[]&gt;</tt>, which doesn't work well in C++14, so there's no transition path. 
This should be called out in Annex C.
</p>
<p><i>[2016-11-12, Issaquah]</i></p>

<p>Sat AM: Priority 0; move to Ready</p>


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

<ol>
<li><p>Add to C.4.9 [diff.cpp14.utilities]:</p>
<blockquote>
<p>
<ins>20.11.2.2 [util.smartptr.shared]</ins>
<p/>
<ins><i>Change:</i> Different constraint on conversions from <tt>unique_ptr</tt>.</ins>
<p/>
<ins><i>Rationale:</i> Adding array support to <tt>shared_ptr</tt>, via the syntax <tt>shared_ptr&lt;T[]&gt;</tt> and 
<tt>shared_ptr&lt;T[N]&gt;</tt>.</ins>
<p/>
<ins><i>Effect on original feature:</i> Valid code may fail to compile or change meaning in this International Standard. 
For example:</ins>
</p>
<blockquote><pre>
<ins>#include &lt;memory&gt;
std::unique_ptr&lt;int[]&gt; arr(new int[1]);
std::shared_ptr&lt;int&gt; ptr(std::move(arr)); // error: int(*)[] is not compatible with int*</ins>
</pre></blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2787" href="#2787">2787.</a> &sect;[file_status.cons] doesn't match class definition</h3>
<p><b>Section:</b> 27.10.11 [class.file_status], 27.10.11.1 [file_status.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-10-21 <b>Last modified:</b> 2017-02-03</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>27.10.11 [class.file_status] depicts:</p>
<blockquote><pre>
explicit file_status(file_type ft = file_type::none, perms prms = perms::unknown) noexcept;
</pre></blockquote>
<p>
while 27.10.11.1 [file_status.cons] describes two constructors:
</p>
<blockquote><pre>
explicit file_status() noexcept;
explicit file_status(file_type ft, perms prms = perms::unknown) noexcept;
</pre></blockquote>
<p>
It's also not clear why the default constructor needs to be explicit. Unlike tag types, there doesn't seem to be 
a compelling reason to disallow constructing a <tt>file_status</tt> without naming the type.
</p>
<p><i>[2016-11-12, Issaquah]</i></p>

<p>Sat AM: Priority 0; move to Ready</p>


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

<ol>
<li><p>Edit 27.10.11 [class.file_status] as indicated:</p>

<blockquote><pre>
class file_status {
public:
  // 27.10.11.1, constructors and destructor:
  <ins>file_status() noexcept : file_status(file_type::none) {}</ins>
  explicit file_status(file_type ft <del>= file_type::none</del>,
                       perms prms = perms::unknown) noexcept;
  [&hellip;]
};
</pre></blockquote>
</li>

<li><p>Edit 27.10.11.1 [file_status.cons] as indicated:</p>

<blockquote>
<pre>
<del>explicit file_status() noexcept;</del>
</pre>
<blockquote>
<p>
<del>-1- <i>Postconditions:</i> <tt>type() == file_type::none</tt> and <tt>permissions() == perms::unknown</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2789" href="#2789">2789.</a> Equivalence of contained objects</h3>
<p><b>Section:</b> 20.8.3 [any.class] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-11-09 <b>Last modified:</b> 2017-02-03</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>
<b>Addresses US 29</b>
<p/>
What does it mean for (the contained) objects to be "equivalent"?
<p/>
Suggested resolution:
<p/>
Add definition (note that using <tt>operator==()</tt> involves complicated questions of overload 
resolution).
</p>

<p><i>[2016-11-08, Jonathan comments and suggests wording]</i></p>

<p>
We can rephrase the copy constructor in terms of equivalence to
construction from the contained object. We need to use in-place
construction to avoid recursion in the case where the contained object
is itself an any.
<p/>
For the move constructor we don't simply want to construct from the
contrained object, because when the contained object is stored in
dynamic memory we don't actually construct anything, we just transfer
ownership of a pointer.
</p>

<p><i>[Issues Telecon 16-Dec-2016]</i></p>

<p>Move to Tentatively Ready</p>


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

<ol>
<li><p>Change [any.cons] p2:</p>
<blockquote>
<pre>
any(const any&amp; other);
</pre>
<blockquote>
<p>
<i>Effects:</i> <del>Constructs an object of type <tt>any</tt> with an equivalent
state as <tt>other</tt>.</del><ins>If <tt>other.has_value()</tt> is <tt>false</tt>, 
constructs an object that has no value. Otherwise, equivalent to 
<tt>any(in_place&lt;T&gt;, any_cast&lt;const T&amp;&gt;(other))</tt> where <tt>T</tt> 
is the type of the contained object.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change [any.cons] p4:</p>

<blockquote>
<pre>
any(any&amp;&amp; other);
</pre>
<blockquote>
<p>
<i>Effects:</i> <del>Constructs an object of type <tt>any</tt> with a state equivalent
to the original state of <tt>other</tt>.</del><ins>If <tt>other.has_value()</tt> is <tt>false</tt>, 
constructs an object that has no value. Otherwise, constructs an object of type <tt>any</tt> that contains
either the contained object of <tt>other</tt>, or contains an object of the same type constructed from 
the contained object of other considering that contained object as an rvalue.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2794" href="#2794">2794.</a> Missing requirements for allocator pointers</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2016-11-09 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<b>Addresses US 146</b>
<p/>
An allocator-aware contiguous container must require 
an allocator whose pointer type is a contiguous 
iterator. Otherwise, functions like data for <tt>basic_string</tt>
and <tt>vector</tt> do not work correctly, along with many 
other expectations of the contiguous guarantee.
<p/>
Suggested resolution:
<p/>
Add a second sentence to 23.2.1 [container.requirements.general] p13:
</p>
<blockquote><p>
An allocator-aware contiguous container requires <tt>allocator_traits&lt;Allocator&gt;::pointer</tt> is a 
contiguous iterator.
</p></blockquote>

<p><i>[2016-11-12, Issaquah]</i></p>

<p>Sat PM: Move to 'Tentatively Ready'</p>


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

<ol>
<li><p>In 17.5.3.5 [allocator.requirements]/5, edit as follows:</p>
<blockquote>
<p>
-5- An allocator type <tt>X</tt> shall satisfy the requirements of <tt>CopyConstructible</tt> (17.6.3.1). The 
<tt>X::pointer</tt>, <tt>X::const_pointer</tt>, <tt>X::void_pointer</tt>, and <tt>X::const_void_pointer</tt> 
types shall satisfy the requirements of <tt>NullablePointer</tt> (17.6.3.3). No constructor, comparison operator, 
copy operation, move operation, or swap operation on these pointer types shall exit via an exception. 
<tt>X::pointer</tt> and <tt>X::const_pointer</tt> shall also satisfy the requirements for a random access 
iterator (<del>24.2 [iterator.requirements]</del><ins>24.2.7 [random.access.iterators]</ins>)
<ins>and of a contiguous iterator (24.2.1 [iterator.requirements.general])</ins>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2795" href="#2795">2795.</a> &sect;[global.functions] provides incorrect example of ADL use</h3>
<p><b>Section:</b> 17.5.5.4 [global.functions] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-11-09 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#global.functions">issues</a> in [global.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<b>Addresses GB 39</b>
<p/>
The example is supposed to highlight the 'otherwise specified' 
aspect of invoking ADL, yet there is no such specification. It is 
unlikely that we intend to explicitly qualify calls to operator functions, 
so they probably should be exempted from this restriction.
<p/>
Suggested resolution:
<p/>
Fix example (and referenced clause) to specify use of ADL, or exempt operators from 
this clause, and find a better example, probably using <tt>swap</tt>.
</p>

<p><i>[2016-11-09, Jonathan comments and provides wording]</i></p>

<p>
The current wording was added by DR <a href="lwg-defects.html#225">225</a>.
</p>

<p><i>[2016-11-10, Tim Song comments]</i></p>

<p>
The "non-operator" seems to have been added at the wrong spot. The problem at issue is permission 
to call operator functions found via ADL, not permission for operator functions in the standard 
library to ADL all over the place. The problem is not unique to operator functions in the standard 
library &mdash; a significant portion of <tt>&lt;algorithm&gt;</tt> and <tt>&lt;numeric&gt;</tt> 
uses some operator (<tt>==</tt>, <tt>&lt;</tt>, <tt>+</tt>, <tt>*</tt>, etc.) that may be picked 
up via ADL.
<p/>
There is also an existing problem in that the example makes no sense anyway: the constraint in this 
paragraph only applies to non-members, yet <tt>ostream_iterator::operator=</tt> is a member function.
</p>

<p><i>[2016-11-10, Tim Song and Jonathan agree on new wording]</i></p>

<p>
The new wording still doesn't quite get it right:
</p>
<blockquote><p>
"calls to non-operator, non-member functions in the standard library do not use functions from another namespace 
which are found through argument-dependent name lookup" can be interpreted as saying that if a user writes 
"<tt>std::equal(a, b, c, d)</tt>", that call will not use ADL'd "<tt>operator==</tt>" because 
"<tt>std::equal(a, b, c, d)</tt>" is a "call" to a "non-operator, non-member function in the standard library".
</p></blockquote>
<p>
The key point here is that "in the standard library" should be modifying "calls", not "function".
</p>

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

<ol>
<li><p>Change 17.5.5.4 [global.functions] p4:</p>
<blockquote>
<p>
Unless otherwise specified, <ins>non-operator,</ins> non-member functions in the standard library shall not use functions from
another namespace which are found through argument-dependent name lookup (3.4.2). [<i>Note:</i> The phrase
"unless otherwise specified" <ins>applies to cases such as the swappable with requirements (17.5.3.2 [swappable.requirements]). 
The exception for overloaded operators allows</ins><del>is intended to allow</del> argument-dependent lookup in cases like that of 
<tt>ostream_iterator::operator=</tt> (24.6.2.2):
</p>
<blockquote>
<p>
<i>Effects:</i>
</p>
<blockquote>
<pre>
*out_stream &lt;&lt; value;
if (delim != 0)
  *out_stream &lt;&lt; delim ;
return *this;
</pre>
</blockquote>
<p>
&mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>
</ol>

</blockquote>

<p><i>[Issues Telecon 16-Dec-2016]</i></p>

<p>Move to Tentatively Ready</p>


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

<ol>
<li><p>Change 17.5.5.4 [global.functions] p4:</p>
<blockquote>
<p>
Unless otherwise specified, <ins>calls made by functions in the standard library to non-operator,</ins> non-member functions 
 <del>in the standard library</del> <del>shall</del><ins>do</ins> not use functions from another namespace which are found through 
argument-dependent name lookup (3.4.2). [<i>Note:</i> The phrase "unless otherwise specified" <ins>applies to 
cases such as the swappable with requirements (17.5.3.2 [swappable.requirements]). 
The exception for overloaded operators allows</ins><del>is intended to allow</del> argument-dependent lookup in cases like that of 
<tt>ostream_iterator::operator=</tt> (24.6.2.2):
</p>
<blockquote>
<p>
<i>Effects:</i>
</p>
<blockquote>
<pre>
*out_stream &lt;&lt; value;
if (delim != 0)
  *out_stream &lt;&lt; delim ;
return *this;
</pre>
</blockquote>
<p>
&mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2804" href="#2804">2804.</a> Unconditional <tt>constexpr</tt> default constructor for <tt>istream_iterator</tt></h3>
<p><b>Section:</b> 24.6.1.1 [istream.iterator.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2016-11-09 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#istream.iterator.cons">active issues</a> in [istream.iterator.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.iterator.cons">issues</a> in [istream.iterator.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>
<b>Addresses US 152</b>
<p/>
<i>see below</i> for the default constructor should simply be 
spelled <tt>constexpr</tt>. The current declaration looks like a 
member function, not a constructor, and the <tt>constexpr</tt> 
keyword implicitly does not apply unless the instantiation could 
make it so, under the guarantees al ready present in the Effects clause.
</p>
<p>
Proposed change:
<p/>
Replace <i>see below</i> with <tt>constexpr</tt> in the declaration 
of the default constructor for <tt>istream_iterator</tt> in the 
class definition, and function specification.
</p>

<p><i>[Issues Telecon 16-Dec-2016]</i></p>

<p>Jonathan provides wording, Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>In the class synopsis in 24.6.1 [istream.iterator] change the default constructor:</p>
<blockquote>
<pre>
<del><i>see below</i></del><ins>constexpr</ins> istream_iterator();
istream_iterator(istream_type&amp; s);
istream_iterator(const istream_iterator&amp; x) = default;
~istream_iterator() = default;
</pre>
</blockquote>

<p>Change [istream.iterator.cons] before paragraph 1:</p>
<blockquote>
<pre>
<del><i>see below</i></del><ins>constexpr</ins> istream_iterator();

-1- Effects: ...
</pre>
</blockquote>





<hr>
<h3><a name="2812" href="#2812">2812.</a> Range access is available with <tt>&lt;string_view&gt;</tt></h3>
<p><b>Section:</b> 24.7 [iterator.range], 21.4.1 [string.view.synop] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Johel Ernesto Guerrero Pe&ntilde;a <b>Opened:</b> 2016-10-29 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#iterator.range">active issues</a> in [iterator.range].</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.range">issues</a> in [iterator.range].</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>
21.4.1 [string.view.synop]/1 states
</p>
<blockquote><p>
The function templates defined in 20.2.2 and 24.7 are available when <tt>&lt;string_view&gt;</tt> is included.
</p></blockquote>
<p>
24.7 [iterator.range], in p1 is missing <tt>&lt;string_view&gt;</tt>.
</p>

<p><i>[Issues Telecon 16-Dec-2016]</i></p>

<p>Move to Tentatively Ready</p>


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

<ol>
<li>
<p>Edit 24.7 [iterator.range] p1 as indicated:</p>

<blockquote>
<p>
-1- In addition to being available via inclusion of the <tt>&lt;iterator&gt;</tt> header, the function templates 
in 24.7 are available when any of the following headers are included: <tt>&lt;array&gt;</tt>, <tt>&lt;deque&gt;</tt>, 
<tt>&lt;forward_list&gt;</tt>, <tt>&lt;list&gt;</tt>, <tt>&lt;map&gt;</tt>, <tt>&lt;regex&gt;</tt>, 
<tt>&lt;set&gt;</tt>, <tt>&lt;string&gt;</tt><ins>, <tt>&lt;string_view&gt;</tt></ins>, <tt>&lt;unordered_map&gt;</tt>, 
<tt>&lt;unordered_set&gt;</tt>, and <tt>&lt;vector&gt;</tt>.
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2824" href="#2824">2824.</a> <tt>list::sort</tt> should say that the order of elements is unspecified if an exception is thrown</h3>
<p><b>Section:</b> 23.3.10.5 [list.ops] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-11-16 <b>Last modified:</b> 2017-02-05</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#list.ops">issues</a> in [list.ops].</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>
Sometime between N1638 and N1804 the sentence "If an exception is thrown the order of the elements in the list is indeterminate." 
in the specification of <tt>list::sort</tt> went missing. This suspiciously coincided with the editorial change that "consolidated definitions of "Stable" in the library clauses" (N1805).
<p/>
<tt>forward_list::sort</tt> says that "If an exception is thrown the order of the elements in <tt>*this</tt> is unspecified"; 
<tt>list::sort</tt> should do the same.
</p>
<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4606.
</p>
<ol>
<li><p>Edit 23.3.10.5 [list.ops] p29 as indicated:</p>

<blockquote>
<pre>
void sort();
template &lt;class Compare&gt; void sort(Compare comp);
</pre>
<blockquote>
<p>
-28- <i>Requires:</i> <tt>operator&lt;</tt> (for the first version) or <tt>comp</tt> (for the second version) shall define 
a strict weak ordering (25.7 [alg.sorting]).
<p/>
-29- <i>Effects:</i> Sorts the list according to the <tt>operator&lt;</tt> or a <tt>Compare</tt> function object. <ins>If an 
exception is thrown, the order of the elements in <tt>*this</tt> is unspecified.</ins> Does not affect the validity of 
iterators and references.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2826" href="#2826">2826.</a> <tt>string_view</tt> iterators use old wording</h3>
<p><b>Section:</b> 21.4.2.2 [string.view.iterators] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2016-11-17 <b>Last modified:</b> 2017-02-03</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>
The wording for <tt>basic_string_view</tt> was written before the definition of
a contiguous iterator was added to C++17 to avoid repeating redundant
wording.
</p>
<p>
Suggested modification of 21.4.2.2 [string.view.iterators] p1 (stealing words from <tt>valarray begin</tt>/<tt>end</tt>):
</p>
<blockquote><p>
-1- <del>A constant random-access iterator type such that, for a <tt>const_iterator it</tt>, if <tt>&amp;*(it + N)</tt> is valid,
then <tt>&amp;*(it + N) == (&amp;*it) + N</tt></del><ins>A type that meets the requirements of a constant random access iterator 
(24.2.7) and of a contiguous iterator (24.2.1) whose <tt>value_type</tt> is the template parameter <tt>charT</tt></ins>.
</p></blockquote>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4606.
</p>
<ol>
<li><p>Modify 21.4.2.2 [string.view.iterators] as indicated:</p>
<blockquote>
<pre>
using const_iterator = <i>implementation-defined</i>;
</pre>
<blockquote>
<p>
-1- A <del>constant random-access iterator type such that, for a <tt>const_iterator it</tt>, if <tt>&amp;*(it + N)</tt> is valid,
then <tt>&amp;*(it + N) == (&amp;*it) + N</tt></del><ins>type that meets the requirements of a constant random access 
iterator (24.2.7 [random.access.iterators]) and of a contiguous iterator (24.2.1 [iterator.requirements.general])
whose <tt>value_type</tt> is the template parameter <tt>charT</tt></ins>.
<p/>
-2- For a <tt>basic_string_view str</tt>, any operation that invalidates a pointer in the range <tt>[str.data(),
str.data() + str.size())</tt> invalidates pointers, iterators, and references returned from <tt>str</tt>'s methods.
<p/>
-3- All requirements on container iterators (23.2 [container.requirements]) apply to 
<tt>basic_string_view::const_iterator</tt> as well.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2834" href="#2834">2834.</a> Resolution LWG 2223 is missing wording about end iterators</h3>
<p><b>Section:</b> 21.3.2.4 [string.capacity], 23.3.8.3 [deque.capacity], 23.3.11.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas Koeppe <b>Opened:</b> 2016-11-29 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#string.capacity">issues</a> in [string.capacity].</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#2223">2223</a> added the wording "Reallocation invalidates all the references, pointers, 
and iterators referring to the elements in the sequence." to a number of <tt>shrink_to_fit</tt> operations.
<p/>
This seems to be missing any mention of end iterators. Surely end iterators are invalidated, too?
<p/>
Suggested resolution:
<p/>
For <tt>string</tt>, <tt>deque</tt>, and <tt>vector</tt> each, append as follows:
<p/>
Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence <ins>as 
well as the past-the-end iterator</ins>.
</p>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://wg21.link/n4618">N4618</a>.
</p>
<ol>
<li><p>Edit 21.3.2.4 [string.capacity] as indicated:</p>
<blockquote>
<pre>
void shrink_to_fit();
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Remarks:</i> Reallocation invalidates all the references, pointers, and iterators referring to the elements in
the sequence <ins>as well as the past-the-end iterator</ins>. If no reallocation happens, they remain valid.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 23.3.8.3 [deque.capacity] as indicated:</p>
<blockquote>
<pre>
void shrink_to_fit();
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-8- <i>Remarks:</i> <tt>shrink_to_fit</tt> invalidates all the references, pointers, and iterators referring to the elements
in the sequence <ins>as well as the past-the-end iterator</ins>. 
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 23.3.11.3 [vector.capacity] as indicated:</p>
<blockquote>
<pre>
void shrink_to_fit();
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-10- <i>Remarks:</i> Reallocation invalidates all the references, pointers, and iterators referring to the elements in
the sequence <ins>as well as the past-the-end iterator</ins>. If no reallocation happens, they remain valid. 
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2835" href="#2835">2835.</a> LWG 2536 seems to misspecify <tt>&lt;tgmath.h&gt;</tt></h3>
<p><b>Section:</b> 26.9.6 [ctgmath.syn], D.4 [depr.c.headers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas Koeppe <b>Opened:</b> 2016-11-29 <b>Last modified:</b> 2017-02-03</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>
The resolution of LWG <a href="lwg-defects.html#2536">2536</a> touches on the specification of C headers (of the form <tt>foo.h</tt>), but 
while it fixes the specification of <tt>complex.h</tt>, it fails to address the specification of <tt>tgmath.h</tt>.
<p/>
Just like <tt>complex.h</tt>, <tt>tgmath.h</tt> is <b>not</b> defined by C. Rather, <em>our</em> <tt>tgmath.h</tt> 
behaves like <tt>&lt;ctgmath&gt;</tt>, which is specified in [ctgmath.syn].
<p/>
Suggested resolution:
<p/>
Amend [depr.c.headers] p3 as follows:
</p>
<blockquote>
<p>
3. The header <tt>&lt;complex.h&gt;</tt> behaves as if it simply includes the header <tt>&lt;ccomplex&gt;</tt>. 
<ins>The header <tt>&lt;tgmath.h&gt;</tt> behaves as if it simply includes the header <tt>&lt;ctgmath&gt;</tt>.</ins>
<p/>
4. Every other C header [&hellip;]
</p>
</blockquote>
<p>
See also LWG <a href="lwg-closed.html#2828">2828</a>.
</p>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://wg21.link/n4618">N4618</a>.
</p>
<ol>
<li><p>Edit D.4 [depr.c.headers] as indicated:</p>
<blockquote>
<p>
[&hellip;]
<p/>
-2- The use of any of the C++ headers [&hellip;] is deprecated.
<p/>
-3- The header <tt>&lt;complex.h&gt;</tt> behaves as if it simply includes the header <tt>&lt;ccomplex&gt;</tt>.
<ins>The header <tt>&lt;tgmath.h&gt;</tt> behaves as if it simply includes the header <tt>&lt;ctgmath&gt;</tt>.</ins>
<p/>
-4- Every other C header, [&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2837" href="#2837">2837.</a> <tt>gcd</tt> and <tt>lcm</tt> should support a wider range of input values</h3>
<p><b>Section:</b> 26.8.13 [numeric.ops.gcd], 26.8.14 [numeric.ops.lcm] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2016-12-16 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#numeric.ops.gcd">issues</a> in [numeric.ops.gcd].</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>This is a duplicate of <a href="lwg-defects.html#2792">2792</a>, which addressed LFTS 2.</p>

<p>By the current definition, <tt>gcd((int64_t)1234, (int32_t)-2147483648)</tt> is 
ill-formed (because <tt>2147483648</tt> is not representable as a value of <tt>int32_t</tt>.)
We want to change this case to be well-formed. As long as both <tt>|m|</tt> and <tt>|n|</tt> 
are representable as values of the common type, absolute values can 
be calculate <tt>d</tt> without causing unspecified behavior, by converting <tt>m</tt> and <tt>n</tt> 
to the common type before taking the negation.
<p/>
Suggested resolution:
</p>
<blockquote><p>
<del><tt>|m|</tt> shall be representable as a value of type <tt>M</tt> and <tt>|n|</tt> shall 
be representable as a value of type <tt>N</tt></del><ins><tt>|m|</tt> and <tt>|n|</tt> shall be 
representable as a value of <tt>common_type_t&lt;M, N&gt;</tt></ins>.
</p></blockquote>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4604">N4604</a>.</p>

<ol>
<li><p>Edit 26.8.13 [numeric.ops.gcd] as indicated:</p>
<blockquote>
<pre>
template&lt;class M, class N&gt;
  constexpr common_type_t&lt;M, N&gt; gcd(M m, N n);
</pre>
<blockquote>
<p>
-2- <i>Requires:</i> <del><tt>|m|</tt> shall be representable as a value of type <tt>M</tt> and <tt>|n|</tt> shall 
be representable as a value of type <tt>N</tt></del><ins><tt>|m|</tt> and <tt>|n|</tt> shall be representable as 
a value of <tt>common_type_t&lt;M, N&gt;</tt></ins>. [<i>Note:</i> These requirements ensure, for example, that 
<tt>gcd(m, m) = |m|</tt> is representable as a value of type <tt>M</tt>. &mdash; <i>end note</i>] 
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 26.8.14 [numeric.ops.lcm] as indicated:</p>
<blockquote>
<pre>
template&lt;class M, class N&gt;
  constexpr common_type_t&lt;M, N&gt; lcm(M m, N n);
</pre>
<blockquote>
<p>
-2- <i>Requires:</i> <del><tt>|m|</tt> shall be representable as a value of type <tt>M</tt> and <tt>|n|</tt> shall 
be representable as a value of type <tt>N</tt></del><ins><tt>|m|</tt> and <tt>|n|</tt> shall be representable as 
a value of <tt>common_type_t&lt;M, N&gt;</tt></ins>. The least common multiple of <tt>|m|</tt> and <tt>|n|</tt> shall 
be representable as a value of type <tt>common_type_t&lt;M, N&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2838" href="#2838">2838.</a> <tt>is_literal_type</tt> specification needs a little cleanup</h3>
<p><b>Section:</b> D.11 [depr.meta.types] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-12-09 <b>Last modified:</b> 2017-02-03</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>
D.11 [depr.meta.types]/3 currently reads:
</p>
<blockquote><p>
<i>Effects:</i> <tt>is_literal_type</tt> has a base-characteristic of <tt>true_type</tt> if <tt>T</tt> is a literal 
type ([basic.types]), and a base-characteristic of <tt>false_type</tt> otherwise.
</p></blockquote>
<p>
First, this doesn't seem like an <i>Effects</i> clause. Second, this wording fails to say that <tt>is_literal_type</tt> 
is an <tt>UnaryTypeTrait</tt>, and misspells <tt>BaseCharacteristic</tt> &mdash; which is only defined for 
<tt>UnaryTypeTraits</tt> and <tt>BinaryTypeTraits</tt>. Third, moving this to Annex D means that the general prohibition 
against specializing type traits in [meta.type.synop]/1 no longer applies, which is presumably unintended.
</p>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4618">N4618</a>.</p>

<ol>
<li><p>Edit D.11 [depr.meta.types] as indicated:</p>
<blockquote>
<p>
The header <tt>&lt;type_traits&gt;</tt> has the following addition:
</p>
<blockquote>
<pre>
namespace std {
  template &lt;class T&gt; struct is_literal_type;
  
  template &lt;class T&gt; constexpr bool is_literal_type_v = is_literal_type&lt;T&gt;::value;
}
</pre>
</blockquote>
<p>
-2- <i>Requires:</i> <tt>remove_all_extents_t&lt;T&gt;</tt> shall be a complete type or (possibly <i>cv</i>-qualified) <tt>void</tt>.
<p/>
-3- <del><i>Effects:</i> <tt>is_literal_type</tt> has a base-characteristic of <tt>true_type</tt> if <tt>T</tt> is a literal type (3.9), 
and a basecharacteristic of <tt>false_type</tt> otherwise</del><ins><tt>is_literal_type&lt;T&gt;</tt> is a 
<tt>UnaryTypeTrait</tt> (20.15.1 [meta.rqmts]) with a <tt>BaseCharacteristic</tt> of <tt>true_type</tt> if <tt>T</tt> 
is a literal type (3.9 [basic.types]), and <tt>false_type</tt> otherwise</ins>.
<p/>
<ins>-?- The behavior of a program that adds specializations for <tt>is_literal_type</tt> or <tt>is_literal_type_v</tt> is 
undefined.</ins>
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2842" href="#2842">2842.</a> <tt>in_place_t</tt> check for <tt>optional::optional(U&amp;&amp;)</tt> should decay <tt>U</tt></h3>
<p><b>Section:</b> 20.6.3.1 [optional.ctor] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-12-13 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#optional.ctor">active issues</a> in [optional.ctor].</p>
<p><b>View all other</b> <a href="lwg-index.html#optional.ctor">issues</a> in [optional.ctor].</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 <tt>in_place_t</tt> is a normal tag type again, we need to decay <tt>U</tt> before doing the <tt>is_same_v</tt> check.
</p>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4618">N4618</a>.</p>

<ol>
<li><p>Edit 20.6.3.1 [optional.ctor] as indicated:</p>
<blockquote>
<pre>
template &lt;class U = T&gt;
  <i>EXPLICIT</i> constexpr optional(U&amp;&amp; v);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-22- <i>Remarks:</i> If <tt>T</tt>'s selected constructor is a <tt>constexpr</tt> constructor, this constructor shall be 
a <tt>constexpr</tt> constructor. This constructor shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;T, U&amp;&amp;&gt;</tt> is <tt>true</tt>, <tt>is_same_v&lt;<ins>decay_t&lt;</ins>U<ins>&gt;</ins>, 
in_place_t&gt;</tt> is <tt>false</tt>, and <tt>is_same_v&lt;optional&lt;T&gt;, decay_t&lt;U&gt;&gt;</tt> is <tt>false</tt>. 
The constructor is explicit if and only if <tt>is_convertible_v&lt;U&amp;&amp;, T&gt;</tt> is <tt>false</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2850" href="#2850">2850.</a> <tt>std::function</tt> move constructor does unnecessary work</h3>
<p><b>Section:</b> 20.14.13.2.1 [func.wrap.func.con] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2016-12-15 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func.con">active issues</a> in [func.wrap.func.con].</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>
Consider [func.wrap.func.con]/p5:
</p>
<blockquote><pre>
function(function&amp;&amp; f);
</pre>
<blockquote>
<p>
<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>
</blockquote>
</blockquote>
<p>
By my reading, this wording requires the move constructor of <tt>std::function</tt> to construct an entirely new target object. 
This is silly: in cases where the target is held in separately allocated memory (i.e. where the target doesn't fit in 
<tt>std::function</tt>'s internal buffer, if any), <tt>std::function</tt>'s move constructor can be implemented by simply 
transferring ownership of the existing target object (which is a simple pointer assignment), so this requirement forces an 
unnecessary constructor invocation and probably an unnecessary allocation (the latter can be avoided with something like 
double-buffering, but ew). Fixing this would technically be a visible change, but I have a hard time imagining reasonable 
code that would be broken by it, especially since both libstdc++ and libc++ already do the sensible thing, constructing a 
new target only if the target is held in an internal buffer, and otherwise assigning pointers.
</p>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4618">N4618</a>.</p>

<ol>
<li><p>Edit 20.14.13.2.1 [func.wrap.func.con]/5 as indicated:</p>

<blockquote class="note">
<p>
<i>Drafting note:</i> The "equivalent to ... before the construction" wording is based on the wording for <tt>MoveConstructible</tt>.
</p>
</blockquote>

<blockquote>
<pre>
function(function&amp;&amp; f);
</pre>
<blockquote>
<p>
-5- <i><del>Effects</del><ins>Postconditions</ins>:</i> If <tt>!f</tt>, <tt>*this</tt> has no target; otherwise, <del>move 
constructs the target of <tt>f</tt> into the target of <tt>*this</tt>, leaving <tt>f</tt></del><ins>the target of <tt>*this</tt> 
is equivalent to the target of <tt>f</tt> before the construction, and <tt>f</tt> is</ins> in a valid state with an 
unspecified value.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2853" href="#2853">2853.</a> Possible inconsistency in specification of <tt>erase</tt> in [vector.modifiers]</h3>
<p><b>Section:</b> 23.3.11.5 [vector.modifiers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Gerard Stone <b>Opened:</b> 2017-01-16 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.modifiers">active issues</a> in [vector.modifiers].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.modifiers">issues</a> in [vector.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>
In Table 87 (Sequence container requirements) <tt>erase(q)</tt> and <tt>erase(q1, q2)</tt> functions have the following requirements: 
</p>
<blockquote>
<p>
For <tt>vector</tt> and <tt>deque</tt>, <tt>T</tt> shall be <tt>MoveAssignable</tt>.
</p>
</blockquote>
<p>
On the other hand, section [vector.modifiers] has the following specification for erase functions (emphasis mine):
</p> 
<blockquote>
<p>
<i>Throws:</i> Nothing unless an exception is thrown by the <b>copy constructor</b>, <b>move constructor</b>, assignment
operator, or move assignment operator of <tt>T</tt>.
</p>
</blockquote>
<p>
Note that Table 87 requires <tt>T</tt> to be only <tt>MoveAssignable</tt>, it says nothing about <tt>T</tt> 
being copy- or move-constructible. It also says nothing about <tt>T</tt> being <tt>CopyInsertable</tt> and <tt>MoveInsertable</tt>, 
so why is this even there? The only reason might be so that vector could shrink, but in this case <tt>T</tt> should be required 
to be <tt>MoveInsertable</tt> or <tt>CopyInsertable</tt> into <tt>vector</tt>.
<p/>
On the other hand, we expect that vector will neither allocate, nor deallocate any memory during this operation, because in 
<i>Effects</i> it is specified that iterators/references shall be invalidated at or after the point of the erase.
<p/>
So to avoid any confusion, the proposed resolution is to remove mentions of <tt>T</tt>'s copy/move constructors 
from [vector.modifiers] paragraph 5.
</p>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4618">N4618</a>.</p>

<ol>
<li><p>Edit 23.3.11.5 [vector.modifiers] p5 as indicated:</p>
<blockquote>
<pre>
iterator erase(const_iterator position);
iterator erase(const_iterator first, const_iterator last);
void pop_back();
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Invalidates iterators and references at or after the point of the erase.
<p/>
-4- <i>Complexity:</i> The destructor of <tt>T</tt> is called the number of times equal to the number of the elements
erased, but the assignment operator of <tt>T</tt> is called the number of times equal to the number of elements
in the vector after the erased elements.
<p/>
-5- <i>Throws:</i> Nothing unless an exception is thrown by the <del>copy constructor, move constructor,</del> assignment
operator<del>,</del> or move assignment operator of <tt>T</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2855" href="#2855">2855.</a> <tt>std::throw_with_nested("string_literal")</tt></h3>
<p><b>Section:</b> 18.8.7 [except.nested] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2017-01-17 <b>Last modified:</b> 2017-02-03</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
<p><b>View all other</b> <a href="lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
[except.nested] says:
</p>
<blockquote>
<pre>
template &lt;class T&gt; [[noreturn]] void throw_with_nested(T&amp;&amp; t);
</pre>
<blockquote>
<p>
Let <tt>U</tt> be <tt>remove_reference_t&lt;T&gt;</tt>.
<p/>
<i>Requires:</i> <tt>U</tt> shall be <tt>CopyConstructible</tt>.
</p>
</blockquote>
</blockquote>
<p>
This forbids <tt>std::throw_with_nested("string literal")</tt> because <tt>T</tt> gets deduced as <tt>const char(&amp;)[15]</tt> 
and so <tt>U</tt> is <tt>const char[15]</tt> which is not <tt>CopyConstructible</tt>.
<p/>
A throw expression decays an array argument to a pointer (5.17 [expr.throw] p2) and so works fine with string literals. 
GCC's <tt>throw_with_nested</tt> also worked fine until I added a <tt>static_assert</tt> to enforce the 
<tt>CopyConstructible</tt> requirement.
<p/>
The same problem exists when throwing a function type, which should also decay:
</p>
<blockquote>
<pre>
#include &lt;exception&gt;

void f() { }

int main() {
  std::throw_with_nested(f);
}
</pre>
</blockquote>
<p>
(Note: LWG <a href="lwg-defects.html#1370">1370</a> added the <tt>remove_reference</tt>, which was a step in the right direction but not far enough.)
</p>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Priority 0</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4618">N4618</a>.</p>

<ol>
<li><p>Edit 18.8.7 [except.nested] as indicated:</p>
<blockquote>
<pre>
template &lt;class T&gt; [[noreturn]] void throw_with_nested(T&amp;&amp; t);
</pre>
<blockquote>
<p>
-6- Let <tt>U</tt> be <tt><del>remove_reference</del><ins>decay</ins>_t&lt;T&gt;</tt>.
<p/>
-7- <i>Requires:</i> <tt>U</tt> shall be <tt>CopyConstructible</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





</body>
</html>
