<!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 Albuquerque</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 Albuquerque</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">R0815R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2017-10-16 at 05:08:47 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="2779" href="#2779">2779</a><sup><a href="https://cplusplus.github.io/LWG/issue2779">(i)</a></sup>. [networking.ts] Relax requirements on buffer sequence iterators</h3>
<p><b>Section:</b> 99 [networking.ts::buffer.reqmts.mutablebuffersequence] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Vinnie Falco <b>Opened:</b> 2016-10-05 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>Not Prioritized
</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: networking.ts</b></p>
<p>
We propose to relax the <b>ForwardIterator</b> requirements of buffer sequences
in [networking.ts] by allowing buffer sequence iterators to return rvalues when
dereferenced, and skip providing <tt>operator-&gt;</tt>.
A paraphrased explanation of why the referential equality rules of <b>ForwardIterator</b>
are harmful to the buffer sequence requirements comes from <a href="http://wg21.link/n4128">N4128</a>,
3.3.7 "Ranges For The Standard Library":
</p>
<blockquote><p>
The [networking.ts] dependence on <b>ForwardIterator</b> in the buffer
sequence requirements ties together the traversal and access properties of
iterators. For instance, no forward iterator may return an <i>rvalue</i> proxy
when it is dereferenced; the <b>ForwardIterator</b> concept requires that
unary <tt>operator*</tt> return an lvalue. This problem has serious consequences
for lazy evaluation that applies transformations to buffer sequence elements on
the fly. If the transformation function does not return an <i>lvalue</i>, the
range's iterator can model no concept stronger than <b>InputIterator</b>, even
if the resulting iterator could in theory support
<b>BidirectionalIterator</b>. The result in practice is that most range
adaptors today will not be compatible with [networking.ts], thereby limiting the
types that [networking.ts] can be passed, for no good reason.
</p></blockquote>

<p>
Consider a user defined function <tt>trim</tt> which lazily adapts a
<tt>ConstBufferSequence</tt>, such that when iterating the buffers in the new
sequence, each buffer appears one byte shorter than in the underlying sequence:
</p>

<blockquote><pre>
#include &lt;boost/range/adaptor/transformed.hpp&gt;

struct trim
{
  using result_type = const_buffer;
  result_type operator()(const_buffer b)
  {
    return const_buffer{b.data(), b.size() - 1};
  }
};

template &lt;ConstBufferSequence&gt;
auto
trim(ConstBufferSequence const&amp; buffers)
{
  using namespace boost::adaptors;
  return buffers | transformed(trim{});
}
</pre></blockquote>

<p>
<tt>trim</tt> returns a <b>BidirectionalRange</b>, whose
<tt>const_iterator</tt> returns an rvalue when dereferenced. This breaks the
requirements of <b>ForwardIterator</b>. A solution that meets the referential equality 
rules of <b>ForwardIterator</b>, would be to evaluate the transformed
sequence upon construction (for example, by storing each transformed
<tt>const_buffer</tt> in a <tt>vector</tt>). Unfortunately this work-around is
more expensive since it would add heap allocation which the original example avoids.
</p>

<p>
The requirement of <b>InputIterator</b> <tt>operator-&gt;</tt> is also
unnecessary for buffer sequence iterators, and should be removed. Because
[networking.ts] only requires that a buffer sequence iterator's
<tt>value_type</tt> be convertible to <tt>const_buffer</tt> or
<tt>mutable_buffer</tt>, implementations of [networking.ts] cannot assume the
existence of any particular member functions or data members other than an
implicit conversion to <tt>const_buffer</tt> or <tt>mutable_buffer</tt>.
Removing the requirement for <tt>operator-&gt;</tt> to be present, provides
additional relief from the referential equality requirements of
<b>ForwardIterator</b> and allows transformations of buffer sequences to meet
the requirements of buffer sequences.
</p>

<p>
This proposal imposes no changes on existing implementations of [networking.ts].
It does not change anything in the standard. The proposal is precise, minimal,
and allows range adapters to transform buffer sequences in optimized, compatible
ways.
</p>

<p><i>[Issues processing Telecon 2016-10-07]</i></p>

<p>Status set to LEWG</p>

<p><i>[2017-02-21, Jonathan comments]</i></p>

<p>
The use of the term "strict aliasing" in the issue discussion is
misleading as that refers to type-based alias analysis in compilers,
but the rule for <tt>ForwardIterator</tt>s is related to referential equality
and not strict aliasing.
</p>

<p><i>[2017-02-22, Vinnie Falco comments]</i></p>

<p>
We have eliminated the use of the term "strict aliasing" from the discussion.
</p>

<p><i>[2017-07-10, Toronto, LEWG comments]</i></p>

<p>Status change: LEWG &rarr; Open.</p>
<p>
Forward to LWG with the note that they may want to use "input +"
instead of "bidirectional -". Unanimous yes.
</p>
<p><i>[2017-07 Toronto Wednesday night issue processing]</i></p>

<p>Status to Ready</p>


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

<ol>
<li>
<p>
Modify 16.2.1 [buffer.reqmts.mutablebuffersequence] as indicated:
</p>
<blockquote>
<p>
<del>An iterator type meeting the requirements for bidirectional
iterators (C++Std [bidirectional.iterators]) whose value type is
convertible to <tt>mutable_buffer</tt></del>
</p>
<p><ins>
An iterator type whose <tt>reference</tt> type is convertible to
<tt>mutable_buffer</tt>, and which satisfies all the requirements for
bidirectional iterators (C++Std [bidirectional.iterators]) except
that:
</ins></p>
<ol style="list-style-type:lower-alpha">
<li>
<ins>there is no requirement that <tt>operator-&gt;</tt> is provided, and</ins>
</li>
<li>
<ins>there is no requirement that <tt>reference</tt> be a reference type.</ins>
</li>
</ol>
</blockquote>
</li>

<li>
<p>
Modify 16.2.2 [buffer.reqmts.constbuffersequence] as indicated:
</p>
<blockquote>
<p>
<del>An iterator type meeting the requirements for bidirectional
iterators (C++Std [bidirectional.iterators]) whose value type is
convertible to <tt>const_buffer</tt>.</del>
</p>

<p>
<ins>An iterator type whose <tt>reference</tt> type is convertible to
<tt>const_buffer</tt>, and which satisfies all the requirements for
bidirectional iterators (C++Std [bidirectional.iterators]) except
that:
</ins></p>
<ol style="list-style-type:lower-alpha">
<li>
<ins>there is no requirement that <tt>operator-&gt;</tt> is provided, and</ins>
</li>
<li>
<ins>there is no requirement that <tt>reference</tt> be a reference type.</ins>
</li>
</ol>
</blockquote>
</li>
</ol>







<hr>
<h3><a name="2870" href="#2870">2870</a><sup><a href="https://cplusplus.github.io/LWG/issue2870">(i)</a></sup>. Default value of parameter <tt>theta</tt> of <tt>polar</tt> should be dependent</h3>
<p><b>Section:</b> 29.5.7 <a href="https://wg21.link/complex.value.ops">[complex.value.ops]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2017-02-03 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</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 JP 25</b></p>

<p>Parameter <tt>theta</tt> of <tt>polar</tt> has the type of the 
template parameter. Therefore, it needs to change the default initial value 
to <tt>T()</tt>. The change of the declaration of this function in 
29.5.1 <a href="https://wg21.link/complex.syn">[complex.syn]</a> is accompanied by this change.</p>

<p>
Proposed change:
</p>
<blockquote>
<pre>
template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = <del>0</del><ins>T()</ins>);
</pre>
</blockquote>

<p><i>[2017-02 pre-Kona]</i></p>

<p>
(twice)
</p>

<p><i>[
2017-06-27 Moved to Tentatively Ready after 7 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.</p>

<ol>
<li><p>Modify 29.5.1 <a href="https://wg21.link/complex.syn">[complex.syn]</a>, header <tt>&lt;complex&gt;</tt> synopsis, as indicated:</p>

<blockquote><pre>
template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp; = <del>0</del><ins>T()</ins>);
</pre></blockquote>
</li>

<li><p>Modify 29.5.7 <a href="https://wg21.link/complex.value.ops">[complex.value.ops]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = <del>0</del><ins>T()</ins>);
</pre>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2935" href="#2935">2935</a><sup><a href="https://cplusplus.github.io/LWG/issue2935">(i)</a></sup>. What should <tt>create_directories</tt> do when <tt>p</tt> already exists but is not a directory?</h3>
<p><b>Section:</b> 30.10.14.6 <a href="https://wg21.link/fs.op.create_directories">[fs.op.create_directories]</a>, 30.10.14.7 <a href="https://wg21.link/fs.op.create_directory">[fs.op.create_directory]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Billy Robert O'Neal III <b>Opened:</b> 2017-02-15 <b>Last modified:</b> 2017-07-15</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 <tt>create_directory</tt> and <tt>create_directories</tt> functions have a postcondition that says 
<tt>is_directory(p)</tt>, but it is unclear how they are supposed to provide this. Both of their effects say that 
they create a directory and return whether it was actually created. It is possible to interpret this as "if 
creation fails due to the path already existing, issue another system call to see if the path is a directory, 
and change the result if so" &mdash; but it seems unfortunate to require both Windows and POSIX to issue more 
system calls in this case.
<p/>
In email discussion Davis Herring and Billy O'Neal discussed this issue and agreed that this was probably 
unintentional. Special thanks for Jonathan Wakely's suggested change to <tt>create_directories</tt>' 
<em>Returns</em> clause.
</p>

<p><i>[2017-07 Toronto Thurs Issue Prioritization]</i></p>

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


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

<ol>
<li><p>Make the following edits to 30.10.14.6 <a href="https://wg21.link/fs.op.create_directories">[fs.op.create_directories]</a>:</p>

<blockquote>
<pre>
bool create_directories(const path&amp; p);
bool create_directories(const path&amp; p, error_code&amp; ec) noexcept;
</pre>
</blockquote>
<p>
-1- <em>Effects:</em><del> Establishes the postcondition by calling </del><ins>Calls </ins><tt>create_directory()</tt> for <del>any</del><ins>each</ins> element of <tt>p</tt> that does not exist.
<p/>
<del>-2- <em>Postconditions:</em> <tt>is_directory(p)</tt>.</del>
<p/>
-3- <em>Returns:</em> <tt>true</tt> if a new directory was created <ins>for the directory <tt>p</tt> resolves to</ins>, 
otherwise <tt>false</tt>. The signature with argument <tt>ec</tt> returns <tt>false</tt> if an error occurs.
<p/>
-4- <em>Throws:</em> As specified in 30.10.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a>.</p>
<p>
-5- <em>Complexity:</em> &#x1d4aa;(<i>n</i>) where <i>n</i> is the number of elements of <tt>p</tt><del> that do not exist</del>.
</p>
</li>

<li><p>Make the following edits to 30.10.14.7 <a href="https://wg21.link/fs.op.create_directory">[fs.op.create_directory]</a>:</p>

<blockquote>
<pre>
bool create_directory(const path&amp; p);
bool create_directory(const path&amp; p, error_code&amp; ec) noexcept;
</pre>
</blockquote>
<p>
-1- <em>Effects:</em><del> Establishes the postcondition by attempting to create</del><ins>Creates</ins> the directory 
<tt>p</tt> resolves to, as if by POSIX <tt>mkdir()</tt> with a second argument of <tt>static_cast&lt;int&gt;(perms::all)</tt>. 
Creation failure because <tt>p</tt> <del>resolves to an existing directory shall not be treated as</del><ins>already exists 
is not</ins> an error.
<p/>
<del>-2- <em>Postconditions:</em> <tt>is_directory(p)</tt>.</del>
<p/>
-3- <em>Returns:</em> <tt>true</tt> if a new directory was created, otherwise <tt>false</tt>. The signature with argument 
<tt>ec</tt> returns <tt>false</tt> if an error occurs.
<p/>
-4- <em>Throws:</em> As specified in 30.10.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a>.
</p>
</li>
</ol>







<hr>
<h3><a name="2941" href="#2941">2941</a><sup><a href="https://cplusplus.github.io/LWG/issue2941">(i)</a></sup>. &sect;[thread.req.timing] wording should apply to both member and namespace-level functions</h3>
<p><b>Section:</b> 33.2.4 <a href="https://wg21.link/thread.req.timing">[thread.req.timing]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Mcdougall <b>Opened:</b> 2017-03-07 <b>Last modified:</b> 2017-07-15</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.req.timing">issues</a> in [thread.req.timing].</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 33.2.4 <a href="https://wg21.link/thread.req.timing">[thread.req.timing]</a>, both /3 and /4 talk about "member
functions whose names end in <tt>_for</tt>" and "<tt>_until</tt>", but these clauses
also apply to <tt>this_thread::sleep_for()</tt> and <tt>this_thread::sleep_until()</tt>,
which are namespace-level functions (30.3.2).
</p>

<p><i>[2017-07 Toronto Wed Issue Prioritization]</i></p>

<p>Priority 0; Move to Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://wg21.link/n4640">N4640</a>.
</p>
<ol>
<li><p>Modify 33.2.4 <a href="https://wg21.link/thread.req.timing">[thread.req.timing]</a> as indicated::</p>
<blockquote>
<p>
[&hellip;]
<p/>
-3- The <del>member</del> functions whose names end in <tt>_for</tt> take an argument that specifies a duration. [&hellip;]
<p/>
-4- The <del>member</del> functions whose names end in <tt>_until</tt> take an argument that specifies a time point. [&hellip;]
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2944" href="#2944">2944</a><sup><a href="https://cplusplus.github.io/LWG/issue2944">(i)</a></sup>. LWG 2905 accidentally removed requirement that construction of the deleter doesn't throw an exception</h3>
<p><b>Section:</b> 23.11.1.2.1 <a href="https://wg21.link/unique.ptr.single.ctor">[unique.ptr.single.ctor]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-03-11 <b>Last modified:</b> 2017-07-15</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</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 wording simplification in LWG <a href="lwg-defects.html#2905">2905</a> accidentally deleted the
requirement that construction of the deleter doesn't throw an
exception. While this isn't the end of the world since any exception
will just run into the noexcept on the constructor and result in a
call to <tt>std::terminate()</tt>, the other <tt>unique_ptr</tt> constructors still have
a similar no-exception <i>Requires:</i> clause, leaving us in the odd
situation where throwing an exception results in undefined behavior
for some constructors and <tt>terminate()</tt> for others. If guaranteeing
<tt>std::terminate()</tt> on exception is desirable, that should be done across
the board.
<p/>
The proposed wording below simply restores the nothrow requirement
along with the <tt>Copy/MoveConstructible</tt> requirement. Wording for the
other alternative (guaranteed <tt>std::terminate()</tt>) can be produced if
desired.
</p>

<p><i>[2017-03-16, Daniel comments]</i></p>

<p>
The publication of the new working draft is awaited, before proposed wording against that
new working draft is formally possible.
</p>
  
<p><i>[2017-05-03, Tim comments]</i></p>

<p>
The suggested wording has been moved to the PR section now that the new working draft is available.
</p>

<p><i>[2017-07 Toronto Wed Issue Prioritization]</i></p>

<p>Priority 0; Move to Ready</p>


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

<ol>
<li><p>Insert a paragraph after 23.11.1.2.1 <a href="https://wg21.link/unique.ptr.single.ctor">[unique.ptr.single.ctor]</a> p11:</p>
<blockquote>
<pre>
unique_ptr(pointer p, <i>see below</i> d1) noexcept;
unique_ptr(pointer p, <i>see below</i> d2) noexcept;
</pre>
<blockquote>
<p>
-9- The signature of these constructors depends upon whether <tt>D</tt> is a reference type. If <tt>D</tt> 
is a non-reference type <tt>A</tt>, then the signatures are:
<p/>
[&hellip;]
<p/>
-10- If <tt>D</tt> is an lvalue reference type <tt>A&amp;</tt>, then the signatures are:
<p/>
[&hellip;]
<p/>
-11- If <tt>D</tt> is an lvalue reference type <tt>const A&amp;</tt>, then the signatures are:
<p/>
[&hellip;]
<p/>
<ins>-??- <i>Requires:</i> For the first constructor, if <tt>D</tt> is not a reference
type, <tt>D</tt> shall satisfy the requirements of <tt>CopyConstructible</tt> and such
construction shall not exit via an exception. For the second
constructor, if <tt>D</tt> is not a reference type, <tt>D</tt> shall satisfy the
requirements of <tt>MoveConstructible</tt> and such construction shall not exit
via an exception.</ins>
</p>
</blockquote>
</blockquote>
</li></ol>






<hr>
<h3><a name="2945" href="#2945">2945</a><sup><a href="https://cplusplus.github.io/LWG/issue2945">(i)</a></sup>. Order of template parameters in <tt>optional</tt> comparisons</h3>
<p><b>Section:</b> 23.6.8 <a href="https://wg21.link/optional.comp_with_t">[optional.comp_with_t]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2017-03-13 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#optional.comp_with_t">issues</a> in [optional.comp_with_t].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#2934">2934</a> added an additional template parameter to the comparison
operators for <tt>std::optional</tt>, but the ones that compare <tt>U</tt> with
<tt>optional&lt;T&gt;</tt> have the parameters backwards compared to the function parameters:
</p>

<blockquote>
<pre>
template &lt;class T, class U&gt; 
constexpr bool operator==(const U&amp;, const optional&lt;T&gt;&amp;);
</pre>
</blockquote>

<p>
Ville confirmed there's no particular reason for this, it's just how
he wrote the proposed resolution, but as this has normative effect we
should consider if we really want the template parameters and function
parameters to be in different orders or not.
</p>

<p><i>[2017-07-13, Casey Carter provides wording]</i></p>


<p><i>[2016-07, Toronto Thursday night issues processing]</i></p>

<p>Status to Ready</p>


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

<ol>
<li>
<p>
Modify 23.6.2 <a href="https://wg21.link/optional.syn">[optional.syn]</a>, <tt>&lt;optional&gt;</tt> synopsis, as indicated:
</p>
<blockquote>
<pre>
<i>// 23.6.8 <a href="https://wg21.link/optional.comp_with_t">[optional.comp_with_t]</a>, comparison with</i> T
template &lt;class T, class U&gt; constexpr bool operator==(const optional&lt;T&gt;&amp;, const U&amp;);
template &lt;class T, class U&gt; constexpr bool operator==(const <del>U</del><ins>T</ins>&amp;, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp;);
template &lt;class T, class U&gt; constexpr bool operator!=(const optional&lt;T&gt;&amp;, const U&amp;);
template &lt;class T, class U&gt; constexpr bool operator!=(const <del>U</del><ins>T</ins>&amp;, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp;);
template &lt;class T, class U&gt; constexpr bool operator&lt;(const optional&lt;T&gt;&amp;, const U&amp;);
template &lt;class T, class U&gt; constexpr bool operator&lt;(const <del>U</del><ins>T</ins>&amp;, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp;);
template &lt;class T, class U&gt; constexpr bool operator&lt;=(const optional&lt;T&gt;&amp;, const U&amp;);
template &lt;class T, class U&gt; constexpr bool operator&lt;=(const <del>U</del><ins>T</ins>&amp;, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp;);
template &lt;class T, class U&gt; constexpr bool operator&gt;(const optional&lt;T&gt;&amp;, const U&amp;);
template &lt;class T, class U&gt; constexpr bool operator&gt;(const <del>U</del><ins>T</ins>&amp;, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp;);
template &lt;class T, class U&gt; constexpr bool operator&gt;=(const optional&lt;T&gt;&amp;, const U&amp;);
template &lt;class T, class U&gt; constexpr bool operator&gt;=(const <del>U</del><ins>T</ins>&amp;, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp;);
</pre>
</blockquote>
</li>

<li>
<p>
Modify 23.6.8 <a href="https://wg21.link/optional.comp_with_t">[optional.comp_with_t]</a> as indicated:
</p>
<blockquote>
<pre>
template &lt;class T, class U&gt; constexpr bool operator==(const <del>U</del><ins>T</ins>&amp; v, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp; x);
</pre>
<blockquote>
<p>
-3- [&hellip;]
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template &lt;class T, class U&gt; constexpr bool operator!=(const <del>U</del><ins>T</ins>&amp; v, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp; x);
</pre>
<blockquote>
<p>
-7- [&hellip;]
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template &lt;class T, class U&gt; constexpr bool operator&lt;(const <del>U</del><ins>T</ins>&amp; v, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp; x);
</pre>
<blockquote>
<p>
-11- [&hellip;]
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template &lt;class T, class U&gt; constexpr bool operator&lt;=(const <del>U</del><ins>T</ins>&amp; v, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp; x);
</pre>
<blockquote>
<p>
-15- [&hellip;]
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template &lt;class T, class U&gt; constexpr bool operator&gt;(const <del>U</del><ins>T</ins>&amp; v, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp; x);
</pre>
<blockquote>
<p>
-19- [&hellip;]
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template &lt;class T, class U&gt; constexpr bool operator&gt;=(const <del>U</del><ins>T</ins>&amp; v, const optional&lt;<del>T</del><ins>U</ins>&gt;&amp; x);
</pre>
<blockquote>
<p>
-23- [&hellip;]
</p>
</blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2948" href="#2948">2948</a><sup><a href="https://cplusplus.github.io/LWG/issue2948">(i)</a></sup>. <tt>unique_ptr</tt> does not define <tt>operator&lt;&lt;</tt> for stream output</h3>
<p><b>Section:</b> 23.11.1 <a href="https://wg21.link/unique.ptr">[unique.ptr]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2017-03-19 <b>Last modified:</b> 2017-07-15</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</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>shared_ptr</tt> does define <tt>operator&lt;&lt;</tt>, and <tt>unique_ptr</tt> should too, for consistency and usability reasons.
</p>

<p><i>[2017-07 Toronto Wed Issue Prioritization]</i></p>

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


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://wg21.link/n4659">N4659</a>.
</p>
<ol>
<li><p>Change 23.10.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a>, header <tt>&lt;memory&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  [&hellip;]
  
  <i>// 23.11.1 <a href="https://wg21.link/unique.ptr">[unique.ptr]</a>, class template unique_ptr</i>
  [&hellip;]
  template &lt;class T, class D&gt;
  bool operator&gt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; y);
  
  <ins>template&lt;class E, class T, class Y, class D&gt;
  basic_ostream&lt;E, T&gt;&amp; operator&lt;&lt; (basic_ostream&lt;E, T&gt;&amp; os, const unique_ptr&lt;Y, D&gt;&amp; p);</ins>
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Change 23.11.1 <a href="https://wg21.link/unique.ptr">[unique.ptr]</a>, class template <tt>unique_ptr</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  [&hellip;]
  template &lt;class T, class D&gt;
  bool operator&gt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; y);
  
  <ins>template&lt;class E, class T, class Y, class D&gt;
  basic_ostream&lt;E, T&gt;&amp; operator&lt;&lt; (basic_ostream&lt;E, T&gt;&amp; os, const unique_ptr&lt;Y, D&gt;&amp; p);</ins>
}
</pre>
</blockquote>
</li>

<li><p>Add a new subclause following subclause 23.11.1.5 <a href="https://wg21.link/unique.ptr.special">[unique.ptr.special]</a> as indicated:</p>

<blockquote>
<p>
<ins>23.11.1.?? <tt>unique_ptr</tt> I/O [unique.ptr.io]</ins>
</p>
<pre>
<ins>template&lt;class E, class T, class Y, class D&gt;
  basic_ostream&lt;E, T&gt;&amp; operator&lt;&lt; (basic_ostream&lt;E, T&gt;&amp; os, const unique_ptr&lt;Y, D&gt;&amp; p);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> Equivalent to <tt>os &lt;&lt; p.get();</tt></ins>
<p/>
<ins>-?- <i>Returns</i>: <tt>os</tt>.</ins>
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless <tt>os &lt;&lt; p.get()</tt> 
is a valid expression.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2950" href="#2950">2950</a><sup><a href="https://cplusplus.github.io/LWG/issue2950">(i)</a></sup>. <tt>std::byte</tt> operations are misspecified</h3>
<p><b>Section:</b> 21.2.5 <a href="https://wg21.link/support.types.byteops">[support.types.byteops]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Thomas K&ouml;ppe <b>Opened:</b> 2017-03-24 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>1
</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 operations for <tt>std::byte</tt> (21.2.5 <a href="https://wg21.link/support.types.byteops">[support.types.byteops]</a>) are currently specified to have undefined 
behaviour in general cases, since the type of the expression <i>expr</i> that appears in <tt>return byte(<i>expr</i>)</tt> is 
obtained by the arithmetic conversion rules and has higher conversion rank than <tt>unsigned char</tt>. Therefore, the 
value of the expression may be outside the range of the enum (for example, consider <tt>~0</tt>), and by 
8.2.9 <a href="https://wg21.link/expr.static.cast">[expr.static.cast]</a> p10 the conversion results in undefined behaviour.
<p/>
I believe the original intent of the specification could be expressed correctly with the following, more verbose sequence 
of casts. I will only give one representative example:
</p>
<blockquote>
<pre>
byte operator&lt;&lt;(byte b, IntType shift)
</pre>
<blockquote>
<p>
Equivalent to: <tt>return byte(static_cast&lt;unsigned char&gt;(static_cast&lt;unsigned char&gt;(b) &lt;&lt; shift));</tt>
</p>
</blockquote>
</blockquote>

<p><i>[
2017-06-27 P1 after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[2017-06-28, STL comments and provides wording]</i></p>

<p>
This proposed resolution performs its work in <tt>unsigned int</tt>, which is immune to promotion. For <tt>op=</tt>, 
I'm avoiding unnecessary verbosity.
<p/>
It stylistically uses <tt>static_cast</tt>s instead of functional-style casts. All of the <tt>static_cast</tt>s are 
intentional, although not all of them are strictly necessary. I felt that it was simpler to always follow the 
same pattern for type conversions, instead of skipping <tt>static_cast</tt>s by taking advantage of the possible 
ranges of values. (I could prepare an alternative PR to avoid unnecessary casts.) I'm not <tt>static_cast</tt>ing 
the shift arguments, because of how 8.8 <a href="https://wg21.link/expr.shift">[expr.shift]</a> works.
<p/>
For <tt>to_integer()</tt>, there's a tiny question. According to 8.2.9 <a href="https://wg21.link/expr.static.cast">[expr.static.cast]</a>/9, 
<tt>static_cast</tt>ing from <tt>[128, 255]</tt> bytes to <tt>signed</tt> (behavior) <tt>char</tt>s triggers unspecified behavior, 
whereas using <tt>unsigned char</tt> as an intermediate type would produce implementation-defined behavior, 
7.8 <a href="https://wg21.link/conv.integral">[conv.integral]</a>/3. This question is basically theoretical, and it's unaffected by this proposed resolution 
(which is just changing a functional-style cast to a <tt>static_cast</tt>).
</p>

<p><i>[2016-07, Toronto Thursday night issues processing]</i></p>

<p>Status to Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>

<ol>
<li><p>Edit 21.2.5 <a href="https://wg21.link/support.types.byteops">[support.types.byteops]</a> as indicated:</p>

<blockquote>
<pre>
template &lt;class IntType&gt;
  constexpr byte&amp; operator&lt;&lt;=(byte&amp; b, IntType shift) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Remarks:</i> This function shall not participate in overload resolution unless <tt>is_integral_v&lt;IntType&gt;</tt> 
is <tt>true</tt>.
<p/>
-2- <i>Effects:</i> Equivalent to: <tt>return b = <ins>b &lt;&lt; shift</ins><del>byte(static_cast&lt;unsigned char&gt;(b) &lt;&lt; shift)</del>;</tt>
</p>
</blockquote>
<pre>
template &lt;class IntType&gt;
  constexpr byte operator&lt;&lt;(byte b, IntType shift) noexcept;
</pre>
<blockquote>
<p>
-3- <i>Remarks:</i> This function shall not participate in overload resolution unless <tt>is_integral_v&lt;IntType&gt;</tt> is
<tt>true</tt>.
<p/>
-4- <i>Effects:</i> Equivalent to: <tt>return 
<ins>static_cast&lt;byte&gt;(static_cast&lt;unsigned char&gt;(static_cast&lt;unsigned int&gt;(b) &lt;&lt; 
shift))</ins><del>byte(static_cast&lt;unsigned char&gt;(b) &lt;&lt; shift)</del>;</tt>
</p>
</blockquote>
<pre>
template &lt;class IntType&gt;
  constexpr byte&amp; operator&gt;&gt;=(byte&amp; b, IntType shift) noexcept;
</pre>
<blockquote>
<p>
-5- <i>Remarks:</i> This function shall not participate in overload resolution unless <tt>is_integral_v&lt;IntType&gt;</tt> is
<tt>true</tt>.
<p/>
-6- <i>Effects:</i> Equivalent to: <tt>return b = <ins>b &gt;&gt; shift</ins><del>byte(static_cast&lt;unsigned char&gt;(b) &gt;&gt; shift)</del>;</tt>
</p>
</blockquote>
<pre>
template &lt;class IntType&gt;
  constexpr byte operator&gt;&gt;(byte b, IntType shift) noexcept;
</pre>
<blockquote>
<p>
-7- <i>Remarks:</i> This function shall not participate in overload resolution unless <tt>is_integral_v&lt;IntType&gt;</tt> is
<tt>true</tt>.
<p/>
-8- <i>Effects:</i> Equivalent to: <tt>return 
<ins>static_cast&lt;byte&gt;(static_cast&lt;unsigned char&gt;(static_cast&lt;unsigned int&gt;(b) &gt;&gt; 
shift))</ins><del>byte(static_cast&lt;unsigned char&gt;(b) &gt;&gt; shift)</del>;</tt>
</p>
</blockquote>
<pre>
constexpr byte&amp; operator|=(byte&amp; l, byte r) noexcept;
</pre>
<blockquote>
<p>
-9- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return l = <ins>l | r</ins><del>byte(static_cast&lt;unsigned char&gt;(l) | static_cast&lt;unsigned char&gt;(r))</del>;
</pre></blockquote>
</blockquote>
<pre>
constexpr byte operator|(byte l, byte r) noexcept;
</pre>
<blockquote>
<p>
-10- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return <ins>static_cast&lt;byte&gt;(static_cast&lt;unsigned char&gt;(static_cast&lt;unsigned int&gt;(l) | 
static_cast&lt;unsigned int&gt;(r)))</ins><del>byte(static_cast&lt;unsigned char&gt;(l) | 
static_cast&lt;unsigned char&gt;(r))</del>;
</pre></blockquote>
</blockquote>
<pre>
constexpr byte&amp; operator&amp;=(byte&amp; l, byte r) noexcept;
</pre>
<blockquote>
<p>
-11- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return l = <ins>l &amp; r</ins><del>byte(static_cast&lt;unsigned char&gt;(l) &amp; static_cast&lt;unsigned char&gt;(r))</del>;
</pre></blockquote>
</blockquote>
<pre>
constexpr byte operator&amp;(byte l, byte r) noexcept;
</pre>
<blockquote>
<p>
-12- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return <ins>static_cast&lt;byte&gt;(static_cast&lt;unsigned char&gt;(static_cast&lt;unsigned int&gt;(l) &amp; 
static_cast&lt;unsigned int&gt;(r)))</ins><del>byte(static_cast&lt;unsigned char&gt;(l) &amp; 
static_cast&lt;unsigned char&gt;(r))</del>;
</pre></blockquote>
</blockquote>
<pre>
constexpr byte&amp; operator^=(byte&amp; l, byte r) noexcept;
</pre>
<blockquote>
<p>
-13- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return l = <ins>l ^ r</ins><del>byte(static_cast&lt;unsigned char&gt;(l) ^ static_cast&lt;unsigned char&gt;(r))</del>;
</pre></blockquote>
</blockquote>
<pre>
constexpr byte operator^(byte l, byte r) noexcept;
</pre>
<blockquote>
<p>
-14- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return <ins>static_cast&lt;byte&gt;(static_cast&lt;unsigned char&gt;(static_cast&lt;unsigned int&gt;(l) ^ 
static_cast&lt;unsigned int&gt;(r)))</ins><del>byte(static_cast&lt;unsigned char&gt;(l) ^ 
static_cast&lt;unsigned char&gt;(r))</del>;
</pre></blockquote>
</blockquote>
<pre>
constexpr byte operator~(byte b) noexcept;
</pre>
<blockquote>
<p>
-15- <i>Effects:</i> Equivalent to: <tt>return 
<ins>static_cast&lt;byte&gt;(static_cast&lt;unsigned char&gt;(~static_cast&lt;unsigned 
int&gt;(b)))</ins><del>byte(~static_cast&lt;unsigned char&gt;(b))</del>;</tt>
</p>
</blockquote>
<pre>
template &lt;class IntType&gt;
  constexpr IntType to_integer(byte b) noexcept;
</pre>
<blockquote>
<p>
-16- <i>Remarks:</i> This function shall not participate in overload resolution unless <tt>is_integral_v&lt;IntType&gt;</tt> is
<tt>true</tt>.
<p/>
-17- <i>Effects:</i> Equivalent to: <tt>return <ins>static_cast&lt;IntType&gt;</ins><del>IntType</del>(b);</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2952" href="#2952">2952</a><sup><a href="https://cplusplus.github.io/LWG/issue2952">(i)</a></sup>. <tt>iterator_traits</tt> should work for pointers to <i>cv</i> <tt>T</tt></h3>
<p><b>Section:</b> 27.4.1 <a href="https://wg21.link/iterator.traits">[iterator.traits]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Billy Robert O'Neal III <b>Opened:</b> 2017-03-27 <b>Last modified:</b> 2017-07-15</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#iterator.traits">active issues</a> in [iterator.traits].</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</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>iterator_traits</tt> accepts pointer to <tt>volatile T*</tt>, but then says that the <tt>value_type</tt> is 
<tt>volatile T</tt>, instead of <tt>T</tt>, which is inconsistent for what it does for pointer to <tt>const T</tt>. 
We should either reject <tt>volatile</tt> outright or give the right answer.
</p>

<p><i>[2017-03-30, David Krauss comments]</i></p>

<p>
<tt>volatile</tt> pointers may not be well-behaved random-access iterators. When simple access incurs side effects, 
the multiple-pass guarantee depends on underlying (hardware) semantics.
</p>

<p><i>[2017-07 Toronto Wed Issue Prioritization]</i></p>

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


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

<ol>
<li><p>Change 27.3 <a href="https://wg21.link/iterator.synopsis">[iterator.synopsis]</a> as indicated:</p>

<blockquote>
<pre>
<i>// 27.4 <a href="https://wg21.link/iterator.primitives">[iterator.primitives]</a>, primitives</i>
template&lt;class Iterator&gt; struct iterator_traits;
template&lt;class T&gt; struct iterator_traits&lt;T*&gt;;
<del>template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;;</del>
</pre>
</blockquote>
</li>

<li><p>Change 27.4.1 <a href="https://wg21.link/iterator.traits">[iterator.traits]</a> as indicated:</p>

<blockquote>
<p>
-3- It is specialized for pointers as
</p>
<blockquote>
<pre>
namespace std {
  template&lt;class T&gt; struct iterator_traits&lt;T*&gt; {
    using difference_type = ptrdiff_t;
    using value_type = <ins>remove_cv_t&lt;</ins>T<ins>&gt;</ins>;
    using pointer = T*;
    using reference = T&amp;;
    using iterator_category = random_access_iterator_tag;
  };
}
</pre>
</blockquote>
<p>
<del>and for pointers to <tt>const</tt> as</del>
</p>
<blockquote>
<pre>
<del>namespace std {
  template&lt;class T&gt; struct iterator_traits&lt;const T*&gt; {
    using difference_type = ptrdiff_t;
    using value_type = T;
    using pointer = const T*;
    using reference = const T&amp;;
    using iterator_category = random_access_iterator_tag;
  };
}</del>
</pre>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2953" href="#2953">2953</a><sup><a href="https://cplusplus.github.io/LWG/issue2953">(i)</a></sup>. LWG 2853 should apply to <tt>deque::erase</tt> too</h3>
<p><b>Section:</b> 26.3.8.4 <a href="https://wg21.link/deque.modifiers">[deque.modifiers]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-03-30 <b>Last modified:</b> 2017-07-15</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#deque.modifiers">issues</a> in [deque.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Most of the discussion of LWG <a href="lwg-defects.html#2853">2853</a> applies, mutatis mutandis, to
<tt>deque::erase</tt>. The relevant requirements table requires neither
<tt>Copy/MoveInsertable</tt> nor <tt>Copy/MoveConstructible</tt> for the erase
operations, so there's no way a copy/move constructor can safely be
called.
<p/>
And "assignment operator or move assignment operator" is just
"assignment operator", since "move assignment operator" is just a
species of "assignment operator".
</p>

<p><i>[2017-07 Toronto Wed Issue Prioritization]</i></p>

<p>Priority 0; Move to Ready</p>


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

<ol>
<li><p>Change 26.3.8.4 <a href="https://wg21.link/deque.modifiers">[deque.modifiers]</a> as indicated:</p>

<blockquote>
<pre>
iterator erase(const_iterator position);
iterator erase(const_iterator first, const_iterator last);
void pop_front();
void pop_back();
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> [&hellip;]
<p/>
-5- <i>Complexity:</i> The number of calls to the destructor of <tt>T</tt> is the same as the number of elements erased,
but the number of calls to the assignment operator of <tt>T</tt> is no more than the lesser of the number of
elements before the erased elements and the number of elements after the erased elements.
<p/>
-6- <i>Throws:</i> Nothing unless an exception is thrown by the <del>copy constructor, move constructor,</del> assignment
operator<del>, or move assignment operator</del> of <tt>T</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2964" href="#2964">2964</a><sup><a href="https://cplusplus.github.io/LWG/issue2964">(i)</a></sup>. Apparently redundant requirement for <tt>dynamic_pointer_cast</tt></h3>
<p><b>Section:</b> 23.11.2.2.9 <a href="https://wg21.link/util.smartptr.shared.cast">[util.smartptr.shared.cast]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-05-11 <b>Last modified:</b> 2017-07-11</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.cast">issues</a> in [util.smartptr.shared.cast].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Currently 23.11.2.2.9 <a href="https://wg21.link/util.smartptr.shared.cast">[util.smartptr.shared.cast]</a>/4 says:
</p>
<blockquote><p>
<i>Requires:</i> The expression <tt>dynamic_cast&lt;T*&gt;((U*)nullptr)</tt> shall be well
formed and shall have well defined behavior.
</p></blockquote>
<p>
A <tt>dynamic_cast</tt> of a null pointer, if well-formed, always has
well-defined behavior: it returns a null pointer. The second part is
therefore redundant as currently worded. The C++14 version, on the
other hand, requires <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> to have well-defined
behavior, which actually adds something: it requires the user to not
trigger the undefined case in [class.cdtor]/5, for instance.
</p>

<p><i>[2017-07 Toronto Monday issue prioritization]</i></p>

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


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

<ol>
<li>
<p>Edit 23.11.2.2.9 <a href="https://wg21.link/util.smartptr.shared.cast">[util.smartptr.shared.cast]</a> as indicated:</p>

<blockquote>
<pre>
shared_ptr&lt;T&gt; dynamic_pointer_cast(const shared_ptr&lt;U&gt;&amp; r) noexcept;
</pre>
<blockquote>
<p>
-4- <i>Requires:</i> The expression <tt>dynamic_cast&lt;T*&gt;((U*)0)</tt> shall be well formed<ins>. The 
expression <tt>dynamic_cast&lt;typename shared_ptr&lt;T&gt;::element_type*&gt;(r.get())</tt> shall be well 
formed</ins> and shall have well defined behavior.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2965" href="#2965">2965</a><sup><a href="https://cplusplus.github.io/LWG/issue2965">(i)</a></sup>. Non-existing <tt>path::native_string()</tt> in <tt>filesystem_error::what()</tt> specification</h3>
<p><b>Section:</b> 99 [filesystem_error.members] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2017-05-22 <b>Last modified:</b> 2017-07-11</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>
As pointed out by Jonathan Wakely and Bo Persson, 99 [filesystem_error.members]/7 refers to a non-existing
function <tt>path::native_string</tt>:
</p>
<blockquote><p>
<i>Returns:</i> A string containing <tt>runtime_error::what()</tt>. The exact format is unspecified. Implementations
are encouraged but not required to include <tt>path1.native_string()</tt> if not empty, 
<tt>path2.native_string()</tt> if not empty, and <tt>system_error::what()</tt> strings in the returned string.
</p></blockquote>
<p>
Existing implementations differ, as Jonathan also determined:
</p>
<ul>
<li><p>Boost.Filesystem uses <tt>path::string()</tt>.</p></li>
<li><p>Libstdc++ uses <tt>path::string()</tt>.</p></li>
<li><p>MSVC++/Dinkumware uses <tt>path::u8string()</tt>.</p></li>
<li><p>It seems that libc++ doesn't include the paths in <tt>what()</tt>.</p></li>
</ul>
<p>
We've had <tt>native_string()</tt> in the spec since <a href="http://wg21.link/n3239#filesystem_error-what">N3239</a> (where
it already didn't match any existing <tt>path</tt> function at that time).
<p/>
Before that it was <tt>file_string()</tt> in <a href="http://wg21.link/n1975#basic_filesystem_error-observers">N1975</a>
(within that specification <tt>path</tt> was a template that was parametrized in the character type).
<p/>
Since it can't be <tt>path::native()</tt> because that might be the wrong type, one of <tt>path::string()</tt> or 
<tt>path::u8string()</tt> seems appropriate.
<p/>
Albeit the wording is just a non-binding encouragement to implementations, the decision on this matter should not be
considered editorially due to the existing implementation variance. Any official resolution of the current state could
cause a reconsideration of existing implementations, and therefore it should be documented.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to <a href="http://wg21.link/n4659">N4659</a>.</p>

<ol>
<li>
<p>Edit 99 [filesystem_error.members] as indicated:</p>

<blockquote>
<pre>
const char* what() const noexcept override;
</pre>
<blockquote>
<p>
-7- <i>Returns:</i> A string containing <tt>runtime_error::what()</tt>. The exact format is unspecified. Implementations
are encouraged but not required to include <tt>path1.<del>native_</del>string()</tt> if not empty, 
<tt>path2.<del>native_</del>string()</tt> if not empty, and <tt>system_error::what()</tt> strings in the returned string.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2017-05-25, Jonathan comments and suggests an alternative resolution]</i></p>

<p>
The revised wording changes leave it up to the implementation which of the native format observers to use. The 
"if not empty" seems redundant, because if the path is empty then there's nothing to include anyway, but the 
proposed resolution preserves it.
</p>

<p><i>[2017-07 Toronto Monday issue prioritization]</i></p>

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


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

<ol>
<li>
<p>Edit 99 [filesystem_error.members] as indicated:</p>

<blockquote>
<pre>
const char* what() const noexcept override;
</pre>
<blockquote>
<p>
-7- <i>Returns:</i> A string containing <tt>runtime_error::what()</tt>. The exact format is unspecified. Implementations
are encouraged but not required to include <del><tt>path1.native_string()</tt> if not empty, 
<tt>path2.native_string()</tt> if not empty, and <tt>system_error::what()</tt> strings</del><ins>the 
<tt>system_error::what()</tt> string and the pathnames of <tt>path1</tt> and <tt>path2</tt> in the native format</ins> 
in the returned string.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2972" href="#2972">2972</a><sup><a href="https://cplusplus.github.io/LWG/issue2972">(i)</a></sup>. What is <tt>is_trivially_destructible_v&lt;int&gt;</tt>?</h3>
<p><b>Section:</b> 23.15.4.3 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2017-06-01 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The spec for <tt>is_trivially_destructible</tt> says the value is true if "<tt>is_destructible_v&lt;T&gt;</tt> is <tt>true</tt> 
and the indicated destructor is known to be trivial."
<p/>
For a case like <tt>is_trivially_destructible_v&lt;int&gt;</tt>, there is no indicated destructor, so it's unclear what value 
the trait would have but the most plausible reading of these words is that it should be <tt>false</tt>. However, I'm confident 
the intent is that this trait should yield <tt>true</tt> in that situation, and that's what all the implementations I can 
find actually do.
</p>

<p><i>[2017-06-14, Daniel and Jonathan provide wording]</i></p>


<p><i>[2017-07-05 Moved to Tentatively Ready after 5 positive votes on c++std-lib.]</i></p>



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

<ol>
<li><p>Change 23.15.4.3 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a>, Table 42 &mdash; "Type property predicates", as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 22 &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&gt;<br/>
struct is_trivially_destructible;</tt>
</td>

<td>
<tt>is_destructible_v&lt;T&gt;</tt> is
<tt>true</tt> and <del>the indicated
destructor is known to be
trivial</del><ins><tt>remove_all_extents_t&lt;T&gt;</tt> is 
either a non-class type or a class type with a trivial destructor</ins>.
</td>

<td>
<tt>T</tt> shall be a complete type,
<i>cv</i> <tt>void</tt>, or an array of
unknown bound.
</td>
</tr>

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

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





<hr>
<h3><a name="2976" href="#2976">2976</a><sup><a href="https://cplusplus.github.io/LWG/issue2976">(i)</a></sup>. Dangling <tt>uses_allocator</tt> specialization for <tt>packaged_task</tt></h3>
<p><b>Section:</b> 33.6.10 <a href="https://wg21.link/futures.task">[futures.task]</a>, 33.6.2 <a href="https://wg21.link/future.syn">[future.syn]</a>, 33.6.10.2 <a href="https://wg21.link/futures.task.nonmembers">[futures.task.nonmembers]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-06-13 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.task">issues</a> in [futures.task].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When LWG <a href="lwg-defects.html#2921">2921</a> removed allocator support from <tt>packaged_task</tt>, it forgot
to remove the <tt>uses_allocator</tt> partial specialization.
</p>

<p><i>[
2017-06-26 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>


<p><i>[2017-06-26, Billy O'Neal reopens]</i></p>

<p>
I think <a href="lwg-defects.html#2921">2921</a> was resolved in error. If <tt>promise&lt;T&gt;</tt> can have an allocator, there's no 
reason for <tt>packaged_task&lt;T&gt;</tt> to not have one. If we remove it from <tt>packaged_task</tt> we should 
remove it from <tt>promise</tt> as well.
<p/>
Note that I am not objecting to removing allocator support here, I'm objecting to the "remove it because this looks 
like <tt>std::function</tt>" case. <tt>packaged_task</tt> has none of the <tt>std::function</tt> problems because 
the function inside a given <tt>packaged_task</tt> is not reassignable.
<p/>
If LWG decides to remove allocator support here then there are more bits that need to be struck, e.g. 
<a href="http://eel.is/c++draft/futures#task.members-5.3">[futures.task.members] (5.3)</a>.
</p>

<p><i>[2017-06-26, Tim updates P/R to remove more dangling bits.]</i></p>

<p>
The additional point in the P/R effectively reverts the second part of the resolution of <a href="lwg-defects.html#2752">2752</a>.
<p/>
The alternative resolution for this issue is, of course, to just revert the resolution of 2921. In that case <a href="lwg-defects.html#2245">2245</a> needs to be reopened.
</p>

<p><i>[2016-07, Toronto Saturday afternoon issues processing]</i></p>

<p>Status to Ready</p>


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

<ol>
<li>
<p>Modify 33.6.2 <a href="https://wg21.link/future.syn">[future.syn]</a>, header <tt>&lt;future&gt;</tt> synopsis, and
33.6.10 <a href="https://wg21.link/futures.task">[futures.task]</a>, class template <tt>packaged_task</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
<del>template &lt;class R, class Alloc&gt;
struct uses_allocator&lt;packaged_task&lt;R&gt;, Alloc&gt;;</del>
</pre>
</blockquote>
</li>

<li>
<p>Modify 33.6.10.2 <a href="https://wg21.link/futures.task.nonmembers">[futures.task.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
<del>template &lt;class R, class Alloc&gt;
  struct uses_allocator&lt;packaged_task&lt;R&gt;, Alloc&gt;
    : true_type { };</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Requires:</i> <tt>Alloc</tt> shall be an Allocator (20.5.3.5).</del>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>Modify 33.6.10.1 <a href="https://wg21.link/futures.task.members">[futures.task.members]</a>/5 as indicated:</p>

<blockquote>
<pre>
template &lt;class F&gt;
  packaged_task(F&amp;&amp; F);
</pre>
<blockquote>
<p>
-2- <i>Requires:</i> [&hellip;]
</p>
<p>
-3- <i>Remarks:</i> [&hellip;]
</p>
<p>
-4- <i>Effects:</i> [&hellip;]
</p>
<p>
-5- <i>Throws:</i>
<blockquote>
<p> <del> &mdash; A</del><ins>a</ins>ny exceptions thrown by the copy or move constructor of <tt>f</tt><del>.</del><ins>, or</ins> </p>
<p> <del>&mdash; For the first version,</del> <tt>bad_alloc</tt> if memory for the internal data structures could not be allocated.</p>
<p> <del>&mdash; For the second version, any exceptions thrown by <tt>allocator_traits&lt;Allocator&gt;::template rebind_traits&lt;<i>unspecified</i>&gt;::allocate</tt>.</del></p>
</blockquote>
</p>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2977" href="#2977">2977</a><sup><a href="https://cplusplus.github.io/LWG/issue2977">(i)</a></sup>. <tt>unordered_<em>meow</em>::merge()</tt> has incorrect <i>Throws:</i> clause</h3>
<p><b>Section:</b> 26.2.7 <a href="https://wg21.link/unord.req">[unord.req]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-06-14 <b>Last modified:</b> 2017-07-11</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As pointed out in <a href="https://stackoverflow.com/q/44530264/2756719">this StackOverflow question</a>, 
<tt>unordered_{map,multimap,set,multiset}::merge()</tt> may need to rehash to maintain its 
<tt>max_load_factor</tt> invariant, which may require allocation, which may throw.
</p>

<p><i>[2017-07 Toronto Monday issue prioritization]</i></p>

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


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>

<ol>
<li><p> In 26.2.7 <a href="https://wg21.link/unord.req">[unord.req]</a>, edit Table 91 "Unordered associative container requirements" as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 91 &mdash; Unordered associative container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note<br />pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>
<tr>
<td>
<tt>a.merge(a2)</tt>
</td>
<td><tt>void</tt></td>
<td>
<i>Requires:</i> <tt>a.get_allocator() == a2.get_allocator()</tt>.<br />
Attempts to extract each element in <tt>a2</tt> and insert it into <tt>a</tt> using the hash function and key equality predicate of  <tt>a</tt>. In containers with unique keys, if there is an element in <tt>a</tt> with key equivalent to the key of an element from <tt>a2</tt>, then that element is not extracted from <tt>a2</tt>. <br />
<i>Postconditions:</i> Pointers and references to the transferred elements of <tt>a2</tt> refer to those same elements but as members of  <tt>a</tt>. Iterators referring to the transferred elements and all iterators referring to <tt>a</tt> will be invalidated, but iterators to elements remaining in <tt>a2</tt> will remain valid.<br/>
<del><i>Throws:</i> Nothing unless the hash function or key equality predicate throws.</del>
</td>
<td>
Average case &#x1d4aa;(<i>N</i>), where <i>N</i> is <tt>a2.size()</tt>.<br />
Worst case &#x1d4aa;(<i>N</i><tt>*a.size()+</tt><i>N</i>).
</td>
</tr>
<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2978" href="#2978">2978</a><sup><a href="https://cplusplus.github.io/LWG/issue2978">(i)</a></sup>. Hash support for <tt>pmr::string</tt> and friends</h3>
<p><b>Section:</b> 24.3.5 <a href="https://wg21.link/basic.string.hash">[basic.string.hash]</a>, 24.3.1 <a href="https://wg21.link/string.syn">[string.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-06-14 <b>Last modified:</b> 2017-07-11</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>
In most cases, <tt>std::pmr::<i>meow</i></tt> is a drop-in replacement for <tt>std::<i>meow</i></tt>. The exception is
<tt>std::pmr::{,w,u16,u32}string</tt>, because unlike their <tt>std::</tt> counterparts, they don't come with enabled 
<tt>std::hash</tt> specializations.
</p>
<p>
The P/R below simply adds <tt>std::hash</tt> specializations for those four typedefs. An alternative approach, for which wording can be
produced if desired, is to make the <tt>hash</tt> specializations for <tt>basic_string</tt> allocator-agnostic, similar to the partial
specialization of <tt>hash</tt> for <tt>vector&lt;bool&gt;</tt>.
</p>

<p><i>[2017-07 Toronto Monday issue prioritization]</i></p>

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


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>
<ol>
<li><p> Edit 24.3.1 <a href="https://wg21.link/string.syn">[string.syn]</a>, header <tt>&lt;string&gt;</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
<ins>  namespace pmr {
    template &lt;class charT, class traits = char_traits&lt;charT&gt;&gt;
      using basic_string = std::basic_string&lt;charT, traits, polymorphic_allocator&lt;charT&gt;&gt;;

    using string    = basic_string&lt;char&gt;;
    using u16string = basic_string&lt;char16_t&gt;;
    using u32string = basic_string&lt;char32_t&gt;;
    using wstring   = basic_string&lt;wchar_t&gt;;
  }</ins>
  
  // 24.3.5 <a href="https://wg21.link/basic.string.hash">[basic.string.hash]</a>, hash support
  template&lt;class T&gt; struct hash;
  template&lt;&gt; struct hash&lt;string&gt;;
  template&lt;&gt; struct hash&lt;u16string&gt;;
  template&lt;&gt; struct hash&lt;u32string&gt;;
  template&lt;&gt; struct hash&lt;wstring&gt;;
<ins>  template&lt;&gt; struct hash&lt;pmr::string&gt;;
  template&lt;&gt; struct hash&lt;pmr::u16string&gt;;
  template&lt;&gt; struct hash&lt;pmr::u32string&gt;;
  template&lt;&gt; struct hash&lt;pmr::wstring&gt;;</ins>

<del>  namespace pmr {
    template &lt;class charT, class traits = char_traits&lt;charT&gt;&gt;
      using basic_string = std::basic_string&lt;charT, traits, polymorphic_allocator&lt;charT&gt;&gt;;

    using string    = basic_string&lt;char&gt;;
    using u16string = basic_string&lt;char16_t&gt;;
    using u32string = basic_string&lt;char32_t&gt;;
    using wstring   = basic_string&lt;wchar_t&gt;;
  }</del>
</pre>
</blockquote>
</li>
<li><p> Edit 24.3.5 <a href="https://wg21.link/basic.string.hash">[basic.string.hash]</a> as indicated:</p>
<blockquote>
<pre>
  template&lt;&gt; struct hash&lt;string&gt;;
  template&lt;&gt; struct hash&lt;u16string&gt;;
  template&lt;&gt; struct hash&lt;u32string&gt;;
  template&lt;&gt; struct hash&lt;wstring&gt;;
<ins>  template&lt;&gt; struct hash&lt;pmr::string&gt;;
  template&lt;&gt; struct hash&lt;pmr::u16string&gt;;
  template&lt;&gt; struct hash&lt;pmr::u32string&gt;;
  template&lt;&gt; struct hash&lt;pmr::wstring&gt;;</ins>
</pre>
<blockquote>
<p>
  -1- If <tt>S</tt> is one of these string types, <tt>SV</tt> is the corresponding string view type, and <tt>s</tt> is an object of type <tt>S</tt>, then <tt>hash&lt;S&gt;()(s) == hash&lt;SV&gt;()(SV(s))</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2979" href="#2979">2979</a><sup><a href="https://cplusplus.github.io/LWG/issue2979">(i)</a></sup>. <tt>aligned_union</tt> should require complete object types</h3>
<p><b>Section:</b> 23.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-06-14 <b>Last modified:</b> 2017-07-11</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</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>aligned_union</tt>'s description doesn't, but should, require the types provided to be complete object types.
</p>

<p><i>[2017-07 Toronto Monday issue prioritization]</i></p>

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


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>

<ol>
<li><p> In 23.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a>, edit Table 50 "Other transformations" as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 50 &mdash; Other transformations</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>template &lt;size_t Len, class... Types&gt;<br />
struct aligned_union;</tt>
</td>
<td>
The member typedef <tt>type</tt> shall be a POD type suitable for use as uninitialized storage for any object whose type is listed in <tt>Types</tt>; its size shall be at least <tt>Len</tt>. The static member <tt>alignment_value</tt> shall be an integral constant of type <tt>size_t</tt> whose value is the strictest alignment of all types listed in <tt>Types</tt>. <br />
<i>Requires:</i> At least one type is provided. <ins>Each type in the parameter pack <tt>Types</tt> shall be a complete object type.</ins>
</td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="2980" href="#2980">2980</a><sup><a href="https://cplusplus.github.io/LWG/issue2980">(i)</a></sup>. Cannot <tt>compare_exchange</tt> empty pointers</h3>
<p><b>Section:</b> 23.11.2.6 <a href="https://wg21.link/util.smartptr.shared.atomic">[util.smartptr.shared.atomic]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2017-06-15 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.atomic">issues</a> in [util.smartptr.shared.atomic].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
[util.smartptr.shared.atomic] p35 states that two shared pointers are equivalent if
they store the same pointer value, and share <em>ownership</em>. As empty shared pointers
never share ownership, it is not possible to replace an empty shared pointer using
the atomic <tt>compare_exchange</tt> API.
<p/>
Note that through aliasing, empty shared pointers may still point to different objects,
and any resolution must allow for that case too.
</p>

<p><i>[
2017-06-26 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>

<ol>
<li><p>Edit 23.11.2.6 <a href="https://wg21.link/util.smartptr.shared.atomic">[util.smartptr.shared.atomic]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt;
  bool atomic_compare_exchange_weak_explicit(
    shared_ptr&lt;T&gt;* p, shared_ptr&lt;T&gt;* v, shared_ptr&lt;T&gt; w,
    memory_order success, memory_order failure);
template&lt;class T&gt;
  bool atomic_compare_exchange_strong_explicit(
    shared_ptr&lt;T&gt;* p, shared_ptr&lt;T&gt;* v, shared_ptr&lt;T&gt; w,
    memory_order success, memory_order failure);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-35- <i>Remarks:</i> Two <tt>shared_ptr</tt> objects are equivalent if they store the same pointer value and share
ownership<ins>, or if they store the same pointer value and both are empty</ins>. The weak form may fail spuriously. 
See 32.6.1.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2981" href="#2981">2981</a><sup><a href="https://cplusplus.github.io/LWG/issue2981">(i)</a></sup>. Remove redundant deduction guides from standard library</h3>
<p><b>Section:</b> 23.14.5 <a href="https://wg21.link/refwrap">[refwrap]</a>, 33.4.4.1 <a href="https://wg21.link/thread.lock.guard">[thread.lock.guard]</a>, 33.4.4.2 <a href="https://wg21.link/thread.lock.scoped">[thread.lock.scoped]</a>, 33.4.4.3 <a href="https://wg21.link/thread.lock.unique">[thread.lock.unique]</a>, 33.4.4.4 <a href="https://wg21.link/thread.lock.shared">[thread.lock.shared]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2017-06-15 <b>Last modified:</b> 2017-07-11</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#refwrap">active issues</a> in [refwrap].</p>
<p><b>View all other</b> <a href="lwg-index.html#refwrap">issues</a> in [refwrap].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are several deduction guides added to the standard library by <a href="https://wg21.link/p0433r2">P0433R2</a> 
that have no effect probably because LWG had not considered late changes to core wording that automatically adds 
a "copy deduction candidate" (16.3.1.8 <a href="https://wg21.link/over.match.class.deduct">[over.match.class.deduct]</a>) that renders these explicit guides moot. 
</p>

<p><i>[2017-07 Toronto Monday issue prioritization]</i></p>

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


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>

<ol>
<li><p>Edit 23.14.5 <a href="https://wg21.link/refwrap">[refwrap]</a>, end of class template <tt>reference_wrapper</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<del>template&lt;class T&gt;
  reference_wrapper(reference_wrapper&lt;T&gt;) -&gt; reference_wrapper&lt;T&gt;;</del>
</pre>
</blockquote>
</li>

<li><p>Edit 33.4.4.1 <a href="https://wg21.link/thread.lock.guard">[thread.lock.guard]</a>, end of class template <tt>lock_guard</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<del>template&lt;class Mutex&gt; lock_guard(lock_guard&lt;Mutex&gt;) -&gt; lock_guard&lt;Mutex&gt;;</del>
</pre>
</blockquote>
</li>

<li><p>Edit 33.4.4.2 <a href="https://wg21.link/thread.lock.scoped">[thread.lock.scoped]</a>, end of class template <tt>scoped_lock</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<del>template&lt;class... MutexTypes&gt;
  scoped_lock(scoped_lock&lt;MutexTypes...&gt;) -&gt; scoped_lock&lt;MutexTypes...&gt;;</del>
</pre>
</blockquote>
</li>

<li><p>Edit 33.4.4.3 <a href="https://wg21.link/thread.lock.unique">[thread.lock.unique]</a>, end of class template <tt>unique_lock</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<del>template&lt;class Mutex&gt; unique_lock(unique_lock&lt;Mutex&gt;) -&gt; unique_lock&lt;Mutex&gt;;</del>
</pre>
</blockquote>
</li>

<li><p>Edit 33.4.4.4 <a href="https://wg21.link/thread.lock.shared">[thread.lock.shared]</a>, end of class template <tt>shared_lock</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<del>template&lt;class Mutex&gt; shared_lock(shared_lock&lt;Mutex&gt;) -&gt; shared_lock&lt;Mutex&gt;;</del>
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2982" href="#2982">2982</a><sup><a href="https://cplusplus.github.io/LWG/issue2982">(i)</a></sup>. Making <tt>size_type</tt> consistent in associative container deduction guides</h3>
<p><b>Section:</b> 26.5.6.1 <a href="https://wg21.link/unord.set.overview">[unord.set.overview]</a>, 26.5.7.1 <a href="https://wg21.link/unord.multiset.overview">[unord.multiset.overview]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2017-06-16 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Due to an incompletely implemented change in Kona, some of the size_type deduction guides say something like:
</p>
<blockquote><p>
A <tt>size_type</tt> parameter type in an <tt>unordered_set</tt> deduction guide refers to the <tt>size_type</tt> 
member type of the primary <tt>unordered_set</tt> template
</p></blockquote>
<p>
while others say
</p>
<blockquote><p>
A <tt>size_type</tt> parameter type in an <tt>unordered_map</tt> deduction guide refers to the <tt>size_type</tt> 
member type of the type deduced by the deduction guide.
</p></blockquote>
<p>
Clearly they should both be the same. My recollection is that the intent of the committee was to change them all 
to be the latter. Note, however, that this issue may be mooted if the suggestions in the upcoming 
<a href="https://wg21.link/p0433r3">P0433R3</a> paper are adopted as a DR in Toronto.
</p>

<p><i>[2017-07 Toronto Monday issue prioritization]</i></p>

<p>Priority 2; Mike is preparing an updated paper &mdash; currently named <a href="https://wg21.link/p0433r3">P0433R3</a>.</p>

<p><i>[2016-07, Toronto Saturday afternoon issues processing]</i></p>

<p>Status to Ready; Marshall to check with Mike about his paper</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>

<ol>
<li><p>Edit 26.5.6.1 <a href="https://wg21.link/unord.set.overview">[unord.set.overview]</a> as indicated:</p>

<blockquote>
<p>
-4- A <tt>size_type</tt> parameter type in an <tt>unordered_set</tt> deduction guide refers to the <tt>size_type</tt> 
member type of the <del>primary <tt>unordered_set</tt> template</del><ins>type deduced by the deduction guide</ins>.
</p>
</blockquote>
</li>

<li><p>Edit 26.5.7.1 <a href="https://wg21.link/unord.multiset.overview">[unord.multiset.overview]</a> as indicated:</p>

<blockquote>
<p>
-4- A <tt>size_type</tt> parameter type in an <tt>unordered_multiset</tt> deduction guide refers to the <tt>size_type</tt> 
member type of the <del>primary <tt>unordered_multiset</tt> template</del><ins>type deduced by the deduction guide</ins>.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2988" href="#2988">2988</a><sup><a href="https://cplusplus.github.io/LWG/issue2988">(i)</a></sup>. Clause 32 cleanup missed one <tt>typename</tt></h3>
<p><b>Section:</b> 32.2 <a href="https://wg21.link/atomics.syn">[atomics.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2017-06-25 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#atomics.syn">active issues</a> in [atomics.syn].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.syn">issues</a> in [atomics.syn].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/p0558r1">P0558R1</a> missed updating one of the <tt>std::atomic_exchange</tt> 
signatures to avoid independent deduction for <tt>T</tt> on the second parameter.
</p>

<p><i>[
2017-06-26 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>

<ol>
<li><p>Edit 32.2 <a href="https://wg21.link/atomics.syn">[atomics.syn]</a>, header <tt>&lt;atomic&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt;
T atomic_exchange(volatile atomic&lt;T&gt;*, <ins>typename atomic&lt;</ins>T<ins>&gt;::value_type</ins>) noexcept;
</pre>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="2993" href="#2993">2993</a><sup><a href="https://cplusplus.github.io/LWG/issue2993">(i)</a></sup>. <tt>reference_wrapper&lt;T&gt;</tt> conversion from <tt>T&amp;&amp;</tt></h3>
<p><b>Section:</b> 23.14.5 <a href="https://wg21.link/refwrap">[refwrap]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-06-28 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#refwrap">active issues</a> in [refwrap].</p>
<p><b>View all other</b> <a href="lwg-index.html#refwrap">issues</a> in [refwrap].</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>reference_wrapper&lt;T&gt;</tt> has a deleted constructor taking <tt>T&amp;&amp;</tt> in order to
prevent accidentally wrapping an rvalue (which can otherwise happen with the 
<tt>reference_wrapper(T&amp;)</tt> constructor if <tt>T</tt> is a non-<tt>volatile</tt>
<tt>const</tt>-qualified type). Unfortunately, a deleted constructor can still
be used to form implicit conversion sequences, so the deleted <tt>T&amp;&amp;</tt>
constructor has the (presumably unintended) effect of creating an implicit conversion sequence from 
a <tt>T</tt> rvalue to a <tt>reference_wrapper&lt;T&gt;</tt>, even though such a conversion would be
ill-formed if actually used. This is visible in overload resolution:
</p>
<blockquote><pre>
void meow(std::reference_wrapper&lt;int&gt;); //#1
void meow(convertible_from_int); //#2
meow(0); // <span style="color:#C80000;font-weight:bold">error, ambiguous</span>; would unambiguously call #2 if #1 instead took int&amp;
</pre></blockquote>
<p>
and in conditional expressions (and hence <tt>std::common_type</tt>) after <a href="https://wg21.link/cwg1895">core issue 1895</a>:
</p>
<blockquote><pre>
std::reference_wrapper&lt;int&gt; purr();

auto x = true? purr() : 0; // <span style="color:#C80000;font-weight:bold">error, ambiguous:</span> ICS exists from int prvalue to 
                           // reference_wrapper&lt;int&gt; and from reference_wrapper&lt;int&gt; to int

using t = std::common_type_t&lt;std::reference_wrapper&lt;int&gt;, int&gt;; // <span style="color:#C80000;font-weight:bold">error:</span> no member 'type' because the conditional 
                                                                // expression is ill-formed
</pre></blockquote>
<p>
The latter in turn interferes with the use of <tt>reference_wrapper</tt> as a
proxy reference type with proxy iterators.
<p/>
We should ensure that there is no implicit conversion sequence from <tt>T</tt>
rvalues to <tt>reference_wrapper&lt;T&gt;</tt>, not just that the conversion will be
ill-formed when used. This can be done by using a suitably constrained
constructor template taking a forwarding reference instead of the
current pair of constructors taking <tt>T&amp;</tt> and <tt>T&amp;&amp;</tt>.
</p>
<p><i>[2017-06-29, Tim adds P/R and comments]</i></p>

<p>
The draft P/R below uses a conditional <tt>noexcept</tt> specification to ensure that converting a <tt>T&amp;</tt> to
a <tt>reference_wrapper&lt;T&gt;</tt> remains <tt>noexcept</tt> and make it not usable when the source type is a 
<tt>reference_wrapper</tt> of the same type so as to avoid affecting <tt>is_trivially_constructible</tt>. It adds a deduction
guide as the new constructor template will not support class template argument deduction.
<p/>
The constructor template has the additional effect of making <tt>reference_wrapper&lt;T&gt;</tt> convertible from everything
that is convertible to <tt>T&amp;</tt>. This implies, for instance, that <tt>reference_wrapper&lt;int&gt;</tt> is now
convertible to <tt>reference_wrapper&lt;const int&gt;</tt> when it wasn't before (the conversion would have required 
two user-defined conversions previously). This more closely emulates the behavior of an actual reference, but does represent
a change to the existing behavior.
<p/>
If perfectly emulating the existing behavior is desired, a conditionally-explicit constructor that is only implicit if 
<tt>T</tt> is reference-compatible with <tt>remove_reference_t&lt;U&gt;</tt> (see 11.6.3 <a href="https://wg21.link/dcl.init.ref">[dcl.init.ref]</a>) can be used.
</p>

<p><i>[2017-07 Toronto Tuesday PM issue prioritization]</i></p>

<p>Priority 3; what else in the library does this affect? <tt>ref</tt> or <tt>cref</tt>?</p>

<p><i>[2016-07, Toronto Saturday afternoon issues processing]</i></p>

<p>Status to Ready.</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>
<ol>
<li><p>Edit 23.14.5 <a href="https://wg21.link/refwrap">[refwrap]</a>, class template <tt>reference_wrapper</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
  template &lt;class T&gt; class reference_wrapper {
    [&hellip;]
    // construct/copy/destroy
<del>    reference_wrapper(T&amp;) noexcept;
    reference_wrapper(T&amp;&amp;) = delete;    // do not bind to temporary objects</del>
<ins>    template &lt;class U&gt;
      reference_wrapper(U&amp;&amp;) noexcept(<i>see below</i>);</ins>
    [&hellip;]
  };
<ins>  template &lt;class T&gt;
  reference_wrapper(T&amp;) -&gt; reference_wrapper&lt;T&gt;;</ins>
  [&hellip;]
}
</pre>
</blockquote>
</li>
<li><p>Edit 23.14.5.1 <a href="https://wg21.link/refwrap.const">[refwrap.const]</a>/1 as indicated:</p>
<blockquote>
<pre>
<del>reference_wrapper(T&amp; t) noexcept;</del>
</pre>
<blockquote>
<p><del>-1- <i>Effects:</i> Constructs a <tt>reference_wrapper</tt> object that stores a reference to <tt>t</tt>.</del></p>
</blockquote>
<pre>
<ins>template&lt;class U&gt;
  reference_wrapper(U&amp;&amp; u) noexcept(<i>see below</i>);</ins>
</pre>
<blockquote>
<p><ins>
-?- <i>Remarks:</i> Let <tt><i>FUN</i></tt> denote the exposition-only functions</ins>
<blockquote><pre>
<ins>void <i>FUN</i>(T&amp;) noexcept;
void <i>FUN</i>(T&amp;&amp;) = delete;</ins>
</pre></blockquote>
<ins>This constructor shall not participate in overload resolution unless the expression <tt><i>FUN</i>(declval&lt;U&gt;())</tt> is well-formed
and <tt>is_same_v&lt;decay_t&lt;U&gt;, reference_wrapper&gt;</tt> is <tt>false</tt>.
The expression inside <tt>noexcept</tt> is equivalent to <tt>noexcept(<i>FUN</i>(declval&lt;U&gt;()))</tt>.</ins>
<p/>
<ins>-?- <i>Effects:</i> Creates a variable <tt>r</tt> as if by <tt>T&amp; r = std::forward&lt;U&gt;(u)</tt>, then constructs a
<tt>reference_wrapper</tt> object that stores a reference to <tt>r</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="2998" href="#2998">2998</a><sup><a href="https://cplusplus.github.io/LWG/issue2998">(i)</a></sup>. Requirements on function objects passed to <tt>{forward_,}list</tt>-specific algorithms</h3>
<p><b>Section:</b> 26.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a>, 26.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-07-07 <b>Last modified:</b> 2017-07-11</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#list.ops">active issues</a> in [list.ops].</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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Some specialized algorithms for <tt>forward_list</tt> and <tt>list</tt> take template parameters named <tt>Predicate</tt>, 
<tt>BinaryPredicate</tt>, or <tt>Compare</tt>. 
However, there's no wording importing the full requirements for template type parameters with such names from 
28.3 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a> and 28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a>,
which means, for instance, that there appears to be no rule prohibiting <tt>Compare</tt> from modifying its arguments, 
because we only refer to 28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a> for the definition of strict weak ordering. Is that intended?
</p>

<p><i>[2017-07 Toronto Tuesday PM issue prioritization]</i></p>

<p>Priority 0; status to Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4659">N4659</a>.
</p>

<ol>
<li><p>Edit 26.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> as indicated:</p>
<blockquote>
<p>-1- Since lists allow fast insertion and erasing from the middle of a list, certain operations are provided specifically 
for them.<sup>259)</sup> <ins>In this subclause, arguments for a template parameter named <tt>Predicate</tt> or 
<tt>BinaryPredicate</tt> shall meet the corresponding requirements in 28.3 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a>.
For <tt>merge</tt> and <tt>sort</tt>, the definitions and requirements in 28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a> apply.</ins>
</p>
</blockquote>
</li>

<li><p>Edit 26.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> as indicated:</p>
<blockquote>
<pre>
void merge(list&amp; x);
void merge(list&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&amp; x, Compare comp);
template &lt;class Compare&gt; void merge(list&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>-22- <i>Requires:</i> <del><tt>comp</tt> shall define a strict weak ordering (28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a>), and b</del><ins>B</ins>oth the list and the argument list shall be sorted
<del>according to this ordering</del><ins>with respect to the comparator <tt>operator&lt;</tt> (for the first two overloads) or <tt>comp</tt> (for the last two overloads)</ins>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Delete 26.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a>/28 as redundant:</p>
<blockquote>
<pre>
void sort();
template &lt;class Compare&gt; void sort(Compare comp);
</pre>
<blockquote>
<p>
<del>-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 (28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a>).</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Insert a new paragraph at the beginning of 26.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a>:</p>
<blockquote>
<p><ins>-?- In this subclause, arguments for a template parameter named <tt>Predicate</tt> or 
<tt>BinaryPredicate</tt> shall meet the corresponding requirements in 28.3 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a>.
For <tt>merge</tt> and <tt>sort</tt>, the definitions and requirements in 28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a> apply.</ins>
</p>
<pre>
void splice_after(const_iterator position, forward_list&amp; x);
void splice_after(const_iterator position, forward_list&amp;&amp; x);
</pre>
<p>
[&hellip;]
</p>
</blockquote>
</li>
<li><p>Edit 26.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a> as indicated:</p>
<blockquote>
<pre>
void merge(forward_list&amp; x);
void merge(forward_list&amp;&amp; x);
template &lt;class Compare&gt; void merge(forward_list&amp; x, Compare comp);
template &lt;class Compare&gt; void merge(forward_list&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>-22- <i>Requires:</i> <del><tt>comp</tt> defines a strict weak ordering (28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a>), and</del> 
<tt>*this</tt> and <tt>x</tt> are both sorted <del>according to this ordering</del><ins>with respect to the comparator 
<tt>operator&lt;</tt> (for the first two overloads) or <tt>comp</tt> (for the last two overloads)</ins>.
<tt>get_allocator() == x.get_allocator()</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Delete 26.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a>/23 as redundant:</p>
<blockquote>
<pre>
void sort();
template &lt;class Compare&gt; void sort(Compare comp);
</pre>
<blockquote>
<p>
<del>-23- <i>Requires:</i> <tt>operator&lt;</tt> (for the version with no arguments) or <tt>comp</tt> (for the version 
with a comparison argument) defines a strict weak ordering (28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a>).</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3001" href="#3001">3001</a><sup><a href="https://cplusplus.github.io/LWG/issue3001">(i)</a></sup>. <tt>weak_ptr::element_type</tt> needs <tt>remove_extent_t</tt></h3>
<p><b>Section:</b> 23.11.2.3 <a href="https://wg21.link/util.smartptr.weak">[util.smartptr.weak]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2017-07-14 <b>Last modified:</b> 2017-08-01</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.weak">issues</a> in [util.smartptr.weak].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
C++17's <tt>shared_ptr&lt;T&gt;::element_type</tt> is <tt>remove_extent_t&lt;T&gt;</tt>, but <tt>weak_ptr&lt;T&gt;::element_type</tt> 
is <tt>T</tt>. They should be the same, but this was lost over time.
<p/>
First, <a href="http://wg21.link/n4562">N4562</a> "Working Draft, C++ Extensions for Library Fundamentals, Version 2" 8.2.2 [memory.smartptr.weak] specified:
</p>
<blockquote>
<pre>
namespace std {
namespace experimental {
inline namespace fundamentals_v2 {

  template&lt;class T&gt; class weak_ptr {
  public:
    typedef typename remove_extent_t&lt;T&gt; element_type;
</pre>
</blockquote>
<p>
(The <tt>typename</tt> here was spurious.)
<p/>
Then, <a href="http://wg21.link/p0220r1">P0220R1</a> "Adopt Library Fundamentals V1 TS Components for C++17 (R1)" listed:
</p>
<blockquote>
<ul>
<li>
<p>8.2.2 Class template <tt>weak_ptr</tt></p>
<ul>
<li>
<p>8.2.2.1 <tt>weak_ptr</tt> constructors</p>
</li>
</ul>
</li>
</ul>
</blockquote>
<p>
This obscured the fact that the Library Fundamentals TS had altered <tt>weak_ptr::element_type</tt>.
<p/>
Finally, <a href="http://wg21.link/p0414r2">P0414R2</a> "Merging <tt>shared_ptr</tt> changes from Library Fundamentals 
to C++17" missed the change to <tt>weak_ptr::element_type</tt>, so it wasn't applied to C++17.
<p/>
Peter Dimov has confirmed that this was unintentionally lost, and that "<tt>boost::weak_ptr</tt> defines 
<tt>element_type</tt> in the same way as <tt>shared_ptr</tt>".
</p>

<p><i>[
2017-07-17 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>




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

<ol>
<li><p>Edit 23.11.2.3 <a href="https://wg21.link/util.smartptr.weak">[util.smartptr.weak]</a>, class template <tt>weak_ptr</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt; class weak_ptr {
public:
  using element_type = <ins>remove_extent_t&lt;</ins>T<ins>&gt;</ins>;
  [&hellip;]
};
</pre>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3024" href="#3024">3024</a><sup><a href="https://cplusplus.github.io/LWG/issue3024">(i)</a></sup>. <tt>variant</tt>'s copies must be deleted instead of disabled via SFINAE</h3>
<p><b>Section:</b> 23.7.3.1 <a href="https://wg21.link/variant.ctor">[variant.ctor]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2017-10-10 <b>Last modified:</b> 2017-10-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#variant.ctor">active issues</a> in [variant.ctor].</p>
<p><b>View all other</b> <a href="lwg-index.html#variant.ctor">issues</a> in [variant.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>
The specification of <tt>variant</tt>'s copy constructor and copy assignment
operator require that those functions do not participate in overload resolution
unless certain conditions are satisfied. There is no mechanism in C++ that makes
it possible to prevent a copy constructor or copy assignment operator from
participating in overload resolution. These functions should instead be specified
to be defined as deleted unless the requisite conditions hold, as we did for the
copy constructor and copy assignment operator of <tt>optional</tt> in LWG
<a href="lwg-defects.html#2756">2756</a>.
</p>

<p><i>[
2017-10-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li><p>Change 23.7.3.1 <a href="https://wg21.link/variant.ctor">[variant.ctor]</a> as indicated:</p>

<blockquote>
<pre>
variant(const variant&amp; w);
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> If <tt>w</tt> holds a value, initializes the <tt>variant</tt>
to hold the same alternative as <tt>w</tt> and direct-initializes the contained
value with <tt>get&lt;j&gt;(w)</tt>, where <tt>j</tt> is <tt>w.index()</tt>.
Otherwise, initializes the <tt>variant</tt> to not hold a value.
</p>
<p>
-7- <i>Throws:</i> Any exception thrown by direct-initializing any
<tt>T<sub><i>i</i></sub></tt> for all <i>i</i>.
</p>
<p>
-8- <i>Remarks:</i> This <del>function shall not participate in overload
resolution</del><ins>constructor shall be defined as deleted</ins> unless
<tt>is_copy_constructible_v&lt;T<sub><i>i</i></sub>&gt;</tt> is true for all
<i>i</i>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.7.3.3 <a href="https://wg21.link/variant.assign">[variant.assign]</a> as indicated:</p>

<blockquote>
<pre>
variant&amp; operator=(const variant&amp; rhs);
</pre>
<blockquote>
<p>
[&hellip;]
</p>
<p>
-4- <i>Postconditions:</i> <tt>index() == rhs.index()</tt>.
</p>
<p>
-5- <i>Remarks:</i> This <del>function shall not participate in overload
resolution</del><ins>operator shall be defined as deleted</ins> unless
<tt>is_copy_constructible_v&lt;T<sub><i>i</i></sub>&gt; &amp;&amp;
is_copy_assignable_v&lt;T<sub><i>i</i></sub>&gt;</tt> is true for all <i>i</i>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





</body>
</html>
