<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta charset="utf-8">
<title>C++ Standard Library Issues to be moved in Jacksonville</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table {border-collapse: collapse;}
</style>
</head>
<body>
<h1>C++ Standard Library Issues to be moved in Jacksonville</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P0888R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2018-02-12 at 00:42:19 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="2164" href="#2164">2164</a><sup><a href="https://cplusplus.github.io/LWG/issue2164">(i)</a></sup>. What are the semantics of <tt>vector.emplace(vector.begin(), vector.back())</tt>?</h3>
<p><b>Section:</b> 26.3.11.5 <a href="https://wg21.link/vector.modifiers">[vector.modifiers]</a>, 26.2 <a href="https://wg21.link/container.requirements">[container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2012-07-07 <b>Last modified:</b> 2018-01-28</p>
<p><b>Priority: </b>2
</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>
Nikolay Ivchenkov recently brought the following example on the
<a href="https://groups.google.com/a/isocpp.org/d/topic/std-discussion/dhy23mDFXj4/discussion">std-discussion</a> 
newsgroup, asking whether the following program well-defined:
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;vector&gt;

int main()
{
  std::vector&lt;int&gt; v;
  v.reserve(4);
  v = { 1, 2, 3 };
  v.emplace(v.begin(), v.back());
  for (int x : v)
    std::cout &lt;&lt; x &lt;&lt; std::endl;
}
</pre></blockquote>
<p>
Nikolay Ivchenkov:
<p/>
I think that an implementation of <tt>vector</tt>'s 'emplace' should initialize an intermediate object with 
<tt>v.back()</tt> before any shifts take place, then perform all necessary shifts and finally replace the 
value pointed to by <tt>v.begin()</tt> with the value of the intermediate object. So, I would expect the 
following output:
</p>
<blockquote><pre>
3
1
2
3
</pre></blockquote>
<p>
GNU C++ 4.7.1 and GNU C++ 4.8.0 produce other results:
</p>
<blockquote><pre>
2
1
2
3
</pre></blockquote>
<p>
Howard Hinnant:
<p/>
I believe Nikolay is correct that vector should initialize an intermediate object with <tt>v.back()</tt> 
before any shifts take place. As Nikolay pointed out in another email, this appears to be the only way to 
satisfy the strong exception guarantee when an exception is not thrown by <tt>T</tt>'s copy constructor, 
move constructor, copy assignment operator, or move assignment operator as specified by 
26.3.11.5 <a href="https://wg21.link/vector.modifiers">[vector.modifiers]</a>/p1. I.e. if the emplace construction throws, the vector must remain unaltered.
<p/>
That leads to an implementation that tolerates objects bound to the function parameter pack of the <tt>emplace</tt> 
member function may be elements or sub-objects of elements of the container.
<p/>
My position is that the standard is correct as written, but needs a clarification in this area. Self-referencing 
<tt>emplace</tt> should be legal and give the result Nikolay expects. The proposed resolution of LWG <a href="lwg-closed.html#760">760</a> 
is not correct.
</p>

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

<p>
LWG agrees with the analysis including the assessment of LWG <a href="lwg-closed.html#760">760</a> and would appreciate a concrete wording proposal.
</p>

<p><i>[2015-04-07 dyp comments]</i></p>

<p>
The Standard currently does not require that creation of such
intermediate objects is legal. 26.2.3 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a> Table 100
&mdash; "Sequence container requirements" currently specifies:
</p>

<blockquote>
<table border="1">
<caption>Table 100 &mdash; Sequence container requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

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

<tr>
<td>
<tt>a.emplace(p, args);</tt>
</td>
<td>
<tt>iterator</tt>
</td>
<td>
<i>Requires</i>: <tt>T</tt> is <tt>EmplaceConstructible</tt> into
<tt>X</tt> from <tt>args</tt>. For <tt>vector</tt> and <tt>deque</tt>,
<tt>T</tt> is also <tt>MoveInsertable</tt> into <tt>X</tt> and
<tt>MoveAssignable</tt>. [&hellip;]
</td>
</tr>

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

</table>
</blockquote>

<p>
The <tt>EmplaceConstructible</tt> concept is defined via
<tt>allocator_traits&lt;A&gt;::construct</tt> in 26.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> p15.5 That's surprising to me
since the related concepts use the suffix <tt>Insertable</tt> if they
refer to the allocator. An additional requirement such as
<tt>std::is_constructible&lt;T, Args...&gt;</tt> is necessary to allow
creation of intermediate objects.
</p>

<p>
The creation of intermediate objects also affects other functions, such
as <tt>vector.insert</tt>. Since aliasing the vector is only allowed for
the single-element forms of <tt>insert</tt> and <tt>emplace</tt> (see
<a href="lwg-closed.html#526">526</a>), the range-forms are not affected. Similarly,
aliasing is not allowed for the rvalue-reference overload. See also LWG
<a href="lwg-defects.html#2266">2266</a>.
</p>

<p>
There might be a problem with a requirement of
<tt>std::is_constructible&lt;T, Args...&gt;</tt> related to the issues
described in LWG <a href="lwg-active.html#2461">2461</a>. For example, a scoped allocator
adapter passes additional arguments to the constructor of the value
type. This is currently not done in recent implementations of libstdc++
and libc++ when creating the intermediate objects, they simply create
the intermediate object by perfectly forwarding the arguments. If such
an intermediate object is then moved to its final destination in the
vector, a change of the allocator instance might be required &mdash;
potentially leading to an expensive copy. One can also imagine worse
problems, such as run-time errors (allocators not comparing equal at
run-time) or compile-time errors (if the value type cannot be created
without the additional arguments). I have not looked in detail into this
issue, but I'd be reluctant adding a requirement such as
<tt>std::is_constructible&lt;T, Args...&gt;</tt> without further
investigation.
</p>

<p>
It should be noted that the creation of intermediate objects currently
is inconsistent in libstdc++ vs libc++. For example, libstdc++ creates
an intermediate object for <tt>vector.insert</tt>, but not
<tt>vector.emplace</tt>, whereas libc++ does the exact opposite in this
respect.
</p>

<p>
A live demo of the inconsistent creation of intermediate objects can be
found <a href="http://coliru.stacked-crooked.com/a/449253d3d329ef4c">here</a>.
</p>

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

<p>HH: If it were easy, it'd have wording. Over the decades I have flipped 180 degrees on this. My current position is that it should work even if the element is in the same container.</p>
<p>TK: What's the implentation status? JW: Broken in GCC. STL: Broken in MSVS. Users complain about this every year.</p>
<p>MC: 526 says push_back has to work.</p>
<p>HH: I think you have to make a copy of the element anyway for reasons of exception safety. [Discussion of exception guarantees] </p>
<p>STL: vector has strong exception guarantees. Could we not just provide the Basic guarantee here. </p>
<p>HH: It would terrify me to relax that guarantee. It'd be an ugly, imperceptible runtime error. </p>
<p>HH: I agree if we had a clean slate that strong exception safety is costing us here, and we shouldn't provide it if it costs us.</p>
<p>STL: I have a mail here, "how can vector provide the strong guarantee when inserting in the middle". </p>
<p>HH: The crucial point is that you only get the strong guarantee if the exception is thrown by something other than the copy and move operations that are used to make the hole. </p>
<p>STL: I think we need to clean up the wording. But it does mandate currently that the self-emplacement must work, because nothings says that you can't do it. TK clarifies that a) self-emplacement must work, and b) you get the strong guarantee only if the operations for making the hole don't throw, otherwise basic. HH agrees. STL wants this to be clear in the Standard.</p>
<p>STL: Should it work for deque, too? HH: Yes.</p>
<p>HH: I will attempt wording for this. </p>
<p>TK: Maybe mail this to the reflector, and maybe someone has a good idea? </p>
<p>JW: I will definitely not come up with anything better, but I can critique wording.</p>
<p>Moved to Open; Howard to provide wording, with feedback from Jonathan.</p>

<p><i>[2017-01-25, Howard suggests wording]</i></p>


<p><i>[2018-1-26 issues processing telecon]</i></p>

<p>Status to 'Tentatively Ready' after adding a period to Howard's wording.</p>


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

<ol>
<li><p>Modify in 26.2.3 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a> Table 87 &mdash; "Sequence container requirements" as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 87 &mdash; Sequence 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>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>a.emplace(p, args)</tt>
</td>
<td><tt>iterator</tt></td>
<td>
<i>Requires</i>: <tt>T</tt> is <tt>EmplaceConstructible</tt> into <tt>X</tt><br/>
from <tt>args</tt>. For <tt>vector</tt> and <tt>deque</tt>, <tt>T</tt> is also<br/>
<tt>MoveInsertable</tt> into <tt>X</tt> and <tt>MoveAssignable</tt>.<br/>
<i>Effects:</i> Inserts an object of type <tt>T</tt><br/>
constructed with<br/>
<tt>std::forward&lt;Args&gt;(args)...</tt> before <tt>p</tt>.<br/>
<ins>[<i>Note:</i> <tt>args</tt> may directly or indirectly refer to a value<br/> 
in <tt>a</tt>. &mdash; <i>end note</i>]</ins>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2243" href="#2243">2243</a><sup><a href="https://cplusplus.github.io/LWG/issue2243">(i)</a></sup>. <tt>istream::putback</tt> problem</h3>
<p><b>Section:</b> 30.7.4.3 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-03-01 <b>Last modified:</b> 2018-01-10</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 30.7.4.3 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> / 34, when describing <tt>putback</tt>, it says that "<tt>rdbuf-&gt;sputbackc()</tt>" 
is called. The problem are not the obvious typos in the expression, but the fact that it may lead to different 
interpretations, since nowhere is specified what the required argument to <tt>sputbackc</tt> is.
<p/>
It can be guessed to be "<tt>rdbuf()-&gt;sputbackc(c)</tt>", but "<tt>rdbuf()-&gt;sputbackc(char_type())</tt>" or 
just anything would be as conforming (or non-conforming) as the first guess.
</p>

<p><i>[2017-12-12, Jonathan comments and provides wording]</i></p>

<p>
Fix the bogus expression, and change <tt>sputbackc()</tt> to just <tt>sputbackc</tt>
since we're talking about the function, not an expression <tt>sputbackc()</tt> (which 
isn't a valid expression any more than <tt>rdbuf-&gt;sputbackc()</tt> is). Make the 
corresponding change to the equivalent wording in p36 too.
</p>

<p><i>[
2017-12-14 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="http://wg21.link/n4713">N4713</a>.</p>

<ol>
<li><p>Change 30.7.4.3 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> as shown:</p>

<blockquote>
<pre>
basic_istream&lt;charT, traits&gt;&amp; putback(char_type c);
</pre>
<blockquote>
<p>
-34- <i>Effects:</i> Behaves as an unformatted input function (as described above), except that the function
first clears <tt>eofbit</tt>. After constructing a sentry object, if <tt>!good()</tt> calls 
<tt>setstate(failbit)</tt> which may throw an exception, and return. If <tt>rdbuf()</tt> is not null, calls 
<tt>rdbuf<ins>()</ins>-&gt;sputbackc(<ins>c</ins>)</tt>. If <tt>rdbuf()</tt> is null, or if 
<tt>sputbackc<del>()</del></tt> returns <tt>traits::eof()</tt>, calls <tt>setstate(badbit)</tt> (which may throw 
<tt>ios_base::failure</tt> (30.5.5.4 <a href="https://wg21.link/iostate.flags">[iostate.flags]</a>)). 
[<i>Note:</i> This function extracts no characters, so the value returned by the next call to <tt>gcount()</tt> 
is <tt>0</tt>. &mdash; <i>end note</i>]
<p/>
-35- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
<pre>
basic_istream&lt;charT, traits&gt;&amp; unget();
</pre>
<blockquote>
<p>
-36- <i>Effects:</i> Behaves as an unformatted input function (as described above), except that the function
first clears <tt>eofbit</tt>. After constructing a sentry object, if <tt>!good()</tt> calls 
<tt>setstate(failbit)</tt> which may throw an exception, and return. If <tt>rdbuf()</tt> is not null, calls 
<tt>rdbuf()-&gt;sungetc()</tt>. If <tt>rdbuf()</tt> is null, or if <tt>sungetc<del>()</del></tt> returns 
<tt>traits::eof()</tt>, calls <tt>setstate(badbit)</tt> (which may throw <tt>ios_base::failure</tt> 
(30.5.5.4 <a href="https://wg21.link/iostate.flags">[iostate.flags]</a>)). 
[<i>Note:</i> This function extracts no characters, so the value returned by the next call to <tt>gcount()</tt> is 
<tt>0</tt>. &mdash; <i>end note</i>]
<p/>
-37- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2816" href="#2816">2816</a><sup><a href="https://cplusplus.github.io/LWG/issue2816">(i)</a></sup>. <tt>resize_file</tt> has impossible postcondition</h3>
<p><b>Section:</b> 30.11.14.33 <a href="https://wg21.link/fs.op.resize_file">[fs.op.resize_file]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2016-11-07 <b>Last modified:</b> 2018-01-28</p>
<p><b>Priority: </b>3
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>resize_file</tt> has this postcondition (after resolving late comment 42, see <a href="http://wg21.link/p0489r0">P0489R0</a>):
</p>
<blockquote><p>
<i>Postcondition:</i> <tt>file_size(p) == new_size</tt>.
</p></blockquote>
<p>
This is impossible for an implementation to satisfy, due to the possibility of file system races. 
This is not actually a postcondition; rather, it is an effect that need no longer hold when the function returns.
</p>

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

<p>Priority 3</p>

<p><i>[2018-01-16, Jonathan provides wording]</i></p>


<p><i>[2018-1-26 issues processing telecon]</i></p>

<p>Status to 'Tentatively Ready'</p>


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

<blockquote class="note">
<p>
[<i>Drafting note:</i> I considered a slightly more verbose form: "Causes the
size in bytes of the file <tt>p</tt> resolves to, as determined by <tt>file_size</tt>
(30.11.14.14 <a href="https://wg21.link/fs.op.file_size">[fs.op.file_size]</a>), to be equal to <tt>new_size</tt>, as if by POSIX
<tt>truncate</tt>." but I don't think it's an improvement. The intent of the
proposed wording is that if either <tt>file_size(p)</tt> or <tt>truncate(p.c_str())</tt>
would fail then an error occurs, but no call to <tt>file_size</tt> is required,
and file system races might change the size before any such call does occur.]
</p>
</blockquote>

<ol>
<li><p>Modify 30.11.14.33 <a href="https://wg21.link/fs.op.resize_file">[fs.op.resize_file]</a> as indicated:</p>

<blockquote>
<pre>
void resize_file(const path&amp; p, uintmax_t new_size);
void resize_file(const path&amp; p, uintmax_t new_size, error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
-1- <del><i>Postconditions:</i> <tt>file_size(p) == new_size</tt></del><ins><i>Effects:</i> Causes 
the size that would be returned by <tt>file_size(p)</tt> to be equal to <tt>new_size</tt>, as if 
by POSIX <tt>truncate</tt></ins>.
<p/>
-2- <i>Throws:</i> As specified in 30.11.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a>.
<p/>
<del>-3- <i>Remarks:</i> Achieves its postconditions as if by POSIX <tt>truncate()</tt>.</del>
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2843" href="#2843">2843</a><sup><a href="https://cplusplus.github.io/LWG/issue2843">(i)</a></sup>. Unclear behavior of <tt>std::pmr::memory_resource::do_allocate()</tt></h3>
<p><b>Section:</b> 23.12.2.2 <a href="https://wg21.link/mem.res.private">[mem.res.private]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2016-12-13 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#mem.res.private">issues</a> in [mem.res.private].</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 specification of <tt>do_allocate()</tt> (23.12.2.2 <a href="https://wg21.link/mem.res.private">[mem.res.private]</a> p2+p3) says:
</p>
<blockquote>
<p>
<i>Returns:</i> A derived class shall implement this function to return a
pointer to allocated storage (3.7.4.2) with a size of at least <tt>bytes</tt>.
The returned storage is aligned to the specified alignment, if such
alignment is supported (3.11); otherwise it is aligned to <tt>max_align</tt>.
<p/>
<i>Throws:</i> A derived class implementation shall throw an appropriate
exception if it is unable to allocate memory with the requested size
and alignment.
</p>
</blockquote>
<p>
It is unclear whether a request for an unsupported alignment
(e.g. larger than <tt>max_align</tt>) yields an exception or the returned
storage is silently aligned to <tt>max_align</tt>.
<p/>
This is <a href="https://github.com/cplusplus/draft/issues/966">editorial issue #966</a>.
</p>

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

<p>Priority 3; Marshall to ping Pablo for intent and provide wording.</p>

<p><i>[2017-02-12 Pablo responds and provides wording]</i></p>

<p>The original intent was:</p>
<ul>
  <li>If the alignment is supported by the implementation (see below), then it must use that alignment or else throw.</li>
  <li>If the alignment is not supported it must use max_align else throw.</li>
</ul>
<p>However, the description of do_allocate might have gone stale as the
aligned-allocation proposal made its way into the standard.</p>

<p>The understanding I take from the definition of extended alignment in
(the current text of) 3.11/3 [basic.align] and "assembling an argument
list" in 5.3.4/14 [expr.new] is that it is intended that, when
allocating space for an object with extended alignment in a well-formed
program, the alignment <i>will</i> be honored and <i>will not be</i>
truncated to max_align. I think this is a change from earlier drafts of
the extended-alignment proposal, where silent truncation to <tt>max_align</tt>
was permitted (I could be wrong). Anyway, it seems wrong to ever ignore
the alignment parameter in <tt>do_allocate()</tt>.</p>

<p><i>[2017-11 Albuquerque Wednesday issue processing]</i></p>

<p>Move to Ready.</p>


<p><b>Proposed resolution:</b></p>
<p>Change the specification of <tt>do_allocate()</tt> (23.12.2.2 <a href="https://wg21.link/mem.res.private">[mem.res.private]</a> p2+p3) as follows:</p>

<blockquote>
  <p><i>Returns</i>: A derived class shall implement this function to
  return a pointer to allocated storage (3.7.4.2) with a size of at
  least <tt>bytes</tt><ins>, aligned to the specified
  <tt>alignment</tt></ins>. <del>The returned storage is aligned to the
  specified alignment, if such alignment is supported; otherwise it is
  aligned to <tt>max_align</tt>.</del></p>

<p><i>Throws:</i> A derived class implementation shall throw an
appropriate exception if it is unable to allocate memory with the
requested size and alignment.</p>
</blockquote>





<hr>
<h3><a name="2849" href="#2849">2849</a><sup><a href="https://cplusplus.github.io/LWG/issue2849">(i)</a></sup>. Why does <tt>!is_regular_file(from)</tt> cause <tt>copy_file</tt> to report a "file already exists" error?</h3>
<p><b>Section:</b> 30.11.14.4 <a href="https://wg21.link/fs.op.copy_file">[fs.op.copy_file]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-12-17 <b>Last modified:</b> 2018-01-26</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fs.op.copy_file">active issues</a> in [fs.op.copy_file].</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.op.copy_file">issues</a> in [fs.op.copy_file].</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>
30.11.14.4 <a href="https://wg21.link/fs.op.copy_file">[fs.op.copy_file]</a>/4 says that <tt>copy_file</tt> reports "a file already exists error as specified in 
[fs.err.report] if" any of several error conditions exist.
<p/>
It's not clear how some of those error conditions, such as <tt>!is_regular_file(from)</tt>, can be sensibly described 
as "file already exists". Pretty much everywhere else in the filesystem specification just says "an error" without 
further elaboration.
</p>

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

<p>Priority 2; Jonathan to provide updated wording.</p>

<p><i>[2018-01-16, Jonathan comments]</i></p>

<p>
I said I'd provide updated wording because I wanted to preserve the requirement that the reported error is 
"file already exists" for some of the error cases. I no longer think that's necessary, so I think the 
current P/R is fine. Please note that I don't think new wording is needed.
</p>

<p><i>[
2018-01-23 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="http://wg21.link/n4713">N4713</a>.</p>

<ol>
<li><p>Edit 30.11.14.4 <a href="https://wg21.link/fs.op.copy_file">[fs.op.copy_file]</a>/4 as indicated:</p>
<blockquote>
<pre>
bool copy_file(const path&amp; from, const path&amp; to, copy_options options);
bool copy_file(const path&amp; from, const path&amp; to, copy_options options,
               error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> As follows:
</p>
<ol style="list-style-type: none">
<li><p>(4.1) &mdash; Report <del>a file already exists</del><ins>an</ins> error as specified in 30.11.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a> if:</p></li>
<li>
<ol style="list-style-type: none">
<li><p>(4.1.1) &mdash;[&hellip;]</p></li>
</ol>
</li>
<li><p>(4.2) &mdash;[&hellip;]</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2851" href="#2851">2851</a><sup><a href="https://cplusplus.github.io/LWG/issue2851">(i)</a></sup>. <tt>std::filesystem</tt> enum classes are now underspecified</h3>
<p><b>Section:</b> 30.11.9.2 <a href="https://wg21.link/fs.enum.file_type">[fs.enum.file_type]</a>, 30.11.9.3 <a href="https://wg21.link/fs.enum.copy.opts">[fs.enum.copy.opts]</a>, 30.11.9.6 <a href="https://wg21.link/fs.enum.dir.opts">[fs.enum.dir.opts]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-12-18 <b>Last modified:</b> 2018-01-28</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.enum.file_type">issues</a> in [fs.enum.file_type].</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#2678">2678</a> stripped the numerical values of the enumerators from three enum classes in 30.11.9 <a href="https://wg21.link/fs.enum">[fs.enum]</a>; 
in doing so it also removed the implicit specification 1) of the bitmask elements for the two bitmask types (<tt>copy_options</tt> 
and <tt>directory_options</tt>) and 2) that the <tt>file_type</tt> constants are distinct.
</p>

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

<p>Priority 2; Jonathan to work with Tim to tweak wording.</p>

<p><i>[2018-01-16, Jonathan comments]</i></p>

<p>
I no longer remember what I didn't like about Tim's P/R so I think we should accept the original P/R.
</p>

<p><i>[2018-1-26 issues processing telecon]</i></p>

<p>Status to 'Tentatively Ready'</p>


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

<ol>
<li><p>Edit 30.11.9.2 <a href="https://wg21.link/fs.enum.file_type">[fs.enum.file_type]</a>/1 as indicated:</p>
<blockquote>
<p>
This enum class specifies constants used to identify file types, with the meanings listed in Table 123. 
<ins>The values of the constants are distinct.</ins>
</p>
</blockquote>
</li>

<li><p>Edit 30.11.9.3 <a href="https://wg21.link/fs.enum.copy.opts">[fs.enum.copy.opts]</a>/1 as indicated:</p>
<blockquote>
<p>
The <tt>enum class</tt> type <tt>copy_options</tt> is a bitmask type (20.4.2.1.4 <a href="https://wg21.link/bitmask.types">[bitmask.types]</a>) that 
specifies bitmask constants used to control the semantics of copy operations. The constants are specified 
in option groups with the meanings listed in Table 124. <ins>The constant <tt>none</tt> represents the empty bitmask, and </ins><del>Constant <tt>none</tt></del> is shown in each option group for purposes of 
exposition; implementations shall provide only a single definition. <ins>Every other constant in the 
table represents a distinct bitmask element.</ins> Calling a library function with more than a single 
constant for an option group results in undefined behavior.
</p>
</blockquote>
</li>

<li><p>Edit 30.11.9.6 <a href="https://wg21.link/fs.enum.dir.opts">[fs.enum.dir.opts]</a>/1 as indicated:</p>
<blockquote>
<p>
The <tt>enum class</tt> type <tt>directory_options</tt> is a bitmask type (20.4.2.1.4 <a href="https://wg21.link/bitmask.types">[bitmask.types]</a>) 
that specifies bitmask constants used to identify directory traversal options, with the meanings listed 
in Table 127. <ins>The constant <tt>none</tt> represents the empty bitmask; every other constant in the 
table represents a distinct bitmask element.</ins>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2969" href="#2969">2969</a><sup><a href="https://cplusplus.github.io/LWG/issue2969">(i)</a></sup>. <tt>polymorphic_allocator::construct()</tt> shouldn't pass <tt>resource()</tt></h3>
<p><b>Section:</b> 23.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2017-05-30 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#mem.poly.allocator.mem">active issues</a> in [mem.poly.allocator.mem].</p>
<p><b>View all other</b> <a href="lwg-index.html#mem.poly.allocator.mem">issues</a> in [mem.poly.allocator.mem].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 23.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> defines the effect of <tt>polymorphic_allocator&lt;T&gt;::construct</tt> as:
</p>
<blockquote>
<p>
<i>Effects:</i> Construct a <tt>T</tt> object in the storage whose address is represented by <tt>p</tt> by uses-allocator
construction with allocator <tt>resource()</tt> and constructor arguments <tt>std::forward&lt;Args&gt;(args)...</tt>.
</p>
</blockquote>
<p>
The use of <tt>resource()</tt> is a hold-over from the LFTS, which contains a modified definition of uses-allocator construction. This revised definition was not carried over into the C++17 WP when allocator_resource and polymorphic_allocator were moved over.
</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 23.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> as indicated:</p>

<blockquote>
<pre>
template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-5- <i>Requires:</i> Uses-allocator construction of <tt>T</tt> with allocator <tt><del>resource()</del><ins>*this</ins></tt> (see 
23.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>) and constructor arguments <tt>std::forward&lt;Args&gt;(args)...</tt> 
is well-formed. [<i>Note:</i> Uses-allocator construction is always well formed for types that do not use 
allocators. &mdash; <i>end note</i>]
<p/>
-6- <i>Effects:</i> Construct a <tt>T</tt> object in the storage whose address is represented by <tt>p</tt> by 
uses-allocator construction with allocator <tt><del>resource()</del><ins>*this</ins></tt> and constructor arguments 
<tt>std::forward&lt;Args&gt;(args)...</tt>.
<p/>
-7- <i>Throws:</i> Nothing unless the constructor for <tt>T</tt> throws.
</p>
</blockquote>
<pre>
template &lt;class T1, class T2, class... Args1, class... Args2&gt;
  void construct(pair&lt;T1,T2&gt;* p, piecewise_construct_t,
                 tuple&lt;Args1...&gt; x, tuple&lt;Args2...&gt; y);
</pre>
<blockquote>
<p>
-8- [<i>Note:</i> This method and the <tt>construct</tt> methods that follow are overloads for piecewise construction
of pairs (23.4.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a>). &mdash; <i>end note</i>]
<p/>
-9- <i>Effects:</i> Let <tt>xprime</tt> be a <tt>tuple</tt> constructed from <tt>x</tt> according to the appropriate rule 
from the following list. [<i>Note:</i> The following description can be summarized as constructing a 
<tt>pair&lt;T1, T2&gt;</tt> object in the storage whose address is represented by <tt>p</tt>, as if by separate 
uses-allocator construction with allocator <tt><del>resource()</del><ins>*this</ins></tt> 
(23.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>) of <tt>p-&gt;first</tt> using the elements of <tt>x</tt> and 
<tt>p-&gt;second</tt> using the elements of <tt>y</tt>. &mdash; <i>end note</i>]
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2017-06-12, Pablo comments]</i></p>

<p>
The current description is correct and does not depend on changes to uses-allocator construction. It relies on the fact 
that <tt>memory_resource*</tt> is convertible to <tt>polymorphic_allocator</tt>.
</p>

<p><i>[2017-06-13, Tim Song reopens]</i></p>

<p>
While it is true that <tt>memory_resource*</tt> is convertible to <tt>polymorphic_allocator</tt>,
uses-allocator construction still requires allocators, and a
<tt>memory_resource*</tt> isn't an allocator.
<p/>
To take a concrete example from the current WP, a <tt>pmr::vector&lt;std::promise&lt;int&gt;&gt;</tt>, as specified, 
will be attempting to uses-allocator construct a <tt>promise&lt;int&gt;</tt> with a <tt>memory_resource*</tt>, but
<tt>std::promise</tt>'s allocator-taking constructor expects something that satisfies the allocator requirements, 
rather than a <tt>memory_resource*</tt>.
</p>

<p><i>[2017-06-13, Daniel and Tim restore and improve the previously proposed wording]</i></p>

<p>
</p>

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

<p>Priority 2; Dietmar to check the P/R before Albuquerque.</p>

<p><i>[2017-11 Albuquerque Wednesday issue processing]</i></p>

<p>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.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> as indicated:</p>

<blockquote>
<pre>
template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-5- <i>Requires:</i> Uses-allocator construction of <tt>T</tt> with allocator <tt><del>resource()</del><ins>*this</ins></tt> (see 
23.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>) and constructor arguments <tt>std::forward&lt;Args&gt;(args)...</tt> 
is well-formed. [<i>Note:</i> Uses-allocator construction is always well formed for types that do not use 
allocators. &mdash; <i>end note</i>]
<p/>
-6- <i>Effects:</i> Construct a <tt>T</tt> object in the storage whose address is represented by <tt>p</tt> by 
uses-allocator construction with allocator <tt><del>resource()</del><ins>*this</ins></tt> and constructor arguments 
<tt>std::forward&lt;Args&gt;(args)...</tt>.
<p/>
-7- <i>Throws:</i> Nothing unless the constructor for <tt>T</tt> throws.
</p>
</blockquote>
<pre>
template &lt;class T1, class T2, class... Args1, class... Args2&gt;
  void construct(pair&lt;T1,T2&gt;* p, piecewise_construct_t,
                 tuple&lt;Args1...&gt; x, tuple&lt;Args2...&gt; y);
</pre>
<blockquote>
<p>
-8- [<i>Note:</i> This method and the <tt>construct</tt> methods that follow are overloads for piecewise construction
of pairs (23.4.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a>). &mdash; <i>end note</i>]
<p/>
-9- <i>Effects:</i> Let <tt>xprime</tt> be a <tt>tuple</tt> constructed from <tt>x</tt> according to the appropriate rule 
from the following list. [<i>Note:</i> The following description can be summarized as constructing a 
<tt>pair&lt;T1, T2&gt;</tt> object in the storage whose address is represented by <tt>p</tt>, as if by separate 
uses-allocator construction with allocator <tt><del>resource()</del><ins>*this</ins></tt> 
(23.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>) of <tt>p-&gt;first</tt> using the elements of <tt>x</tt> and 
<tt>p-&gt;second</tt> using the elements of <tt>y</tt>. &mdash; <i>end note</i>]
</p>
<ol style="list-style-type: none">
<li><p>(9.1) &mdash; If <tt>uses_allocator_v&lt;T1,<del>memory_resource*</del><ins>polymorphic_allocator</ins>&gt;</tt> is <tt>false</tt>
and <tt>is_constructible_v&lt;T1,Args1...&gt;</tt> is <tt>true</tt>, then <tt>xprime</tt> is <tt>x</tt>.</p></li>
<li><p>(9.2) &mdash; Otherwise, if <tt>uses_allocator_v&lt;T1,<del>memory_resource*</del><ins>polymorphic_allocator</ins>&gt;</tt> is <tt>true</tt>
and <tt>is_constructible_v&lt;T1,allocator_arg_t,<del>memory_resource*</del><ins>polymorphic_allocator</ins>,Args1...&gt;</tt> is <tt>true</tt>, then 
<tt>xprime</tt> is <tt>tuple_cat(make_tuple(allocator_arg, <del>resource()</del><ins>*this</ins>), 
std::move(x))</tt>.</p></li>
<li><p>(9.3) &mdash; Otherwise, if <tt>uses_allocator_v&lt;T1,<del>memory_resource*</del><ins>polymorphic_allocator</ins>&gt;</tt> is <tt>true</tt> and 
<tt>is_constructible_v&lt;T1,Args1...,<del>memory_resource*</del><ins>polymorphic_allocator</ins>&gt;</tt> is <tt>true</tt>, then <tt>xprime</tt> is 
<tt>tuple_cat(std::move(x), make_tuple(<del>resource()</del><ins>*this</ins>))</tt>.</p></li>
<li><p>(9.4) &mdash; Otherwise the program is ill formed.</p></li>
</ol>
<p>
Let <tt>yprime</tt> be a tuple constructed from <tt>y</tt> according to the appropriate rule from the following list:
</p>
<ol style="list-style-type: none">
<li><p>(9.5) &mdash; If <tt>uses_allocator_v&lt;T2,<del>memory_resource*</del><ins>polymorphic_allocator</ins>&gt;</tt> is <tt>false</tt>
and <tt>is_constructible_v&lt;T2,Args2...&gt;</tt> is <tt>true</tt>, then <tt>yprime</tt> is <tt>y</tt>.</p></li>
<li><p>(9.6) &mdash; Otherwise, if <tt>uses_allocator_v&lt;T2,<del>memory_resource*</del><ins>polymorphic_allocator</ins>&gt;</tt> is <tt>true</tt> and 
<tt>is_constructible_v&lt;T2,allocator_arg_t,<del>memory_resource*</del><ins>polymorphic_allocator</ins>,Args2...&gt;</tt> is <tt>true</tt>, then <tt>yprime</tt> 
is <tt>tuple_cat(make_tuple(allocator_arg, <del>resource()</del><ins>*this</ins>), std::move(y))</tt>.</p></li>
<li><p>(9.7) &mdash; Otherwise, if <tt>uses_allocator_v&lt;T2,<del>memory_resource*</del><ins>polymorphic_allocator</ins>&gt;</tt> is <tt>true</tt> and 
<tt>is_constructible_v&lt;T2,Args2...,<del>memory_resource*</del><ins>polymorphic_allocator</ins>&gt;</tt> is <tt>true</tt>,
then <tt>yprime</tt> is <tt>tuple_cat(std::move(y), make_tuple(<del>resource()</del><ins>*this</ins>))</tt>.</p></li>
<li><p>(9.8) &mdash; Otherwise the program is ill formed.</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2975" href="#2975">2975</a><sup><a href="https://cplusplus.github.io/LWG/issue2975">(i)</a></sup>. Missing case for <tt>pair</tt> construction in scoped and polymorphic allocators</h3>
<p><b>Section:</b> 23.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a>, 23.13.4 <a href="https://wg21.link/allocator.adaptor.members">[allocator.adaptor.members]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2017-06-13 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#mem.poly.allocator.mem">active issues</a> in [mem.poly.allocator.mem].</p>
<p><b>View all other</b> <a href="lwg-index.html#mem.poly.allocator.mem">issues</a> in [mem.poly.allocator.mem].</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>scoped_allocator_adaptor</tt> ([allocator.adaptor.syn]) and <tt>polymorphic_allocator</tt> ([mem.poly.allocator.class]) 
have identical families of members named <tt>construct</tt>:
</p>
<blockquote>
<pre>
template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);

template &lt;class T1, class T2, class... Args1, class... Args2&gt;
  void construct(pair&lt;T1,T2&gt;* p, piecewise_construct_t,
                 tuple&lt;Args1...&gt; x, tuple&lt;Args2...&gt; y);
template &lt;class T1, class T2&gt;
  void construct(pair&lt;T1,T2&gt;* p);
template &lt;class T1, class T2, class U, class V&gt;
  void construct(pair&lt;T1,T2&gt;* p, U&amp;&amp; x, V&amp;&amp; y);
template &lt;class T1, class T2, class U, class V&gt;
  void construct(pair&lt;T1,T2&gt;* p, const pair&lt;U, V&gt;&amp; pr);
template &lt;class T1, class T2, class U, class V&gt;
  void construct(pair&lt;T1,T2&gt;* p, pair&lt;U, V&gt;&amp;&amp; pr);
</pre>
</blockquote>
<p>
Both allocators perform <tt>uses_allocator</tt> construction, and therefore need special handling for <tt>pair</tt> 
constructions since <tt>pair</tt> doesn't specialize <tt>uses_allocator</tt> (<tt>tuple</tt> gets all of that magic 
and <tt>pair</tt> is left out in the cold). Presumably, the intent is that the <tt>construct</tt> overloads whose first 
argument is a pointer to <tt>pair</tt> capture all <tt>pair</tt> constructions. This is not the case: invoking 
<tt>construct</tt> with a <tt>pair</tt> pointer and a non-constant lvalue <tt>pair</tt> resolves to the <em>first</em> 
overload when it is viable: it's a better match than the <tt>pair</tt>-pointer-and-<tt>const</tt>-lvalue-<tt>pair</tt> 
overload. The first overload notably does not properly perform piecewise <tt>uses_allocator</tt> construction for 
<tt>pair</tt>s as intended.
</p>

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

<p>Priority 2; Marshall to work with Casey to reduce the negations in the wording.</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<ol>
<li>
<p>Modify 23.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> as indicated:</p>

<blockquote>
<pre>
template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-5- <i>Requires:</i> Uses-allocator construction of <tt>T</tt> with allocator <tt>resource()</tt> (see 
23.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>) and constructor arguments <tt>std::forward&lt;Args&gt;(args)...</tt> 
is well-formed. [<i>Note:</i> Uses-allocator construction is always well formed for types that do not use allocators.
&mdash; <i>end note</i>]
<p/>
-6- <i>Effects:</i> Construct a <tt>T</tt> object in the storage whose address is represented by <tt>p</tt> by 
uses-allocator construction with allocator <tt>resource()</tt> and constructor arguments <tt>std::forward&lt;Args&gt;(args)...</tt>.
<p/>
-7- <i>Throws:</i> Nothing unless the constructor for <tt>T</tt> throws.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless <tt>T</tt> is not a specialization 
of <tt>pair</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>Modify 23.13.4 <a href="https://wg21.link/allocator.adaptor.members">[allocator.adaptor.members]</a> as indicated:</p>

<blockquote>
<pre>
template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-9- <i>Effects:</i> [&hellip;]
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless <tt>T</tt> is not a specialization 
of <tt>pair</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>

</blockquote>

<p><i>[2017-11-02 Marshall and Casey provide updated wording]</i></p>


<p><i>[2017-11 Albuquerque Wednesday issue processing]</i></p>

<p>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>Modify 23.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> as indicated:</p>

<blockquote>
<pre>
template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-5- <i>Requires:</i> Uses-allocator construction of <tt>T</tt> with allocator <tt>resource()</tt> (see 
23.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>) and constructor arguments <tt>std::forward&lt;Args&gt;(args)...</tt> 
is well-formed. [<i>Note:</i> Uses-allocator construction is always well formed for types that do not use allocators.
&mdash; <i>end note</i>]
<p/>
-6- <i>Effects:</i> Construct a <tt>T</tt> object in the storage whose address is represented by <tt>p</tt> by 
uses-allocator construction with allocator <tt>resource()</tt> and constructor arguments <tt>std::forward&lt;Args&gt;(args)...</tt>.
<p/>
-7- <i>Throws:</i> Nothing unless the constructor for <tt>T</tt> throws.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution if <tt>T</tt> is a specialization 
of <tt>pair</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>Modify 23.13.4 <a href="https://wg21.link/allocator.adaptor.members">[allocator.adaptor.members]</a> as indicated:</p>

<blockquote>
<pre>
template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-9- <i>Effects:</i> [&hellip;]
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution if <tt>T</tt> is a specialization 
of <tt>pair</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2989" href="#2989">2989</a><sup><a href="https://cplusplus.github.io/LWG/issue2989">(i)</a></sup>. <tt>path</tt>'s stream insertion operator lets you insert everything under the sun</h3>
<p><b>Section:</b> 30.11.7.6.1 <a href="https://wg21.link/fs.path.io">[fs.path.io]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2017-06-27 <b>Last modified:</b> 2018-01-28</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The rules for converting a <tt>path</tt> to a narrow character sequence aren't necessarily the same as that iostreams should use. Note that this program creates a temporary path and stream inserts that, which likely destroys information.
</p>

<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;filesystem&gt;
#include &lt;string&gt;

void foo() {
  using namespace std;
  using namespace std::experimental::filesystem::v1;
  wstring val(L"abc");
  std::cout &lt;&lt; val;
}
</pre></blockquote>
<p>
Using <a href="https://godbolt.org/g/dTQ8Pw">the godbolt online compiler</a> we get:
</p>
<blockquote><pre>
foo PROC
  sub      rsp, 104   ; 00000068H
  lea      rdx, OFFSET FLAT:$SG44895
  lea      rcx, QWORD PTR val$[rsp]
  call     std::basic_string&lt;wchar_t,std::char_traits&lt;wchar_t&gt;,std::allocator&lt;wchar_t&gt;
           &gt;::basic_string&lt;wchar_t,std::char_traits&lt;wchar_t&gt;,std::allocator&lt;wchar_t&gt; &gt;
  lea      rdx, QWORD PTR val$[rsp]
  lea      rcx, QWORD PTR $T1[rsp]
  call     ??$?0_WU?$char_traits@_W@std@@V?$allocator@_W@1@@path@v1@filesystem@experimental@std@@QEAA@AEBV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@4@@Z
  lea      rdx, QWORD PTR $T1[rsp]
  lea      rcx, OFFSET FLAT:std::cout
  <span style="color:#C80000;font-weight:bold">call     std::experimental::filesystem::v1::operator&lt;&lt;&lt;char,std::char_traits&lt;char&gt; &gt;</span>
  lea      rcx, QWORD PTR $T1[rsp]
  <span style="color:#C80000;font-weight:bold">call     std::experimental::filesystem::v1::path::~path</span>
  lea      rcx, QWORD PTR val$[rsp]
  call     std::basic_string&lt;wchar_t,std::char_traits&lt;wchar_t&gt;,std::allocator&lt;wchar_t&gt;
           &gt;::~basic_string&lt;wchar_t,std::char_traits&lt;wchar_t&gt;,std::allocator&lt;wchar_t&gt; &gt;
  add      rsp, 104   ; 00000068H
  ret      0
foo ENDP
</pre></blockquote>
<p>
This should either be disabled with a SFINAE constraint, use the <tt>auto_ptr</tt> user-defined conversion
trick, or the stream insertion operators should be made "hidden friends" to prevent conversions to <tt>path</tt>
from being considered here.
</p>

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

<p>Priority 2</p>

<p><i>[2017-07 Toronto Saturday afternoon]</i></p>

<p>LWG confirmed they want the hidden friend solution, Billy O'Neal to provide wording.</p>

<p><i>[2018-1-26 issues processing telecon]</i></p>

<p>Status to 'Tentatively Ready'</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 30.11.5 <a href="https://wg21.link/fs.filesystem.syn">[fs.filesystem.syn]</a>, header <tt>&lt;filesystem&gt;</tt> synopsis, as indicated:</p>

<blockquote><pre>
<del><i>// 30.11.7.6.1 <a href="https://wg21.link/fs.path.io">[fs.path.io]</a>,</i> path <i>inserter and extractor</i>
template &lt;class charT, class traits&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const path&amp; p);
template &lt;class charT, class traits&gt;
  basic_istream&lt;charT, traits&gt;&amp;
    operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, path&amp; p);</del>
</pre></blockquote></li>

<li><p>Edit 30.11.7.6.1 <a href="https://wg21.link/fs.path.io">[fs.path.io]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The project editor is kindly asked to consider to move sub-clause 30.11.7.6.1 <a href="https://wg21.link/fs.path.io">[fs.path.io]</a> 
<em>before</em> sub-clause 30.11.7.6 <a href="https://wg21.link/fs.path.nonmember">[fs.path.nonmember]</a> (as a peer of it) &mdash; <i>end drafting note</i>]
</p>
</blockquote>

<blockquote><pre>
template &lt;class charT, class traits&gt;
  <ins>friend</ins> basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const path&amp; p);

[&hellip;]

template &lt;class charT, class traits&gt;
  <ins>friend</ins> basic_istream&lt;charT, traits&gt;&amp;
    operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, path&amp; p);
</pre></blockquote></li>

<li><p>Edit 30.11.7 <a href="https://wg21.link/fs.class.path">[fs.class.path]</a> p2, class <tt>path</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std::filesystem {
  class path {
  public:
    [&hellip;]
    iterator begin() const;
    iterator end() const;

    <ins><i>// 30.11.7.6.1 <a href="https://wg21.link/fs.path.io">[fs.path.io]</a></i> path <i>inserter and extractor</i>
    template &lt;class charT, class traits&gt;
      friend basic_ostream&lt;charT, traits&gt;&amp;
        operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const path&amp; p);
    template &lt;class charT, class traits&gt;
      friend basic_istream&lt;charT, traits&gt;&amp;
        operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, path&amp; p);</ins>
  };
}
</pre></blockquote></li>
</ol>




<hr>
<h3><a name="3000" href="#3000">3000</a><sup><a href="https://cplusplus.github.io/LWG/issue3000">(i)</a></sup>. <tt>monotonic_memory_resource::do_is_equal</tt> uses <tt>dynamic_cast</tt> unnecessarily</h3>
<p><b>Section:</b> 23.12.6.2 <a href="https://wg21.link/mem.res.monotonic.buffer.mem">[mem.res.monotonic.buffer.mem]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2017-07-14 <b>Last modified:</b> 2017-11-12</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>
Section [mem.res.monotonic.buffer.mem], paragraph 11 says
</p>
<blockquote>
<pre>
bool do_is_equal(const memory_resource&amp; other) const noexcept override;
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>this == dynamic_cast&lt;const monotonic_buffer_resource*&gt;(&amp;other)</tt>.
</p>
</blockquote>
</blockquote>
<p>
The <tt>dynamic_cast</tt> adds nothing of value. It is an incorrect cut-and-paste from an example <tt>do_is_equal</tt>
for a more complex resource.
</p>

<p><i>[2017-07-16, Tim Song comments]</i></p>

<p>
The pool resource classes appear to also have this issue.
</p>

<p><i>[2017-09-18, Casey Carter expands PR to cover the pool resources.]</i></p>


<strong>Previous resolution: [SUPERSEDED]</strong>

<blockquote class="note">
<ol>
<li><p>Edit 23.12.6.2 <a href="https://wg21.link/mem.res.monotonic.buffer.mem">[mem.res.monotonic.buffer.mem]</a> as indicated:</p>

<blockquote><pre>
bool do_is_equal(const memory_resource&amp; other) const noexcept override;
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>this == <del>dynamic_cast&lt;const monotonic_buffer_resource*&gt;(</del>&amp;other<del>)</del></tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[
2017-11-01 Moved to Tentatively Ready after 7 positive votes for P0 on c++std-lib.
]</i></p>



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

<ol>
<li><p>Edit 23.12.5.4 <a href="https://wg21.link/mem.res.pool.mem">[mem.res.pool.mem]</a> as indicated:</p>

<blockquote><pre>
bool <del>synchronized_pool_resource::</del>do_is_equal(<ins>const memory_resource&amp; other) const noexcept override;</ins>
    <del>const memory_resource&amp; other) const noexcept override;</del>
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>this == <del>dynamic_cast&lt;const synchronized_pool_resource*&gt;(</del>&amp;other<del>)</del></tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Strike 23.12.5.4 <a href="https://wg21.link/mem.res.pool.mem">[mem.res.pool.mem]</a> paragraph 10, and the immediately preceding declaration of <tt>unsynchronized_pool_resource::do_is_equal</tt>.</p>
</li>

<li><p>Edit 23.12.6.2 <a href="https://wg21.link/mem.res.monotonic.buffer.mem">[mem.res.monotonic.buffer.mem]</a> as indicated:</p>

<blockquote><pre>
bool do_is_equal(const memory_resource&amp; other) const noexcept override;
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>this == <del>dynamic_cast&lt;const monotonic_buffer_resource*&gt;(</del>&amp;other<del>)</del></tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3002" href="#3002">3002</a><sup><a href="https://cplusplus.github.io/LWG/issue3002">(i)</a></sup>. [networking.ts] <tt>basic_socket_acceptor::is_open()</tt> isn't <tt>noexcept</tt></h3>
<p><b>Section:</b> 99 [networking.ts::socket.acceptor.ops] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2017-07-14 <b>Last modified:</b> 2017-11-12</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: networking.ts</b></p>
<p>
<tt>basic_socket::is_open()</tt> is <tt>noexcept</tt>, but the corresponding function on
<tt>basic_socket_acceptor</tt> is not. This is a simple observer with a wide contract and cannot fail.</p>

<p><i>[
2017-11-01 Moved to Tentatively Ready after 7 positive votes for P0 on c++std-lib.
]</i></p>



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

<ol>
<li><p>Edit  [networking.ts::socket.acceptor], class template <tt>basic_socket_acceptor</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
template&lt;class AcceptableProtocol&gt; 
class basic_socket_acceptor {
public:
  [&hellip;]
  bool is_open() const <ins>noexcept</ins>;
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Edit 99 [networking.ts::socket.acceptor.ops] as indicated:</p>

<blockquote>
<pre>
bool is_open() const <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-10- <i>Returns:</i> A <tt>bool</tt> indicating whether this acceptor was opened by a previous call to <tt>open</tt> or <tt>assign</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3004" href="#3004">3004</a><sup><a href="https://cplusplus.github.io/LWG/issue3004">(i)</a></sup>. &sect;[string.capacity] and &sect;[vector.capacity] should specify time complexity for <tt>capacity()</tt></h3>
<p><b>Section:</b> 24.3.2.4 <a href="https://wg21.link/string.capacity">[string.capacity]</a>, 26.3.11.3 <a href="https://wg21.link/vector.capacity">[vector.capacity]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Andy Giese <b>Opened:</b> 2017-07-24 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.capacity">active issues</a> in [string.capacity].</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>
<tt>basic_string</tt> and <tt>vector</tt> both have a <tt>capacity</tt> function that returns the size of the internally 
allocated buffer. This function does not specify a time complexity nor does it have an implied time complexity. However, 
given the complexities for <tt>data()</tt> to be <tt>&#x1d4aa;(1)</tt> and <tt>size()</tt> to be <tt>&#x1d4aa;(1)</tt>, 
we can imagine that it's reasonable to also require <tt>capacity()</tt> to be <tt>&#x1d4aa;(1)</tt>, since the 
implementation will most likely be caching the size of the allocated buffer so as to check for the need to reallocate 
on insertion.
</p>

<p><i>[
2017-11-01 Moved to Tentatively Ready after 10 positive votes for P0 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 24.3.2.4 <a href="https://wg21.link/string.capacity">[string.capacity]</a> as indicated:</p>

<blockquote>
<pre>
size_type capacity() const noexcept;
</pre>
<blockquote>
<p>
-9- <i>Returns:</i> The size of the allocated storage in the string.
<p/>
<ins>-?- <i>Complexity:</i> Constant time.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 26.3.11.3 <a href="https://wg21.link/vector.capacity">[vector.capacity]</a> as indicated:</p>

<blockquote>
<pre>
size_type capacity() const noexcept;
</pre>
<blockquote>
<p>
-1- <i>Returns:</i> The total number of elements that the vector can hold without requiring reallocation.
<p/>
<ins>-?- <i>Complexity:</i> Constant time.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3005" href="#3005">3005</a><sup><a href="https://cplusplus.github.io/LWG/issue3005">(i)</a></sup>. Destruction order of arrays by <tt>make_shared/allocate_shared</tt> only recommended?</h3>
<p><b>Section:</b> 23.11.3.6 <a href="https://wg21.link/util.smartptr.shared.create">[util.smartptr.shared.create]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2017-08-01 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared.create">active issues</a> in [util.smartptr.shared.create].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.create">issues</a> in [util.smartptr.shared.create].</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 [util.smartptr.shared.create]/7.9 we find this:
</p>
<blockquote><p>
"When the lifetime of the object managed by the return value ends, or when the initialization of an 
array element throws an exception, the initialized elements should be destroyed in the reverse order 
of their construction."
</p></blockquote>
<p>
Why is this only a "should be" and not a "shall be" (or, following usual conventions for how we write 
requirements on the implementation, "are")? Is there some problem that means we can't require an 
implementation to destroy in reverse construction order in all cases?
</p>

<strong>Previous resolution: [SUPERSEDED]</strong>

<blockquote class="note">
<p>This resolution is relative to <a href="http://wg21.link/n4687">N4687</a>.</p>

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

<blockquote>
<pre>
template&lt;class T, ...&gt;
shared_ptr&lt;T&gt; make_shared(<i>args</i>);
template&lt;class T, class A, ...&gt;
shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, <i>args</i>);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-7- <i>Remarks:</i>
</p>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(7.9) &mdash; When the lifetime of the object managed by the return value ends, or when the initialization of
an array element throws an exception, the initialized elements <ins>are</ins><del>should be</del> destroyed in 
<ins>decreasing index order</ins><del>the reverse order of their construction</del>.</p></li>
</ol>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2017-11-01, Alisdair comments and suggests wording improvement]</i></p>

<p>
I dislike the change of how we specify the order of destruction, which is clear (but
non-normative) from the preceding paragraph making the order of construction
explicit.  We are replacing that with a different specification, so now I need to match
up ""decreasing index order" to "ascending order of address" to infer the behavior that
is worded more directly today.
<p/>
P0 to change "should be" to "are" though.
</p>

<strong>Previous resolution: [SUPERSEDED]</strong>

<blockquote class="note">
<p>This resolution is relative to <a href="http://wg21.link/n4700">N4700</a>.</p>

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

<blockquote>
<pre>
template&lt;class T, ...&gt;
shared_ptr&lt;T&gt; make_shared(<i>args</i>);
template&lt;class T, class A, ...&gt;
shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, <i>args</i>);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-7- <i>Remarks:</i>
</p>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(7.9) &mdash; When the lifetime of the object managed by the return value ends, or when the initialization of
an array element throws an exception, the initialized elements <ins>are</ins><del>should be</del> destroyed in 
the reverse order of their construction.</p></li>
</ol>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2017-11-01]</i></p>

<p>
The rationale for the "decreasing index order" change in the original P/R suggested by Richard Smith had been presented 
as that user code may destroy one or more array elements and construct new ones in their place. In those cases 
<tt>shared_ptr</tt> has no way of knowing the construction order, so it cannot ensure that the destruction order reverses 
it.<br/>
Richard: Perhaps something like:
</p>
<blockquote><p>
the initialized elements <ins>are</ins> <del>should be</del> destroyed in the reverse order of their <ins>original</ins> construction.
</p></blockquote>
<p>
would work?
</p>

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



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

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

<blockquote>
<pre>
template&lt;class T, ...&gt;
shared_ptr&lt;T&gt; make_shared(<i>args</i>);
template&lt;class T, class A, ...&gt;
shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, <i>args</i>);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-7- <i>Remarks:</i>
</p>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(7.9) &mdash; When the lifetime of the object managed by the return value ends, or when the initialization of
an array element throws an exception, the initialized elements <ins>are</ins><del>should be</del> destroyed in 
the reverse order of their <ins>original</ins> construction.</p></li>
</ol>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3007" href="#3007">3007</a><sup><a href="https://cplusplus.github.io/LWG/issue3007">(i)</a></sup>. <tt>allocate_shared</tt> should rebind allocator to <i>cv</i>-unqualified <tt>value_type</tt> for construction</h3>
<p><b>Section:</b> 23.11.3.6 <a href="https://wg21.link/util.smartptr.shared.create">[util.smartptr.shared.create]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Glen Joseph Fernandes <b>Opened:</b> 2017-08-06 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared.create">active issues</a> in [util.smartptr.shared.create].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.create">issues</a> in [util.smartptr.shared.create].</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 remarks for the <tt>allocate_shared</tt> family of functions
specify that when constructing a (sub)object of type <tt>U</tt>, it uses a
rebound copy of the allocator <tt>a</tt> passed to
<tt>allocate_shared</tt> such that its <tt>value_type</tt> is
<tt>U</tt>. However <tt>U</tt> can be a <tt>const</tt> or
<tt>volatile</tt> qualified type, and [allocator.requirements] specify
that the <tt>value_type</tt> must be <i>cv</i>-unqualified.
</p>

<p><i>[
2017-11-01 Moved to Tentatively Ready after 6 positive votes for P0 on c++std-lib.
]</i></p>



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

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

<blockquote>
<pre>
template&lt;class T, ...&gt;
shared_ptr&lt;T&gt; make_shared(<i>args</i>);
template&lt;class T, class A, ...&gt;
shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, <i>args</i>);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-7- <i>Remarks:</i>
</p>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(7.5) &mdash; When a (sub)object of a non-array type <tt>U</tt> is specified to have an initial value of <tt>v</tt>, 
or <tt>U(l...)</tt>, where <tt>l...</tt> is a list of constructor arguments, <tt>allocate_shared</tt> shall initialize this 
(sub)object via the expression</p>
<ol style="list-style-type: none">
<li><p>(7.5.1) &mdash; <tt>allocator_traits&lt;A2&gt;::construct(a2, pv, v)</tt> or</p></li>
<li><p>(7.5.2) &mdash; <tt>allocator_traits&lt;A2&gt;::construct(a2, pv, l...)</tt></p></li>
</ol>
<p>
respectively, where <tt>pv</tt> points to storage suitable to hold an object of type <tt>U</tt> and <tt>a2</tt> of 
type <tt>A2</tt> is a rebound copy of the allocator a passed to <tt>allocate_shared</tt> such that its 
<tt>value_type</tt> is <tt><ins>remove_cv_t&lt;</ins>U<ins>&gt;</ins></tt>.
</p>
</li>
<li><p>(7.6) &mdash; When a (sub)object of non-array type <tt>U</tt> is specified to have a default initial value, 
<tt>make_shared</tt> shall initialize this (sub)object via the expression <tt>::new(pv) U()</tt>, where <tt>pv</tt> 
has type <tt>void*</tt> and points to storage suitable to hold an object of type <tt>U</tt>.</p></li>
<li><p>(7.7) &mdash; When a (sub)object of non-array type <tt>U</tt> is specified to have a default initial value, 
<tt>allocate_shared</tt> shall initialize this (sub)object via the expression <tt>allocator_traits&lt;A2&gt;::construct(a2, pv)</tt>,
where <tt>pv</tt> points to storage suitable to hold an object of type <tt>U</tt> and <tt>a2</tt> of type <tt>A2</tt> 
is a rebound copy of the allocator a passed to <tt>allocate_shared</tt> such that its <tt>value_type</tt> is 
<tt><ins>remove_cv_t&lt;</ins>U<ins>&gt;</ins></tt>.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3009" href="#3009">3009</a><sup><a href="https://cplusplus.github.io/LWG/issue3009">(i)</a></sup>. Including <tt>&lt;string_view&gt;</tt> doesn't provide <tt>std::size/empty/data</tt></h3>
<p><b>Section:</b> 27.8 <a href="https://wg21.link/iterator.container">[iterator.container]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-08-11 <b>Last modified:</b> 2017-11-12</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>
<tt>basic_string_view</tt> has <tt>size()</tt>, <tt>empty()</tt>, and <tt>data()</tt> members, but
including <tt>&lt;string_view&gt;</tt> isn't guaranteed to give you access to the
corresponding free function templates. This seems surprising.
</p>

<p><i>[
2017-11-01 Moved to Tentatively Ready after 7 positive votes for P0 on c++std-lib.
]</i></p>



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

<ol>
<li><p>Edit 27.8 <a href="https://wg21.link/iterator.container">[iterator.container]</a> 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 
27.8 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="3010" href="#3010">3010</a><sup><a href="https://cplusplus.github.io/LWG/issue3010">(i)</a></sup>. [networking.ts] <tt>uses_executor</tt> says "if a type <tt>T::executor_type</tt> exists"</h3>
<p><b>Section:</b> 99 [networking.ts::async.uses.excecutor.trait] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2017-08-17 <b>Last modified:</b> 2017-11-12</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: networking.ts</b></p>
<p>
[async.uses.executor.trait] p1 says "if a type <tt>T::executor_type</tt> exists" but we don't want it to be required 
to detect private or ambiguous types.
</p>

<p><i>[
2017-11-01 Moved to Tentatively Ready after 7 positive votes for P0 on c++std-lib.
]</i></p>



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

<ol>
<li><p>Edit  [networking.ts::async.uses.executor.trait] as indicated:</p>

<blockquote>
<p>
-1- Remark: Detects whether <tt>T</tt> has a nested <tt>executor_type</tt> that is convertible from
<tt>Executor</tt>. Meets the <tt>BinaryTypeTrait</tt> requirements (C++Std [meta.rqmts]). The implementation 
provides a definition that is derived from <tt>true_type</tt> if <del>a type</del><ins>the <em>qualified-id</em></ins> 
<tt>T::executor_type</tt> <del>exists</del><ins>is valid and denotes a type</ins> and 
<tt>is_convertible&lt;Executor, T::executor_type&gt;::value != false</tt>, otherwise it is derived from
<tt>false_type</tt>. A program may specialize this template [&hellip;].
</p>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3013" href="#3013">3013</a><sup><a href="https://cplusplus.github.io/LWG/issue3013">(i)</a></sup>. <tt>(recursive_)directory_iterator</tt> construction and traversal should not be <tt>noexcept</tt></h3>
<p><b>Section:</b> 30.11.12.1 <a href="https://wg21.link/fs.dir.itr.members">[fs.dir.itr.members]</a>, 30.11.13.1 <a href="https://wg21.link/fs.rec.dir.itr.members">[fs.rec.dir.itr.members]</a>, 30.11.14.3 <a href="https://wg21.link/fs.op.copy">[fs.op.copy]</a>, 30.11.14.19 <a href="https://wg21.link/fs.op.is_empty">[fs.op.is_empty]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-08-23 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fs.dir.itr.members">active issues</a> in [fs.dir.itr.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.dir.itr.members">issues</a> in [fs.dir.itr.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Constructing a <tt>(recursive_)directory_iterator</tt> from a <tt>path</tt> requires, at a minimum, initializing its 
underlying <tt>directory_entry</tt> object with the <tt>path</tt> formed from the supplied <tt>path</tt> and the name of the 
first entry, which requires a potentially throwing memory allocation; every implementation I've looked at also allocates 
memory to store additional data as well.
<p/>
Similarly, <tt>increment()</tt> needs to update the <tt>path</tt> stored in <tt>directory_entry</tt> object to refer 
to the name of the next entry, which may require a memory allocation. While it might conceivably be possible to 
postpone the update in this case until the iterator is dereferenced (the dereference operation is not <tt>noexcept</tt> 
due to its narrow contract), it seems highly unlikely that such an implementation is intended (not to mention that it 
would require additional synchronization as the dereference operations are const).
<p/>
This further calls into question whether the <tt>error_code</tt> overloads of <tt>copy</tt> and <tt>is_empty</tt>, 
whose specification uses <tt>directory_iterator</tt>, should be <tt>noexcept</tt>. There might be a case for keeping 
the <tt>noexcept</tt> for <tt>is_empty</tt>, although that would require changes in all implementations I checked 
(libstdc++, libc++, and Boost). <tt>copy</tt> appears to be relentlessly hostile to <tt>noexcept</tt>, since its 
specification forms a <tt>path</tt> via <tt>operator/</tt> in two places (bullets 4.7.4 and 4.8.2) in addition to the 
<tt>directory_iterator</tt> usage. The proposed resolution below removes both.
</p>

<p><i>[
2017-11-03 Moved to Tentatively Ready after 7 positive votes for P0 on c++std-lib.
]</i></p>



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

<ol>
<li><p>Edit 30.11.12 <a href="https://wg21.link/fs.class.directory_iterator">[fs.class.directory_iterator]</a>, class <tt>directory_iterator</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
[&hellip;]
explicit directory_iterator(const path&amp; p);
directory_iterator(const path&amp; p, directory_options options);
directory_iterator(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
directory_iterator(const path&amp; p, directory_options options,
                   error_code&amp; ec) <del>noexcept</del>;
[&hellip;]

directory_iterator&amp; operator++();
directory_iterator&amp; increment(error_code&amp; ec) <del>noexcept</del>;
</pre>
</blockquote>
</li>

<li><p>Edit 30.11.12.1 <a href="https://wg21.link/fs.dir.itr.members">[fs.dir.itr.members]</a> before p2 as indicated:</p>
<blockquote>
<pre>
explicit directory_iterator(const path&amp; p);
directory_iterator(const path&amp; p, directory_options options);
directory_iterator(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
directory_iterator(const path&amp; p, directory_options options, error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> [&hellip;]
<p/>
-3- <i>Throws:</i> As specified in 30.11.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a>.
<p/>
-4- [<i>Note:</i> [&hellip;] &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 30.11.12.1 <a href="https://wg21.link/fs.dir.itr.members">[fs.dir.itr.members]</a> before p10 as indicated:</p>
<blockquote>
<pre>
directory_iterator&amp; operator++();
directory_iterator&amp; increment(error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-10- <i>Effects:</i> As specified for the prefix increment operation of Input iterators (24.2.3).
<p/>
-11- <i>Returns:</i> <tt>*this</tt>.
<p/>
-12- <i>Throws:</i> As specified in 30.11.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 30.11.13 <a href="https://wg21.link/fs.class.rec.dir.itr">[fs.class.rec.dir.itr]</a>, class <tt>recursive_directory_iterator</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
[&hellip;]
explicit recursive_directory_iterator(const path&amp; p);
recursive_directory_iterator(const path&amp; p, directory_options options);
recursive_directory_iterator(const path&amp; p, directory_options options,
                             error_code&amp; ec) <del>noexcept</del>;
recursive_directory_iterator(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
[&hellip;]

recursive_directory_iterator&amp; operator++();
recursive_directory_iterator&amp; increment(error_code&amp; ec) <del>noexcept</del>;
</pre>
</blockquote>
</li>

<li><p>Edit 30.11.13.1 <a href="https://wg21.link/fs.rec.dir.itr.members">[fs.rec.dir.itr.members]</a> before p2 as indicated:</p>
<blockquote>
<pre>
explicit recursive_directory_iterator(const path&amp; p);
recursive_directory_iterator(const path&amp; p, directory_options options);
recursive_directory_iterator(const path&amp; p, directory_options options, error_code&amp; ec) <del>noexcept</del>;
recursive_directory_iterator(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> [&hellip;]
<p/>
-3- <i>Postconditions:</i> [&hellip;]
<p/>
-4- <i>Throws:</i> As specified in 30.11.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a>.
<p/>
-5- [<i>Note:</i> [&hellip;] &mdash; <i>end note</i>]
<p/>
-6- [<i>Note:</i> [&hellip;] &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 30.11.13.1 <a href="https://wg21.link/fs.rec.dir.itr.members">[fs.rec.dir.itr.members]</a> before p23 as indicated:</p>
<blockquote>
<pre>
recursive_directory_iterator&amp; operator++();
recursive_directory_iterator&amp; increment(error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-23- <i>Effects:</i> As specified for the prefix increment operation of Input iterators (24.2.3), except that: [&hellip;]
<p/>
-24- <i>Returns:</i> <tt>*this</tt>.
<p/>
-25- <i>Throws:</i> As specified 30.11.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 30.11.5 <a href="https://wg21.link/fs.filesystem.syn">[fs.filesystem.syn]</a>, header <tt>&lt;filesystem&gt;</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std::filesystem {

  [&hellip;]

  void copy(const path&amp; from, const path&amp; to);
  void copy(const path&amp; from, const path&amp; to, error_code&amp; ec) <del>noexcept</del>;
  void copy(const path&amp; from, const path&amp; to, copy_options options);
  void copy(const path&amp; from, const path&amp; to, copy_options options,
            error_code&amp; ec) <del>noexcept</del>;

  [&hellip;]

  bool is_empty(const path&amp; p);
  bool is_empty(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
  
  [&hellip;]

}
</pre>
</blockquote>
</li>

<li><p>Edit 30.11.14.3 <a href="https://wg21.link/fs.op.copy">[fs.op.copy]</a> as indicated:</p>
<blockquote>
<pre>
void copy(const path&amp; from, const path&amp; to, error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> Equivalent to <tt>copy(from, to, copy_options::none, ec)</tt>.
</p>
</blockquote>
<pre>
void copy(const path&amp; from, const path&amp; to, copy_options options);
void copy(const path&amp; from, const path&amp; to, copy_options options,
          error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-3- <i>Requires:</i> [&hellip;]
<p/>
-4- <i>Effects:</i> [&hellip;]
<p/>
-5- <i>Throws:</i> [&hellip;]
<p/>
-6- <i>Remarks:</i> [&hellip;]
<p/>
-7- [<i>Example:</i> [&hellip;] &mdash; <i>end example</i>]
</p>
</blockquote>
</blockquote>
</li>


<li><p>Edit 30.11.14.19 <a href="https://wg21.link/fs.op.is_empty">[fs.op.is_empty]</a> as indicated:</p>
<blockquote>
<pre>
bool is_empty(const path&amp; p);
bool is_empty(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> [&hellip;]
<p/>
-2- <i>Throws:</i> [&hellip;]
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3014" href="#3014">3014</a><sup><a href="https://cplusplus.github.io/LWG/issue3014">(i)</a></sup>. More <tt>noexcept</tt> issues with filesystem operations</h3>
<p><b>Section:</b> 30.11.14.4 <a href="https://wg21.link/fs.op.copy_file">[fs.op.copy_file]</a>, 30.11.14.6 <a href="https://wg21.link/fs.op.create_directories">[fs.op.create_directories]</a>, 30.11.14.31 <a href="https://wg21.link/fs.op.remove_all">[fs.op.remove_all]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-08-23 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fs.op.copy_file">active issues</a> in [fs.op.copy_file].</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.op.copy_file">issues</a> in [fs.op.copy_file].</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>create_directories</tt> may need to create temporary <tt>path</tt>s, and <tt>remove_all</tt> may need to create temporary 
<tt>path</tt>s and/or <tt>directory_iterator</tt>s. These operations may require a potentially throwing memory allocation.
<p/>
Implementations of <tt>copy_file</tt> may wish to dynamically allocate the buffer used for copying when the underlying OS 
doesn't supply a copy API directly. This can happen indirectly, e.g., by using <tt>&lt;fstream&gt;</tt> facilities to 
perform the copying without supplying a custom buffer. Unless LWG wishes to prohibit using a dynamically allocated buffer 
in this manner, the <tt>noexcept</tt> should be removed.
</p>

<p><i>[2017-11 Albuquerque Wednesday night issues processing]</i></p>

<p>Moved to Ready</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>Edit 30.11.5 <a href="https://wg21.link/fs.filesystem.syn">[fs.filesystem.syn]</a>, header <tt>&lt;filesystem&gt;</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std::filesystem {

  [&hellip;]
  
  bool copy_file(const path&amp; from, const path&amp; to);
  bool copy_file(const path&amp; from, const path&amp; to, error_code&amp; ec) <del>noexcept</del>;
  bool copy_file(const path&amp; from, const path&amp; to, copy_options option);
  bool copy_file(const path&amp; from, const path&amp; to, copy_options option,
                 error_code&amp; ec) <del>noexcept</del>;

  [&hellip;]

  bool create_directories(const path&amp; p);
  bool create_directories(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
  
  [&hellip;]
  
  uintmax_t remove_all(const path&amp; p);
  uintmax_t remove_all(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
  
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Edit 30.11.14.4 <a href="https://wg21.link/fs.op.copy_file">[fs.op.copy_file]</a> as indicated:</p>
<blockquote>
<pre>
bool copy_file(const path&amp; from, const path&amp; to);
bool copy_file(const path&amp; from, const path&amp; to, error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-1- <i>Returns:</i> [&hellip;]
<p/>
-2- <i>Throws:</i> [&hellip;]
</p>
</blockquote>
<pre>
bool copy_file(const path&amp; from, const path&amp; to, copy_options options);
bool copy_file(const path&amp; from, const path&amp; to, copy_options options,
               error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-3- <i>Requires:</i> [&hellip;]
<p/>
-4- <i>Effects:</i> [&hellip;]
<p/>
-5- <i>Returns:</i> [&hellip;]
<p/>
-6- <i>Throws:</i> [&hellip;]
<p/>
-7- <i>Complexity:</i> [&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 30.11.14.6 <a href="https://wg21.link/fs.op.create_directories">[fs.op.create_directories]</a> as indicated:</p>
<blockquote>
<pre>
bool create_directories(const path&amp; p);
bool create_directories(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> [&hellip;]
<p/>
-2- <i>Postconditions:</i> [&hellip;]
<p/>
-3- <i>Returns:</i> [&hellip;]
<p/>
-4- <i>Throws:</i> [&hellip;]
<p/>
-5- <i>Complexity:</i> [&hellip;]
</p>
</blockquote>
</blockquote>
</li>
<li><p>Edit 30.11.14.31 <a href="https://wg21.link/fs.op.remove_all">[fs.op.remove_all]</a> as indicated:</p>
<blockquote>
<pre>
uintmax_t remove_all(const path&amp; p);
uintmax_t remove_all(const path&amp; p, error_code&amp; ec) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> [&hellip;]
<p/>
-2- <i>Postconditions:</i> [&hellip;]
<p/>
-3- <i>Returns:</i> [&hellip;]
<p/>
-4- <i>Throws:</i> [&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3015" href="#3015">3015</a><sup><a href="https://cplusplus.github.io/LWG/issue3015">(i)</a></sup>. <tt>copy_options::<i>unspecified</i></tt> underspecified</h3>
<p><b>Section:</b> 30.11.14.3 <a href="https://wg21.link/fs.op.copy">[fs.op.copy]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-08-24 <b>Last modified:</b> 2018-01-28</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fs.op.copy">active issues</a> in [fs.op.copy].</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.op.copy">issues</a> in [fs.op.copy].</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>
30.11.14.3 <a href="https://wg21.link/fs.op.copy">[fs.op.copy]</a>/4.8.2 says in the copy-a-directory case <tt>filesystem::copy</tt> performs:
<blockquote>
<pre>
for (const directory_entry&amp; x : directory_iterator(from))
  copy(x.path(), to/x.path().filename(), options | copy_options::<i>unspecified</i>);
</pre>
</blockquote>
<p/>
Presumably this does not actually mean that the implementation is free to set whatever <tt>copy_option</tt> element it wishes 
(<tt>directories_only</tt>? <tt>recursive</tt>? <tt>create_hard_links</tt>?), or <tt>none</tt> at all, or &ndash; since 
unspecified behavior corresponds to the nondeterministic aspects of the abstract machine (6.8.1 <a href="https://wg21.link/intro.execution">[intro.execution]</a>/3) 
&ndash; a nondeterministically picked element for every iteration of the loop. That would be outright insane.
<p/>
I'm fairly sure that what's intended here is to set an otherwise-unused bit in <tt>options</tt> so as to prevent recursion in the <tt>options == copy_options::none</tt> case.
</p>

<p><i>[2017-11-08]</i></p>

<p>Priority set to 3 after five votes on the mailing list</p>

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

<ol>
<li><p>Edit 30.11.14.3 <a href="https://wg21.link/fs.op.copy">[fs.op.copy]</a> p4, bullet 4.8.2 as indicated:</p>
<blockquote>
<ol style="list-style-type: none">
<li><p>(4.7) &mdash; Otherwise, if <tt>is_regular_file(f)</tt>, then:</p>
<blockquote>
[&hellip;]
</blockquote>
</li>
<li><p>(4.8) &mdash; Otherwise, if</p>
<blockquote>
<blockquote><pre>
is_directory(f) &amp;&amp;
((options &amp; copy_options::recursive) != copy_options::none ||
options == copy_options::none)
</pre></blockquote>
<p>
then:
</p>
</blockquote>
<ol style="list-style-type: none">
<li><p>(4.8.1) &mdash; If <tt>exists(t)</tt> is <tt>false</tt>, then <code>create_directory(to, from)</code>.</p></li>
<li><p>(4.8.2) &mdash; Then, iterate over the files in <code>from</code>, as if by </p>
<blockquote>
<blockquote><pre>
for (const directory_entry&amp; x : directory_iterator(from))
  copy(x.path(), to/x.path().filename(), options | copy_options::<i><del>unspecified</del><ins>in-recursive-copy</ins></i>)<ins>;</ins>
</pre></blockquote>
<p>
<ins>where <tt><i>in-recursive-copy</i></tt> is an exposition-only bitmask element of <tt>copy_options</tt> that is not one of the elements in 30.11.9.3 <a href="https://wg21.link/fs.enum.copy.opts">[fs.enum.copy.opts]</a>.</ins>
</p>
</blockquote>
</li>
</ol>
</li>
<li><p>(4.9) &mdash; Otherwise, for the signature with argument <tt>ec</tt>, <tt>ec.clear()</tt>.</p></li>
<li><p>(4.10) &mdash; Otherwise, no effects.</p></li>
</ol>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2018-1-26 issues processing telecon]</i></p>

<p>Status to 'Tentatively Ready' after striking the words 'Exposition-only' from the added text</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>Edit 30.11.14.3 <a href="https://wg21.link/fs.op.copy">[fs.op.copy]</a> p4, bullet 4.8.2 as indicated:</p>
<blockquote>
<ol style="list-style-type: none">
<li><p>(4.7) &mdash; Otherwise, if <tt>is_regular_file(f)</tt>, then:</p>
<blockquote>
[&hellip;]
</blockquote>
</li>
<li><p>(4.8) &mdash; Otherwise, if</p>
<blockquote>
<blockquote><pre>
is_directory(f) &amp;&amp;
((options &amp; copy_options::recursive) != copy_options::none ||
options == copy_options::none)
</pre></blockquote>
<p>
then:
</p>
</blockquote>
<ol style="list-style-type: none">
<li><p>(4.8.1) &mdash; If <tt>exists(t)</tt> is <tt>false</tt>, then <code>create_directory(to, from)</code>.</p></li>
<li><p>(4.8.2) &mdash; Then, iterate over the files in <code>from</code>, as if by </p>
<blockquote>
<blockquote><pre>
for (const directory_entry&amp; x : directory_iterator(from))
  copy(x.path(), to/x.path().filename(), options | copy_options::<i><del>unspecified</del><ins>in-recursive-copy</ins></i>)<ins>;</ins>
</pre></blockquote>
<p>
<ins>where <tt><i>in-recursive-copy</i></tt> is an bitmask element of <tt>copy_options</tt> that is not one of the elements in 30.11.9.3 <a href="https://wg21.link/fs.enum.copy.opts">[fs.enum.copy.opts]</a>.</ins>
</p>
</blockquote>
</li>
</ol>
</li>
<li><p>(4.9) &mdash; Otherwise, for the signature with argument <tt>ec</tt>, <tt>ec.clear()</tt>.</p></li>
<li><p>(4.10) &mdash; Otherwise, no effects.</p></li>
</ol>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3017" href="#3017">3017</a><sup><a href="https://cplusplus.github.io/LWG/issue3017">(i)</a></sup>. <tt>list splice</tt> functions should use <tt>addressof</tt></h3>
<p><b>Section:</b> 26.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a>, 26.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2017-09-05 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.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>
26.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a> p1 and 26.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> p3 say <tt>&amp;x != this</tt>, but should use
<tt>addressof</tt>. We really need front matter saying that when the library says <tt>&amp;x</tt> it means 
<tt>std::addressof(x)</tt>.
</p>

<p><i>[
2017-11-03 Moved to Tentatively Ready after 9 positive votes for P0 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>Edit 26.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a> p1 as indicated:</p>
<blockquote>
<pre>
void splice_after(const_iterator position, forward_list&amp; x);
void splice_after(const_iterator position, forward_list&amp;&amp; x);
</pre>
<blockquote>
<p>
-1- <i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or is a dereferenceable iterator in the range <tt>[begin(), 
end())</tt>. <tt>get_allocator() == x.get_allocator()</tt>. <tt><del>&amp;</del><ins>addressof(</ins>x<ins>)</ins> != this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 26.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> p3 as indicated:</p>
<blockquote>
<pre>
void splice(const_iterator position, list&amp; x);
void splice(const_iterator position, list&amp;&amp; x);
</pre>
<blockquote>
<p>
-3- <i>Requires:</i> <tt><del>&amp;</del><ins>addressof(</ins>x<ins>)</ins> != this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 26.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> p3 as indicated:</p>
<blockquote>
<pre>
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> <tt>comp</tt> shall define a strict weak ordering (28.7 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a>), and both the list 
and the argument list shall be sorted according to this ordering.
<p/>
-23- <i>Effects:</i> If <tt>(<del>&amp;</del><ins>addressof(</ins>x<ins>)</ins> == this)</tt> does nothing; 
otherwise, merges the two sorted ranges <tt>[begin(), end())</tt> and <tt>[x.begin(), x.end())</tt>. The result 
is a range in which the elements will be sorted in non-decreasing order according to the ordering defined by 
<tt>comp</tt>; that is, for every iterator <tt>i</tt>, in the range other than the first, the condition 
<tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>. Pointers and references to the moved elements of <tt>x</tt> 
now refer to those same elements but as members of <tt>*this</tt>. Iterators referring to the moved elements 
will continue to refer to their elements, but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>.
<p/>
-24- <i>Remarks:</i> Stable (20.5.5.7 <a href="https://wg21.link/algorithm.stable">[algorithm.stable]</a>). If 
<tt>(<del>&amp;</del><ins>addressof(</ins>x<ins>)</ins> != this)</tt> the range <tt>[x.begin(), x.end())</tt> is 
empty after the merge. No elements are copied by this operation. The behavior is undefined if <tt>get_allocator() !=
x.get_allocator()</tt>.
<p/>
-25- <i>Complexity:</i> At most <tt>size() + x.size() - 1</tt> applications of <tt>comp</tt> if 
<tt>(<del>&amp;</del><ins>addressof(</ins>x<ins>)</ins> != this)</tt>; otherwise, no applications of <tt>comp</tt> are 
performed. If an exception is thrown other than by a comparison there are no effects.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3020" href="#3020">3020</a><sup><a href="https://cplusplus.github.io/LWG/issue3020">(i)</a></sup>. [networking.ts] Remove spurious nested <tt>value_type</tt> buffer sequence requirement</h3>
<p><b>Section:</b> 99 [networking.ts::buffer.reqmts] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Vinnie Falco <b>Opened:</b> 2017-09-20 <b>Last modified:</b> 2018-01-22</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: networking.ts</b></p>
<p>
The post-condition requirements for <tt>ConstBufferSequence</tt> and <tt>MutableBufferSequence</tt> refer to <tt>X::value_type</tt>, 
but no such nested type is required. The lambda expression passed to <tt>equal</tt> can use <tt>auto const&amp;</tt> parameter types 
instead. 
</p>

<strong>Previous resolution: [SUPERSEDED]</strong>

<blockquote class="note">
<p>
This wording is relative to <a href="http://wg21.link/n4588">N4588</a>.
</p>

<ol>
<li>
<p>
Modify 99 [networking.ts::buffer.reqmts.mutablebuffersequence] Table 12 "<tt>MutableBufferSequence</tt> requirements" as indicated:
</p>
<blockquote>
<table border="1">
<caption>Table 12 &mdash; <tt>MutableBufferSequence</tt> requirements</caption>
<tr>
<th>expression</th>
<th>return type</th>
<th>assertion/note pre/post-condition</th>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>X u(x);</tt>
</td>
<td>
</td>
<td>
post:<br/>
<pre>
equal(
  net::buffer_sequence_begin(x),
  net::buffer_sequence_end(x),
  net::buffer_sequence_begin(u),
  net::buffer_sequence_end(u),
  [](const <del>typename X::value_type</del><ins>auto</ins>&amp; v1,
     const <del>typename X::value_type</del><ins>auto</ins>&amp; v2)
    {
      mutable_buffer b1(v1);
      mutable_buffer b2(v2);
      return b1.data() == b2.data()
          &amp;&amp; b1.size() == b2.size();
    })
</pre>
</td>
</tr>
</table>
</blockquote>
</li>

<li>
<p>
Modify 99 [networking.ts::buffer.reqmts.constbuffersequence] Table 13 "<tt>ConstBufferSequence</tt> requirements" as indicated:
</p>
<blockquote>
<table border="1">
<caption>Table 13 &mdash; <tt>ConstBufferSequence</tt> requirements</caption>
<tr>
<th>expression</th>
<th>return type</th>
<th>assertion/note pre/post-condition</th>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>X u(x);</tt>
</td>
<td>
</td>
<td>
post:<br/>
<pre>
equal(
  net::buffer_sequence_begin(x),
  net::buffer_sequence_end(x),
  net::buffer_sequence_begin(u),
  net::buffer_sequence_end(u),
  [](const <del>typename X::value_type</del><ins>auto</ins>&amp; v1,
     const <del>typename X::value_type</del><ins>auto</ins>&amp; v2)
    {
      const_buffer b1(v1);
      const_buffer b2(v2);
      return b1.data() == b2.data()
          &amp;&amp; b1.size() == b2.size();
    })
</pre>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2017-10-19, Peter Dimov provides improved wording]</i></p>

<p>
The alternative wording prevents the need for <tt>auto</tt> parameters because it takes advantage of the "convertible to" 
requirement.
</p>

<p><i>[
2017-10-20 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/n4588">N4588</a>.
</p>

<ol>
<li>
<p>
Modify 99 [networking.ts::buffer.reqmts.mutablebuffersequence] Table 12 "<tt>MutableBufferSequence</tt> requirements" as indicated:
</p>
<blockquote>
<table border="1">
<caption>Table 12 &mdash; <tt>MutableBufferSequence</tt> requirements</caption>
<tr>
<th>expression</th>
<th>return type</th>
<th>assertion/note pre/post-condition</th>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>X u(x);</tt>
</td>
<td>
</td>
<td>
post:<br/>
<pre>
equal(
  net::buffer_sequence_begin(x),
  net::buffer_sequence_end(x),
  net::buffer_sequence_begin(u),
  net::buffer_sequence_end(u),
  [](const <del>typename X::value_type&amp; v1</del><ins>mutable_buffer&amp; b1</ins>,
     const <del>typename X::value_type&amp; v2</del><ins>mutable_buffer&amp; b2</ins>)
    {
      <del>mutable_buffer b1(v1);
      mutable_buffer b2(v2);</del>
      return b1.data() == b2.data()
          &amp;&amp; b1.size() == b2.size();
    })
</pre>
</td>
</tr>
</table>
</blockquote>
</li>

<li>
<p>
Modify 99 [networking.ts::buffer.reqmts.constbuffersequence] Table 13 "<tt>ConstBufferSequence</tt> requirements" as indicated:
</p>
<blockquote>
<table border="1">
<caption>Table 13 &mdash; <tt>ConstBufferSequence</tt> requirements</caption>
<tr>
<th>expression</th>
<th>return type</th>
<th>assertion/note pre/post-condition</th>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>X u(x);</tt>
</td>
<td>
</td>
<td>
post:<br/>
<pre>
equal(
  net::buffer_sequence_begin(x),
  net::buffer_sequence_end(x),
  net::buffer_sequence_begin(u),
  net::buffer_sequence_end(u),
  [](const <del>typename X::value_type&amp; v1</del><ins>const_buffer&amp; b1</ins>,
     const <del>typename X::value_type&amp; v2</del><ins>const_buffer&amp; v2</ins>)
    {
      <del>const_buffer b1(v1);
      const_buffer b2(v2);</del>
      return b1.data() == b2.data()
          &amp;&amp; b1.size() == b2.size();
    })
</pre>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3026" href="#3026">3026</a><sup><a href="https://cplusplus.github.io/LWG/issue3026">(i)</a></sup>. <tt>filesystem::weakly_canonical</tt> still defined in terms of <tt>canonical(p, base)</tt></h3>
<p><b>Section:</b> 30.11.14.39 <a href="https://wg21.link/fs.op.weakly_canonical">[fs.op.weakly_canonical]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2017-10-14 <b>Last modified:</b> 2018-01-22</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>
LWG <a href="lwg-defects.html#2956">2956</a> fixed <tt>canonical</tt> to no longer use a base path, but <tt>weakly_canonical</tt> should have been
changed too:
</p>
<blockquote><p>
<i>Effects:</i> Using <tt>status(p)</tt> or <tt>status(p, ec)</tt>, respectively, to determine
existence, return a path composed by <tt>operator/=</tt> from the result of calling <tt>canonical()</tt> without
a <tt>base</tt> argument and with a [&hellip;]
</p></blockquote>
<p>
Since <tt>canonical</tt> doesn't accept a <tt>base</tt> argument, it doesn't make sense
to talk about calling it without one.
</p>

<p><i>[
2017-10-16 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 30.11.14.39 <a href="https://wg21.link/fs.op.weakly_canonical">[fs.op.weakly_canonical]</a> as indicated:</p>

<blockquote>
<pre>
path weakly_canonical(const path&amp; p);
path weakly_canonical(const path&amp; p, error_code&amp; ec);
</pre>
<blockquote>
<p>
-1- <i>Returns:</i> [&hellip;]
<p/>
-2- <i>Effects:</i> Using <tt>status(p)</tt> or <tt>status(p, ec)</tt>, respectively, to determine existence, return a path
composed by <tt>operator/=</tt> from the result of calling <tt>canonical()</tt> <del>without a <tt>base</tt> argument and</del> 
with a path argument composed of the leading elements of <tt>p</tt> that exist, if any, followed by the elements of <tt>p</tt>
that do not exist, if any. For the first form, <tt>canonical()</tt> is called without an <tt>error_code</tt> argument.
For the second form, <tt>canonical()</tt> is called with ec as an <tt>error_code</tt> argument, and <tt>path()</tt> is returned
at the first error occurrence, if any.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3030" href="#3030">3030</a><sup><a href="https://cplusplus.github.io/LWG/issue3030">(i)</a></sup>. Who shall meet the requirements of <tt>try_lock</tt>?</h3>
<p><b>Section:</b> 33.4.5 <a href="https://wg21.link/thread.lock.algorithm">[thread.lock.algorithm]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2017-11-07 <b>Last modified:</b> 2017-11-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.lock.algorithm">issues</a> in [thread.lock.algorithm].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
33.4.5 <a href="https://wg21.link/thread.lock.algorithm">[thread.lock.algorithm]</a> says:
</p>
<blockquote><p>
"If a call to <tt>try_lock()</tt> fails, <tt>unlock()</tt> shall be called for all prior
arguments and there shall be no further calls to <tt>try_lock()</tt>."
</p></blockquote>
<p>
We try to use "shall" for requirements on the user (e.g. as in the
previous paragraph) which is absolutely not what is meant here.
</p>

<p><i>[2017-11 Albuquerque Wednesday night issues processing]</i></p>

<p>Moved to Ready</p>


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

<ol>
<li><p>Change 33.4.5 <a href="https://wg21.link/thread.lock.algorithm">[thread.lock.algorithm]</a> as indicated:</p>

<blockquote>
<pre>
template &lt;class L1, class L2, class... L3&gt; int try_lock(L1&amp;, L2&amp;, L3&amp;...);
</pre>
<blockquote>
<p>
-1- <i>Requires:</i> [&hellip;]
<p/>
-2- <i>Effects:</i> Calls <tt>try_lock()</tt> for each argument in order beginning with the first until all arguments have
been processed or a call to <tt>try_lock()</tt> fails, either by returning <tt>false</tt> or by throwing an exception.
If a call to <tt>try_lock()</tt> fails, <tt>unlock()</tt> <del>shall be</del><ins>is</ins> called for all prior arguments 
<del>and there shall be</del><ins>with</ins> no further calls to <tt>try_lock()</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template &lt;class L1, class L2, class... L3&gt; void lock(L1&amp;, L2&amp;, L3&amp;...);
</pre>
<blockquote>
<p>
-4- <i>Requires:</i> [&hellip;]
<p/>
-5- <i>Effects:</i> All arguments are locked via a sequence of calls to <tt>lock()</tt>, <tt>try_lock()</tt>, 
or <tt>unlock()</tt> on each argument. The sequence of calls <del>shall</del><ins>does</ins> not result in deadlock, 
but is otherwise unspecified. [<i>Note:</i> A deadlock avoidance algorithm such as try-and-back-off must be used, but the 
specific algorithm is not specified to avoid over-constraining implementations. &mdash; <i>end note</i>] If a 
call to <tt>lock()</tt> or <tt>try_lock()</tt> throws an exception, <tt>unlock()</tt> <del>shall be</del><ins>is</ins> 
called for any argument that had been locked by a call to <tt>lock()</tt> or <tt>try_lock()</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3034" href="#3034">3034</a><sup><a href="https://cplusplus.github.io/LWG/issue3034">(i)</a></sup>. P0767R1 breaks previously-standard-layout 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">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2017-11-12 <b>Last modified:</b> 2017-11-22</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://wg21.link/p0767r1">P0767R1 "Expunge POD"</a> changed the
requirement for several library types from "POD" to "trivial." Since these types
no longer provide/require the standard-layout portion of "POD," the change breaks:
<ul>
<li>user classes with a member of such a type that were standard-layout in C++17</li>
<li>implementations of <tt>basic_string</tt> and <tt>basic_string_view</tt> that
expect character types to be both trivial and standard layout.</li>
</ul>
It appears this breakage was not intentional and not discussed in LWG.
</p>
<p>
The fix is straight-forward: apply an additional standard-layout requirement to
the affected types:
<ul>
<li><tt>max_align_t</tt></li>
<li>the <tt>type</tt> member of specializations of <tt>aligned_storage</tt></li>
<li>the <tt>type</tt> member of specializations of <tt>aligned_union</tt></li>
<li>the char-like objects used by <tt>basic_string</tt> and <tt>basic_string_view</tt>.</li>
</ul>
(Albeit the potential for breakage with <tt>max_align_t</tt> is admittedly small.)
</p>

<p><i>[
2017-11-14 Moved to Tentatively Ready after 8 positive votes for P0 on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://wg21.link/n4700">N4700</a> +
<a href="http://wg21.link/p0767r1">P0767R1</a>.
</p>
<ol>
<li><p>Change in 21.2.4 <a href="https://wg21.link/support.types.layout">[support.types.layout]</a> paragraph 5:</p>
<p>
The type <tt>max_align_t</tt> is a trivial <ins>standard-layout</ins> type whose
alignment requirement is at least as great as that of every scalar type, and whose
alignment requirement is supported in every context (6.6.5 <a href="https://wg21.link/basic.align">[basic.align]</a>).
</p>
</li>
<li><p>Change the table in 23.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a> as indicated:</p>
<p>
<tt>aligned_storage</tt><br/>
The member typedef <tt>type</tt> shall be a trivial <ins>standard-layout</ins>
type suitable for use as uninitialized storage for any object whose size is at
most <tt>Len</tt> and whose alignment is a divisor of <tt>Align</tt>.
</p>
<p>
<tt>aligned_union</tt><br/>
The member typedef <tt>type</tt> shall be a trivial <ins>standard-layout</ins>
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>.
</p>
</li>
<li><p>Change 24.1 <a href="https://wg21.link/strings.general">[strings.general]</a> paragraph 1 as indicated:</p>
<p>
This Clause describes components for manipulating sequences of any non-array
trivial <ins>standard-layout</ins> (6.7 <a href="https://wg21.link/basic.types">[basic.types]</a>) type. Such types
are called char-like types, and objects of char-like types are called char-like
objects or simply characters.
</p>
</li>
</ol>





<hr>
<h3><a name="3035" href="#3035">3035</a><sup><a href="https://cplusplus.github.io/LWG/issue3035">(i)</a></sup>. <tt>std::allocator</tt>'s constructors should be <tt>constexpr</tt></h3>
<p><b>Section:</b> 23.10.10 <a href="https://wg21.link/default.allocator">[default.allocator]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2017-11-11 <b>Last modified:</b> 2018-01-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#default.allocator">issues</a> in [default.allocator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::allocator</tt>'s constructors should be <tt>constexpr</tt>. It's expected to be an empty class as far as I know, 
so this should impose no implementation burden, and it would be useful to permit guaranteed static initialization of 
objects that need to hold a <tt>std::allocator</tt>, but don't have to actually use it until after construction.
</p>

<p><i>[
2017-11-25 Moved to Tentatively Ready after 7 positive votes for P0 on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://wg21.link/n4700">N4700</a>.
</p>
<ol>
<li><p>Change in 23.10.10 <a href="https://wg21.link/default.allocator">[default.allocator]</a> as indicated:</p>
<blockquote>
<pre>
namespace std {
  template &lt;class T&gt; class allocator {
  public:
    using value_type = T;
    using propagate_on_container_move_assignment = true_type;
    using is_always_equal = true_type;
    <ins>constexpr</ins> allocator() noexcept;
    <ins>constexpr</ins> allocator(const allocator&amp;) noexcept;
    <ins>constexpr</ins> template &lt;class U&gt; allocator(const allocator&lt;U&gt;&amp;) noexcept;
    ~allocator();
    T* allocate(size_t n);
    void deallocate(T* p, size_t n);
  };
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3039" href="#3039">3039</a><sup><a href="https://cplusplus.github.io/LWG/issue3039">(i)</a></sup>. Unnecessary <tt>decay</tt> in <tt>thread</tt> and <tt>packaged_task</tt></h3>
<p><b>Section:</b> 33.3.2.2 <a href="https://wg21.link/thread.thread.constr">[thread.thread.constr]</a>, 33.6.10.1 <a href="https://wg21.link/futures.task.members">[futures.task.members]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej  <b>Opened:</b> 2017-11-17 <b>Last modified:</b> 2018-01-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</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>
Following <a href="http://wg21.link/p0777r1">P0777R1</a> "Treating Unnecessary decay", more occurrences can be fixed. 
When constraints are checking for the same type as <tt>thread</tt> or a specialization of <tt>packaged_task</tt>, 
decaying functions to function pointers and arrays to object pointers can't affect the result.
</p>

<p><i>[28-Nov-2017 Moved to Tentatively Ready after five positive votes on the ML.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Wording relative to <a href="http://wg21.link/n4700">N4700</a>.
</p>

<ol>
<li>
<p>
Edit 33.3.2.2 <a href="https://wg21.link/thread.thread.constr">[thread.thread.constr]</a> as indicated:
</p>
<blockquote>
<pre>
template &lt;class F, class... Args&gt; explicit thread(F&amp;&amp; f, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-3- <i>Requires:</i> [&hellip;]
<p/>
-4- <i>Remarks:</i> This constructor shall not participate in overload resolution if 
<tt><del>decay_t</del><ins>remove_cvref_t</ins>&lt;F&gt;</tt> is the same type as <tt>std::thread</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Edit 33.6.10.1 <a href="https://wg21.link/futures.task.members">[futures.task.members]</a> 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/>
-3- <i>Remarks:</i> This constructor shall not participate in overload resolution if 
<tt><del>decay_t</del><ins>remove_cvref_t</ins>&lt;F&gt;</tt> is the same type as <tt>packaged_task&lt;R(ArgTypes...)&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3041" href="#3041">3041</a><sup><a href="https://cplusplus.github.io/LWG/issue3041">(i)</a></sup>. Unnecessary <tt>decay</tt> in <tt>reference_wrapper</tt></h3>
<p><b>Section:</b> 23.14.5.1 <a href="https://wg21.link/refwrap.const">[refwrap.const]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Agust&iacute;n K-ballo Berg&eacute; <b>Opened:</b> 2017-12-04 <b>Last modified:</b> 2018-01-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Another occurrence of unnecessary decay (<a href="http://wg21.link/p0777">P0777</a>) was introduced by the
resolution of LWG <a href="lwg-defects.html#2993">2993</a>. A decayed function/array type will never be the same type as 
<tt>reference_wrapper</tt>.
</p>

<p><i>[
2018-01-09 Moved to Tentatively Ready after 9 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/n4713">N4713</a>.</p>

<ol>
<li><p>Change 23.14.5.1 <a href="https://wg21.link/refwrap.const">[refwrap.const]</a> as indicated:</p>

<blockquote>
<pre>template&lt;class U&gt;
reference_wrapper(U&amp;&amp; u) noexcept(<i>see below</i>);</pre>
<blockquote>
<p>
-1- <i>Remarks:</i> Let <tt><i>FUN</i></tt> denote the exposition-only functions
</p>
<pre>
void FUN(T&amp;) noexcept;
void FUN(T&amp;&amp;) = delete;
</pre>
<p>
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;<del>decay_t</del><ins>remove_cvref_t</ins>&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>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3042" href="#3042">3042</a><sup><a href="https://cplusplus.github.io/LWG/issue3042">(i)</a></sup>. <tt>is_literal_type_v</tt> should be inline</h3>
<p><b>Section:</b> D.13 <a href="https://wg21.link/depr.meta.types">[depr.meta.types]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-12-06 <b>Last modified:</b> 2018-01-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#depr.meta.types">issues</a> in [depr.meta.types].</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>
<a href="https://wg21.link/P0607R0">P0607R0</a> forgot to look at D.13 <a href="https://wg21.link/depr.meta.types">[depr.meta.types]</a> and make <tt>is_literal_type_v</tt> inline.
</p>

<p><i>[
2018-01-08 Moved to Tentatively Ready after 8 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/n4713">N4713</a>.</p>

<ol>
<li><p>Change D.13 <a href="https://wg21.link/depr.meta.types">[depr.meta.types]</a>p1 as indicated:</p>
<p>
-1- 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; <ins>inline</ins> constexpr bool is_literal_type_v = is_literal_type&lt;T&gt;::value;

  template&lt;class&gt; struct result_of;    // not defined
  template&lt;class Fn, class... ArgTypes&gt; struct result_of&lt;Fn(ArgTypes...)&gt;;
  template&lt;class T&gt; using result_of_t = typename result_of&lt;T&gt;::type;

  template&lt;class T&gt; struct is_pod;
  template&lt;class T&gt; inline constexpr bool is_pod_v = is_pod&lt;T&gt;::value;
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3043" href="#3043">3043</a><sup><a href="https://cplusplus.github.io/LWG/issue3043">(i)</a></sup>. Bogus postcondition for <tt>filesystem_error</tt> constructor</h3>
<p><b>Section:</b> 30.11.8.1 <a href="https://wg21.link/fs.filesystem_error.members">[fs.filesystem_error.members]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-12-06 <b>Last modified:</b> 2018-01-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.filesystem_error.members">issues</a> in [fs.filesystem_error.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.11.8.1 <a href="https://wg21.link/fs.filesystem_error.members">[fs.filesystem_error.members]</a> says that constructors of
<tt>filesystem_error</tt> have the postcondition that <tt>runtime_error::what()</tt> has the
value <tt>what_arg.c_str()</tt>. That's obviously incorrect: these are pointers
to distinct copies of the string in any sane implementation and cannot
possibly compare equal.
<p/>
The requirement seems suspect for a further reason: it mandates the content of the string
returned by <tt>runtime_error::what()</tt>, but <tt>filesystem_error</tt>
has no direct control over the construction of its indirect
non-virtual base class <tt>runtime_error</tt>. Instead, what is passed to <tt>runtime_error</tt>'s
constructor is determined by <tt>system_error</tt>'s constructor, which in many implementations
is an eagerly crafted error string. This is permitted by the specification of
<tt>system_error</tt> (see 22.5.7 <a href="https://wg21.link/syserr.syserr">[syserr.syserr]</a>) but would make the requirement unimplementable.
<p/>
The proposed wording below adjusts the postcondition using the formula of <tt>system_error</tt>'s 
constructor. As an editorial change, it also replaces the postcondition tables with normal postcondition clauses,
in the spirit of <a href="https://github.com/cplusplus/draft/issues/1875">editorial issue 1875</a>.
</p>

<p><i>[
2018-01-12 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/n4713">N4713</a>.</p>

<ol>
<li><p>Replace 30.11.8.1 <a href="https://wg21.link/fs.filesystem_error.members">[fs.filesystem_error.members]</a> p2-4, including Tables 119 through 121, with the following:</p>
<pre>
filesystem_error(const string&amp; what_arg, error_code ec);
</pre>
<blockquote>
-2- <i>Postconditions</i>: <tt>code() == ec</tt>, <tt>path1().empty() == true</tt>, <tt>path2().empty() == true</tt>,
and <tt>string_view(what()).find(what_arg) != string_view::npos</tt>.
</blockquote>
<pre>
filesystem_error(const string&amp; what_arg, const path&amp; p1, error_code ec);
</pre>
<blockquote>
-3- <i>Postconditions</i>: <tt>code() == ec</tt>, <tt>path1()</tt> returns a reference to the stored copy of <tt>p1</tt>, <tt>path2().empty() == true</tt>,
and <tt>string_view(what()).find(what_arg) != string_view::npos</tt>.
</blockquote>
<pre>
filesystem_error(const string&amp; what_arg, const path&amp; p1, const path&amp; p2, error_code ec);
</pre>
<blockquote>
-4- <i>Postconditions</i>: <tt>code() == ec</tt>, <tt>path1()</tt> returns a reference to the stored copy of <tt>p1</tt>,
<tt>path2()</tt> returns a reference to the stored copy of <tt>p2</tt>, and <tt>string_view(what()).find(what_arg) != string_view::npos</tt>.
</blockquote>
</li>
<li><p>Edit 30.11.8.1 <a href="https://wg21.link/fs.filesystem_error.members">[fs.filesystem_error.members]</a> p7 as indicated:</p>
<pre>
const char* what() const noexcept override;
</pre>
<blockquote>
-7- <i>Returns</i>: <del>A string containing <tt>runtime_error::what()</tt>.</del><ins>An <span style="font-variant:small-caps">ntbs</span> that
incorporates the <tt>what_arg</tt> argument supplied to the constructor.</ins> The exact format is unspecified. Implementations should include
the <tt>system_error::what()</tt> string and the pathnames of <tt>path1</tt> and <tt>path2</tt> in the native format in the returned string.
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3045" href="#3045">3045</a><sup><a href="https://cplusplus.github.io/LWG/issue3045">(i)</a></sup>. <tt>atomic&lt;<i>floating-point</i>&gt;</tt> doesn't have <tt>value_type</tt> or <tt>difference_type</tt></h3>
<p><b>Section:</b> 32.6.3 <a href="https://wg21.link/atomics.types.float">[atomics.types.float]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-12-11 <b>Last modified:</b> 2018-01-22</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 <tt>atomic&lt;<i>floating-point</i>&gt;</tt> specialization doesn't have the <tt>value_type</tt> and <tt>difference_type</tt> member typedefs, making it
unusable with most of the nonmember function templates. This doesn't seem to be the intent.
</p>

<p><i>[
2018-01-09 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="http://wg21.link/n4713">N4713</a>.</p>

<ol>
<li><p>Edit 32.6.3 <a href="https://wg21.link/atomics.types.float">[atomics.types.float]</a> after p1, class template specialization <tt>atomic&lt;<i>floating-point</i>&gt;</tt> synopsis, as indicated:</p>
<pre>
  namespace std {
    template&lt;&gt; struct atomic&lt;<i>floating-point</i>&gt; {
<ins>      using value_type = <i>floating-point</i>;
      using difference_type = value_type;</ins>
      static constexpr bool is_always_lock_free = <i>implementation-defined</i>;
      [&hellip;]
    };
  }
</pre>
</li>
</ol>





<hr>
<h3><a name="3048" href="#3048">3048</a><sup><a href="https://cplusplus.github.io/LWG/issue3048">(i)</a></sup>. <tt>transform_reduce(exec, first1, last1, first2, init)</tt> discards execution policy</h3>
<p><b>Section:</b> 29.8.5 <a href="https://wg21.link/transform.reduce">[transform.reduce]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy Robert O'Neal III <b>Opened:</b> 2017-12-15 <b>Last modified:</b> 2018-01-22</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>
Since there exists only one common <i>Effects</i> element for both the parallel and the non-parallel form of
<tt>transform_reduce</tt> without explicit operation parameters, the current specification of a function call 
<tt>std::transform_reduce(exec, first1, last1, first2, init)</tt> has the same effect as if the 
<tt>ExecutionPolicy</tt> would have been ignored. Presumably this effect is unintended.
</p>

<p><i>[
2018-01-15 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/n4713">N4713</a>.</p>

<ol>
<li><p>Modify 29.8.5 <a href="https://wg21.link/transform.reduce">[transform.reduce]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class InputIterator1, class InputIterator2, class T&gt;
  T transform_reduce(InputIterator1 first1, InputIterator1 last1,
                     InputIterator2 first2,
                     T init);
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> Equivalent to:</ins> 
</p>
<blockquote><pre>
<ins>return transform_reduce(first1, last1, first2, init, plus&lt;&gt;(), multiplies&lt;&gt;());</ins>
</pre></blockquote>
</blockquote>
<pre>
template&lt;class ExecutionPolicy,
         class ForwardIterator1, class ForwardIterator2, class T&gt;
  T transform_reduce(ExecutionPolicy&amp;&amp; exec,
                     ForwardIterator1 first1, ForwardIterator1 last1,
                     ForwardIterator2 first2,
                     T init);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to: 
</p>
<blockquote><pre>
return transform_reduce(<ins>std::forward&lt;ExecutionPolicy&gt;(exec),</ins> first1, last1, first2, init, plus&lt;&gt;(), 
multiplies&lt;&gt;());
</pre></blockquote>
</blockquote>
</blockquote>

</li>
</ol>




<hr>
<h3><a name="3051" href="#3051">3051</a><sup><a href="https://cplusplus.github.io/LWG/issue3051">(i)</a></sup>. Floating point classifications were inadvertently changed in P0175</h3>
<p><b>Section:</b> 29.9.1 <a href="https://wg21.link/cmath.syn">[cmath.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas K&ouml;ppe <b>Opened:</b> 2018-01-23 <b>Last modified:</b> 2018-01-31</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#cmath.syn">active issues</a> in [cmath.syn].</p>
<p><b>View all other</b> <a href="lwg-index.html#cmath.syn">issues</a> in [cmath.syn].</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 paper <a href="http://wg21.link/p0175">P0175</a> was meant to be a purely editorial change to 
spell out the synopses of the "C library" headers. However it contained the following inadvertent 
normative change: The floating point classification functions <tt>isinf</tt>, <tt>isfinite</tt>, 
<tt>signbit</tt>, etc. (but not <tt>fpclassify</tt>) used to be specified to return "<tt>bool</tt>" 
in C++14. In C, those are macros, but in C++ they have always been functions. During the preparation 
of P0175, I recreated the function signatures copying the return type "<tt>int</tt>" from C, but 
failed to notice that we had already specified those functions differently, so the return type was 
changed to "<tt>int</tt>".
<p/>
To restore the intended specification, we should change the return types of all the <tt>is...</tt> 
and <tt>signbit</tt> classification functions back to <tt>bool</tt>. Alternatively, we could decide 
that the return type should actually be <tt>int</tt>, but that would be a larger discussion.
<p/>
Proposed resolution for restoring the original wording: Replace return type "<tt>int</tt>" with 
return type "<tt>bool</tt>" and for all the classification/comparison functions after 
"<i>// classification/comparison functions</i>" in [cmath.syn] <em>except</em> the <tt>fpclassify</tt> 
functions.
<p/>
Related previous issue was LWG <a href="lwg-defects.html#1327">1327</a> and the corresponding 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3141.pdf#page=188">NB comment US-136</a> 
resolution.
</p>

<p><i>[
2018-01-29 Moved to Tentatively Ready after 8 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/n4713">N4713</a>.</p>

<ol>
<li><p>Modify 29.9.1 <a href="https://wg21.link/cmath.syn">[cmath.syn]</a> as indicated:</p>

<blockquote>
<pre>
[&hellip;]
namespace std {
  [&hellip;]
  <i>// 29.9.4 <a href="https://wg21.link/c.math.fpclass">[c.math.fpclass]</a>, classification / comparison functions</i>
  int fpclassify(float x);
  int fpclassify(double x);
  int fpclassify(long double x);
  <ins>bool</ins><del>int</del> isfinite(float x);
  <ins>bool</ins><del>int</del> isfinite(double x);
  <ins>bool</ins><del>int</del> isfinite(long double x);
  <ins>bool</ins><del>int</del> isinf(float x);
  <ins>bool</ins><del>int</del> isinf(double x);
  <ins>bool</ins><del>int</del> isinf(long double x);
  <ins>bool</ins><del>int</del> isnan(float x);
  <ins>bool</ins><del>int</del> isnan(double x);
  <ins>bool</ins><del>int</del> isnan(long double x);
  <ins>bool</ins><del>int</del> isnormal(float x);
  <ins>bool</ins><del>int</del> isnormal(double x);
  <ins>bool</ins><del>int</del> isnormal(long double x);
  <ins>bool</ins><del>int</del> signbit(float x);
  <ins>bool</ins><del>int</del> signbit(double x);
  <ins>bool</ins><del>int</del> signbit(long double x);
  <ins>bool</ins><del>int</del> isgreater(float x, float y);
  <ins>bool</ins><del>int</del> isgreater(double x, double y);
  <ins>bool</ins><del>int</del> isgreater(long double x, long double y);
  <ins>bool</ins><del>int</del> isgreaterequal(float x, float y);
  <ins>bool</ins><del>int</del> isgreaterequal(double x, double y);
  <ins>bool</ins><del>int</del> isgreaterequal(long double x, long double y);
  <ins>bool</ins><del>int</del> isless(float x, float y);
  <ins>bool</ins><del>int</del> isless(double x, double y);
  <ins>bool</ins><del>int</del> isless(long double x, long double y);
  <ins>bool</ins><del>int</del> islessequal(float x, float y);
  <ins>bool</ins><del>int</del> islessequal(double x, double y);
  <ins>bool</ins><del>int</del> islessequal(long double x, long double y);
  <ins>bool</ins><del>int</del> islessgreater(float x, float y);
  <ins>bool</ins><del>int</del> islessgreater(double x, double y);
  <ins>bool</ins><del>int</del> islessgreater(long double x, long double y);
  <ins>bool</ins><del>int</del> isunordered(float x, float y);
  <ins>bool</ins><del>int</del> isunordered(double x, double y);
  <ins>bool</ins><del>int</del> isunordered(long double x, long double y);
  [&hellip;]
}
</pre>
</blockquote>
</li>
</ol>




</body>
</html>
