<!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 Toronto</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 Toronto</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P0698R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2017-06-19 at 02:20:00 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="2444" href="#2444">2444.</a> Inconsistent complexity for <tt>std::sort_heap</tt></h3>
<p><b>Section:</b> 25.7.7.4 [sort.heap] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Fran&ccedil;ois Dumont <b>Opened:</b> 2014-10-07 <b>Last modified:</b> 2017-05-31</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>
While creating complexity tests for the GNU libstdc++ implementation <a href="https://gcc.gnu.org/ml/libstdc++/2014-10/msg00048.html">I
stumbled</a> across a surprising requirement for the <tt>std::sort_heap</tt> algorithm.
<p/>
In 25.7.7.4 [sort.heap] p3 the Standard states:
</p>
<blockquote><p>
<i>Complexity</i>: At most <tt><i>N</i> log(<i>N</i>)</tt> comparisons (where <tt><i>N</i> == last - first</tt>).
</p></blockquote>
<p>
As stated on the libstdc++ mailing list by Marc Glisse <tt>sort_heap</tt> can be implemented by <tt><i>N</i></tt> calls to
<tt>pop_heap</tt>. As max number of comparisons of <tt>pop_heap</tt> is <tt>2 * log(<i>N</i>)</tt> then <tt>sort_heap</tt>
max limit should be <tt>2 * log(1) + 2 * log(2) + .... + 2 * log(<i>N</i>)</tt> that is to say <tt>2 * log(<i>N</i>!)</tt>.
In terms of <tt>log(<i>N</i>)</tt> we can also consider that this limit is also cap by <tt>2 * <i>N</i> * log(<i>N</i>)</tt>
which is surely what the Standard wanted to set as a limit.
<p/>
This is why I would like to propose to replace paragraph 3 by:
</p>
<blockquote><p>
<i>Complexity</i>: At most <tt><ins>2</ins><i>N</i> log(<i>N</i>)</tt> comparisons (where <tt><i>N</i> == last - first</tt>).
</p></blockquote>

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

<p>
Marshall will research the maths and report back in Lenexa.
</p>

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

<p>STL: I dislike exact complexity requirements, they prevent one or two extra checks in debug mode. Would it be better to say O(N log(N)) not at most?</p>

<p><i>[2017-03-04, Kona]</i></p>

<p>Move to Tentatively Ready. STL may write a paper (with Thomas &amp; Robert) offering guidance about Big-O notation vs. exact requirements.</p>


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

<ol><li>
<p>
In 25.7.7.4 [sort.heap] p3 the Standard states:
</p>
<blockquote>
<pre>
template&lt;class RandomAccessIterator&gt;
  void sort_heap(RandomAccessIterator first, RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void sort_heap(RandomAccessIterator first, RandomAccessIterator last,
                 Compare comp);
</pre>
<blockquote><p>
[&hellip;]
<p/>
-3- <i>Complexity</i>: At most <tt><ins>2</ins><i>N</i> log(<i>N</i>)</tt> comparisons (where <tt><i>N</i> == last - first</tt>).
</p></blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2593" href="#2593">2593.</a> Moved-from state of Allocators</h3>
<p><b>Section:</b> 17.5.3.5 [allocator.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> David Krauss <b>Opened:</b> 2016-02-19 <b>Last modified:</b> 2017-06-15</p>
<p><b>Priority: </b>4
</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
17.5.3.5 [allocator.requirements] suggests that the moved-from state of an allocator may be unequal to its
previous state. Such a move constructor would break most container implementations, which move-construct the
embedded allocator along with a compressed pair. Even if a moved-from container is empty, it should still
subsequently allocate from the same resource pool as it did before.
</p>
<blockquote><pre>
std::vector&lt;int, pool&gt; a(500, my_pool);
auto b = std::move(a); // b uses my_pool too.
a.resize(500); // should still use my_pool.
</pre></blockquote>

<p><i>[2016-02, Jacksonville]</i></p>

<p>Marshall will see if this can be resolved editorially.</p>

<p>
After discussion, the editors and I decided that this could not be handled editorially.
The bit about a moved-from state of an allocator being the same as the original state is a
normative change. I submitted a <a href="https://github.com/cplusplus/draft/pull/727">pull request</a>
to handle the mismatched variables in the table.
</p>

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

<ol>
<li><p>Change 17.5.3.5 [allocator.requirements], Table 28 &mdash; "Allocator requirements" as indicated:
<blockquote class="note">
<p>
Note there's an editorial error in Table 28 in that line and the surrounding ones. The left column was apparently
updated to use <tt>u</tt> and the right column is still using <tt>a</tt>/<tt>a1</tt>/<tt>b</tt>.
</p>
</blockquote>
</p>

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

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

<tr>
<td>
<tt>X u(move(a));<br/>
X u = move(a);</tt>
</td>
<td></td>
<td>
Shall not exit via an exception.
post: <ins><tt>u</tt> is equal to <tt>a</tt> and equal to the prior value of <tt>a</tt></ins><del><tt>a1</tt>
equals the prior value of <tt>a</tt></del>.
</td>
<td>
</td>
</tr>

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

</table>
</blockquote>

</li>
</ol>

</blockquote>

<p><i>[2016-06-20, Oulu, Daniel comments]</i></p>

<p>
According to the current working draft, the situation has changed due to changes performed by the project editor, the revised
resolution has been adjusted to N4594.
</p>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs AM: Moved to LEWG, as this decision (should allocators only be copyable, not movable) is design.</p>

<p><i>[2017-02 in Kona, LEWG responds]</i></p>

<p>Alisdair Meredith says that if you have a do-not-propagate-on-move-assignment,
then the move of the allocator must compare equal to the original.</p>
<p>Have a data structure where all allocators are equal.
Construct an element somewhere else moving from inside the container
(which doesn't have a POCMA trait); you don't want the allocator of the
moved-from element to now be different. So in that case, the allocator's
move constructor must behave the same as copy.</p>
<p>We don't need to go as far as this issue, but going that far is ok for Bloomberg.</p>

<p><i>[2017-06-02 Issues Telecon]</i></p>

<p>We discussed containers that have sentinel nodes, etc, and so might have to
allocate/deallocate using a moved-from allocator - and decided that we didn't
want any part of that</p>
<p>Adjusted the wording slightly, and moved to Tentatively Ready</p>

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

<ol>
<li><p>Change 17.5.3.5 [allocator.requirements], Table 28 &mdash; "Allocator requirements" as indicated:</p>

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

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

<tr>
<td>
<tt>X u(std::move(a));<br/>
X u = std::move(a);</tt>
</td>
<td></td>
<td>
Shall not exit via an exception.
post: <ins><tt>u</tt> is equal to <tt>a</tt> and equal to the prior value of <tt>a</tt></ins><del><tt>u</tt> is equal to the prior
value of <tt>a</tt>.</del>.
</td>
<td>
</td>
</tr>

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

</table>
</blockquote>

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



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

<ol>
<li><p>Change 17.5.3.5 [allocator.requirements], Table 28 &mdash; "Allocator requirements" as indicated:</p>

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

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

<tr>
<td>
<tt>X u(std::move(a));<br/>
X u = std::move(a);</tt>
</td>
<td></td>
<td>
Shall not exit via an exception.
post: <ins>The value of <tt>a</tt> is unchanged and is equal to <tt>u</tt></ins><del><tt>u</tt> is equal to the prior value of <tt>a</tt></del>.
</td>
<td>
</td>
</tr>

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

</table>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="2597" href="#2597">2597.</a> <tt>std::log</tt> misspecified for complex numbers</h3>
<p><b>Section:</b> 26.5.8 [complex.transcendentals] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas Koeppe <b>Opened:</b> 2016-03-01 <b>Last modified:</b> 2017-03-13</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#complex.transcendentals">issues</a> in [complex.transcendentals].</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 current specification of <tt>std::log</tt> is inconsistent for complex numbers, specifically, the Returns clause
(26.5.8 [complex.transcendentals]). On the one hand, it states that the imaginary part of the return value lies
in the <em>closed</em> interval <tt>[-<i>i</i> &pi;, +<i>i</i> &pi;]</tt>. On the other hand, it says that "the branch
cuts are along the negative real axis" and "the imaginary part of <tt>log(x)</tt> is <tt>+&pi;</tt> when <tt>x</tt>
is a negative real number".
</p>
<p>
The inconsistency lies in the difference between the mathematical concept of a branch cut and the nature of floating
point numbers in C++. The corresponding specification in the C standard makes it clearer that if <tt>x</tt> is a real
number, then <tt>log(x + 0<i>i</i>) = +&pi;</tt>, but <tt>log(x - 0<i>i</i>) = -&pi;</tt>, i.e. they consider positive
and negative zero to represent the two different limits of approaching the branch cut from opposite directions. In
other words, the term "negative real number" is misleading, and in fact there are <em>two distinct</em> real numbers,
<tt>x + 0<i>i</i></tt> and <tt>x - 0<i>i</i></tt>, that compare equal but whose logarithms differ by <tt>2 &pi; <i>i</i></tt>.
</p>
<p>
The resolution should consist of two parts:
</p>
<ol>
<li><p>Double-check that our usage and definition of "branch cut" is sufficiently unambiguous. The C standard contains
a lot more wording around this that we don't have in C++.</p></li>
<li><p>Change the Returns clause of <tt>log</tt> appropriately. For example: "When <tt>x</tt> is a negative real number,
<tt>imag(log(x + 0<i>i</i>))</tt> is <tt>&pi;</tt>, and <tt>imag(log(x - 0<i>i</i>))</tt> is <tt>-&pi;</tt>."</p></li>
</ol>
<p>
Current implementations seem to behave as described in (2).
(<a href="http://melpon.org/wandbox/permlink/pwBDeGiY3HDtFAh8">Try-it-at-home link</a>)
</p>

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

<p>Move to Open - Thomas to provide wording</p>

<p><i>[2016-11-15, Thomas comments and provides wording]</i></p>

<p>
Following LWG discussion in Issaquah, I now propose to resolve this issue by removing the normative requirement on the
function limits, and instead adding a note that the intention is to match the behaviour of C. This allows implementations
to use the behaviour of C without having to specify what floating point numbers really are.
<p/>
The change applies to both <tt>std::log</tt> and <tt>std::sqrt</tt>.
<p/>
Updated try-at-home link, see <a href="http://melpon.org/wandbox/permlink/tVYVUNfeZ1yoFnp8">here</a>.
</p>

<p><i>[2017-03-04, Kona]</i></p>

<p>Minor wording update and status to Tentatively Ready.</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
This wording is relative to N4606.
</p>
<ol>
<li><p>Change the "returns" element for <tt>std::log</tt> (26.5.8 [complex.transcendentals] p17):</p>

<blockquote>
<pre>
template&lt;class T&gt; complex&lt;T&gt; log(const complex&lt;T&gt;&amp; x);
</pre>
<blockquote>
<p>
-16- <i>Remarks:</i> The branch cuts are along the negative real axis.
<p/>
-17- <i>Returns:</i> The complex natural (base-&#8495;) logarithm of <tt>x</tt>. For all <tt>x</tt>, <tt>imag(log(x))</tt>
lies in the interval <tt>[</tt>-&pi;, &pi;<tt>]</tt><del>, and when <tt>x</tt> is a negative real number, <tt>imag(log(x))</tt>
is &pi;</del>. <ins>[<i>Note:</i> The semantics of <tt>std::log</tt> are intended to be the same in C++ as they are for
<tt>clog</tt> in C. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change the "returns" element for <tt>std::sqrt</tt> (26.5.8 [complex.transcendentals] p25):</p>

<blockquote>
<pre>
template&lt;class T&gt; complex&lt;T&gt; sqrt(const complex&lt;T&gt;&amp; x);
</pre>
<blockquote>
<p>
-24- <i>Remarks:</i> The branch cuts are along the negative real axis.
<p/>
-25- <i>Returns:</i> The complex square root of <tt>x</tt>, in the range of the right half-plane. <del>If the argument is a
negative real number, the value returned lies on the positive imaginary axis.</del><ins>[<i>Note:</i> The semantics of
<tt>std::sqrt</tt> are intended to be the same in C++ as they are for <tt>csqrt</tt> in C. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4606.
</p>
<ol>
<li><p>Change the "returns" element for <tt>std::log</tt> (26.5.8 [complex.transcendentals] p17):</p>

<blockquote>
<pre>
template&lt;class T&gt; complex&lt;T&gt; log(const complex&lt;T&gt;&amp; x);
</pre>
<blockquote>
<p>
-16- <i>Remarks:</i> The branch cuts are along the negative real axis.
<p/>
-17- <i>Returns:</i> The complex natural (base-&#8495;) logarithm of <tt>x</tt>. For all <tt>x</tt>, <tt>imag(log(x))</tt>
lies in the interval <tt>[</tt>-&pi;, &pi;<tt>]</tt><del>, and when <tt>x</tt> is a negative real number, <tt>imag(log(x))</tt>
is &pi;</del>. <ins>[<i>Note:</i> the semantics of this function are intended to be the same in C++ as they are for
<tt>clog</tt> in C. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change the "returns" element for <tt>std::sqrt</tt> (26.5.8 [complex.transcendentals] p25):</p>

<blockquote>
<pre>
template&lt;class T&gt; complex&lt;T&gt; sqrt(const complex&lt;T&gt;&amp; x);
</pre>
<blockquote>
<p>
-24- <i>Remarks:</i> The branch cuts are along the negative real axis.
<p/>
-25- <i>Returns:</i> The complex square root of <tt>x</tt>, in the range of the right half-plane. <del>If the argument is a
negative real number, the value returned lies on the positive imaginary axis.</del><ins>[<i>Note:</i> The semantics of
this function are intended to be the same in C++ as they are for <tt>csqrt</tt> in C. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2783" href="#2783">2783.</a> <tt>stack::emplace()</tt> and <tt>queue::emplace()</tt> should return <tt>decltype(auto)</tt></h3>
<p><b>Section:</b> 23.6.4.1 [queue.defn], 23.6.6.1 [stack.defn] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-10-14 <b>Last modified:</b> 2017-03-13</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 <tt>stack</tt> and <tt>queue</tt> adaptors are now defined as:
</p>
<blockquote><pre>
template &lt;class... Args&gt;
reference emplace(Args&amp;&amp;... args) { return c.emplace_back(std::forward&lt;Args&gt;(args)...); }
</pre></blockquote>
<p>
This breaks any code using <tt>queue&lt;UserDefinedSequence&gt;</tt> or <tt>stack&lt;UserDefinedSequence&gt;</tt>
until the user-defined containers are updated to meet the new C++17 requirements.
<p/>
If we defined them as returning <tt>decltype(auto)</tt> then we don't break any code. When used with <tt>std::vector</tt>
or <tt>std::deque</tt> they will return <tt>reference</tt>, as required, but when used with C++14-conforming containers
they will return <tt>void</tt>, as before.
</p>

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

<p>Sat AM: P2</p>

<p><i>[2017-03-04, Kona]</i></p>

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


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

<ol>
<li><p>Change return type of <tt>emplace</tt> in class definition in 23.6.4.1 [queue.defn]:</p>

<blockquote>
<pre>
template &lt;class... Args&gt;
  <del>reference</del><ins>decltype(auto)</ins> emplace(Args&amp;&amp;... args) { return c.emplace_back(std::forward&lt;Args&gt;(args)...); }
</pre>
</blockquote>
</li>

<li><p>Change return type of <tt>emplace</tt> in class definition in 23.6.6.1 [stack.defn]:</p>

<blockquote>
<pre>
template &lt;class... Args&gt;
  <del>reference</del><ins>decltype(auto)</ins> emplace(Args&amp;&amp;... args) { return c.emplace_back(std::forward&lt;Args&gt;(args)...); }
</pre>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2932" href="#2932">2932.</a> Constraints on parallel algorithm implementations are underspecified</h3>
<p><b>Section:</b> 25.4.3 [algorithms.parallel.exec] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Dietmar K&uuml;hl <b>Opened:</b> 2017-02-05 <b>Last modified:</b> 2017-03-13</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#algorithms.parallel.exec">active issues</a> in [algorithms.parallel.exec].</p>
<p><b>View all other</b> <a href="lwg-index.html#algorithms.parallel.exec">issues</a> in [algorithms.parallel.exec].</p>
<p><b>Discussion:</b></p>
<p>
Section 25.4.3 [algorithms.parallel.exec] specifies constraints a user of the parallel algorithms has to obey. Notably,
it specifies in paragraph 3 that executions of element access functions are indeterminately sequenced with respect to each other. Correspondingly, it is the user's obligation to ensure that these calls do not introduce data races (this is also clarified in
a note on this section).
<p/>
Unfortunately, there is no constraint that, at least, mutating element access functions like <tt>operator++()</tt> on an
iterator are called on different objects. An odd implementation of a parallel algorithm could increment a shared iterator
from two threads without synchronisation of its own and the user would be obliged to make sure there is no data race!
<p/>
For example:
</p>
<blockquote><pre>
template &lt;typename FwdIt&gt;
FwdIt adjacent_find(std::execution::parallel_policy, FwdIt it, FwdIt end)
{
  if (2 &lt;= std::distance(it, end)) {
    FwdIt tmp(it);
    auto f1 = std::async([&amp;tmp](){ ++tmp; });
    auto f2 = std::async([&amp;tmp](){ ++tmp; });
    f1.get();
    f2.get();
  }
  return std::adjancent_find(it, end);
}
</pre></blockquote>
<p>
This code is, obviously, a contrived example but with the current specification a legal implementation of <tt>adjacent_find()</tt>.
The problem is that, e.g., for pointers there is a data race when incrementing <tt>tmp</tt>, i.e., the function can't be used
on pointers. I don't think any of the containers makes a guarantee that their iterators can be incremented without synchronisation,
i.e., the standard library doesn't have any iterators which could be used with this algorithm!
<p/>
Of course, no sane implementation would do anything like that. However, they are allowed to be implemented as above, making it unnecessarily hard and probably inefficient to use the algorithms: in portable code any user of the parallel algorithms needs
to deal with the possibility that mutating operations on the same object are called from different threads. There is a constraint
missing for the parallel algorithm implementations which limits calls to, at least, some element access functions to be applied
only to different objects if there is synchronisation done by the algorithm. At least, obviously mutating operations like the
iterator increment/decrement operators need to be correspondingly constrained.
<p/>
On the other hand, it seems reasonable that a shared data structure stores, e.g., a predicate used concurrently by all threads.
This use is quite reasonable and there is nothing wrong. That is, demanding that all element access functions are called on different objects between different threads would possibly adversely over-constraining the algorithms. Only the element access functions deliberately changing the object need to be constrained.
<p/>
Based on checking all algorithms in the standard library taking an <tt>ExecutionPolicy</tt> template parameter there are broadly
four groups of template parameters:
</p>
<ol>
<li><p>Parameters with a known set of possible arguments: <tt>ExecutionPolicy</tt> (execution policies listed in
20.19 [execpol]).</p></li>
<li><p>Parameters specifying types of objects which are expected not to change: <tt>BinaryOperation</tt>, <tt>BinaryPredicate</tt>,
<tt>Compare</tt>, <tt>Function</tt>, <tt>Predicate</tt>, <tt>UnaryFunction</tt>, <tt>UnaryOperation</tt>, and <tt>T</tt> (all but
the last one are function objects although I couldn't locate concepts for some of them &mdash; that may be a separate issue).</p></li>
<li><p>Parameters of mutable types which are also meant to be mutated: <tt>InputIterator</tt>, <tt>OutputIterator</tt>,
<tt>ForwardIterator</tt>, <tt>BidirectionalIterator</tt>, <tt>RandomAccessIterator</tt>, and <tt>Size</tt> (the concept for
<tt>Size</tt> also seems to be unspecified).</p></li>
<li><p>Some algorithms use <tt>Generator</tt> which seems to be a mutable function object. However, I couldn't locate a concept
for this parameter.</p></li>
</ol>
<p>
The problematic group is 3 and possibly 4: mutations on the objects are expected. It seem the general approach of disallowing
calling non-const functions without synchronisation applies. Note, however, that prohibiting calling of any non-const function
from the algorithms would put undue burden on the implementation of algorithms: any of the accessor functions may be non-const
although the concept assume that the function would be const. The constraint should, thus, only apply to functions which may
mutate the object according to their respective concept.
</p>
<p>
Suggested Resolution:
</p>
<p>
Add a statement prohibiting unsequenced calls to element access functions on the same object which are not applicable to
const objects according to the corresponding concept. I'm not sure how to best specify the constraint in general, though.
<p/>
Since the current algorithms use relatively few concepts there are fairly few operations actually affected. It may be
reasonable at least for the initial version (and until we could refer to constructs in concepts in the language) to
explicitly list the affected operations. I haven't done a full audit but iterator <tt>++</tt>, <tt>--</tt>, <tt>@=</tt> (for
<tt>@</tt> being any of the operators which can be combined with an assignment), and assignments on all objects may be
the set of affected element access functions whose use needs to be constrained.
<p/>
Here is a concrete proposal for the change: In 25.4.2 [algorithms.parallel.user] add a paragraph:
<p/>
Parallel algorithms are constrained when calling mutating element access functions without synchronisation: if any mutating
element access function is called on an object there shall be no other unsynchronised accesses to this object. The mutating
element access functions are those which are specified as mutating object in the concept, notably assignment on any object,
operators <tt>++</tt>, <tt>--</tt>, <tt>+=</tt>, and <tt>-=</tt> on any of the iterator or <tt>Size</tt> parameters, and
any <tt>@=</tt> operators on the <tt>Size</tt> parameters.
</p>

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

<ol>
<li><p>Modify 25.4.2 [algorithms.parallel.user] as indicated:</p>
<blockquote>
<p>
-1- Function objects passed into parallel algorithms as objects of type <tt>Predicate</tt>, <tt>BinaryPredicate</tt>,
<tt>Compare</tt>, and <tt>BinaryOperation</tt> shall not directly or indirectly modify objects via their arguments.
<p/>
<ins>-?- Parallel algorithms are constrained when calling mutating element access functions without synchronisation: If
any mutating element access function is called on an object there shall be no other unsynchronised accesses to this object.
The mutating element access functions are those which are specified as mutating object in the concept, notably assignment
on any object, operators <tt>++</tt>, <tt>--</tt>, <tt>+=</tt>, and <tt>-=</tt> on any of the iterator or <tt>Size</tt>
parameters, and any <tt>@=</tt> operators on the <tt>Size</tt> parameters.</ins>
</p>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2017-03-03, Kona]</i></p>

<p>
Dietmar provides improved wording. Issues with the PR before the change:
</p>
<ul>
<li><p>The part before the colon is redundant: we don't need to state that.</p></li>
<li><p>Replace "notably" with "specifically"</p></li>
<li><p><tt>swap()</tt> needs to be in the list.</p></li>
<li><p>Not sure what "called on an object means"</p></li>
<li><p>The assignment side is overconstrained: the right hand side is allowed.</p></li>
</ul>

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

<ol>
<li><p>Modify 25.4.2 [algorithms.parallel.user] as indicated:</p>
<blockquote>
<p>
-1- Function objects passed into parallel algorithms as objects of type <tt>Predicate</tt>, <tt>BinaryPredicate</tt>,
<tt>Compare</tt>, and <tt>BinaryOperation</tt> shall not directly or indirectly modify objects via their arguments.
<p/>
<ins>-?- If an object is mutated by an element access function the algorithm will perform no other unsynchronized
accesses to that object. The mutating element access functions are those which are specified as mutating the object
in the relevant concept, such as <tt>swap()</tt>, <tt>++</tt>, <tt>--</tt>, <tt>@=</tt>, and assignments. For the assignment
and <tt>@=</tt> operators only the left argument is mutated.</ins>
</p>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2017-03-03, Kona]</i></p>

<p>Dietmar finetunes wording after review by SG1.</p>

<p><i>[2017-03-03, Kona]</i></p>

<p>Move to Ready</p>


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

<ol>
<li><p>Add a new paragraph following 25.4.3 [algorithms.parallel.exec] p1 as indicated:</p>
<blockquote>
<p>
-1- Parallel algorithms have template parameters named <tt>ExecutionPolicy</tt> (20.19) which describe the manner in
which the execution of these algorithms may be parallelized and the manner in which they apply the element
access functions.
<p/>
<ins>-?- If an object is modified by an element access function the algorithm will perform no other unsynchronized accesses
to that object. The modifying element access functions are those which are specified as modifying the object in the relevant
concept [<i>Note:</i> For example, <tt>swap()</tt>, <tt>++</tt>, <tt>--</tt>, <tt>@=</tt>, and assignments modify the object.
For the assignment and <tt>@=</tt> operators only the left argument is modified. &mdash; <i>end note</i>].</ins>
<p/>
-2- [&hellip;]
</p>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="2937" href="#2937">2937.</a> Is <tt>equivalent("existing_thing", "not_existing_thing")</tt> an error?</h3>
<p><b>Section:</b> 27.10.15.12 [fs.op.equivalent] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy Robert O'Neal III <b>Opened:</b> 2017-02-27 <b>Last modified:</b> 2017-03-13</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.op.equivalent">issues</a> in [fs.op.equivalent].</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>
See discussion on the LWG mailing list with subject "Is equivalent("existing_thing", "not_existing_thing") an error?", abreviated below:
<p/>
Billy O'Neal:
</p>
<blockquote>
<p>
The existing "an error is reported" effects say that an error is reported for <tt>!exists(p1) &amp;&amp; !exists(p2)</tt>, but
I'm not sure that treating <tt>equivalent("existing_thing", "not_existing_thing")</tt> as "<tt>false</tt>, no error" makes any more
sense than for <tt>equivalent("not_existing_thing", "not_existing_thing")</tt>.
<p/>
It's also unfortunate that the current spec requires reporting an error for <tt>is_other(p1) &amp;&amp; is_other(p2)</tt> &mdash;
there's no reason that you can't give a sane answer for paths to NT pipes. (Do POSIX FIFOs give garbage answers here?)
</p>
</blockquote>
<p>
Davis Herring:
</p>
<blockquote>
<p>
I'm fine with an error if either path does not exist. See also Late 29: I would much prefer
</p>
<blockquote><pre>
file_identity identity(const path&amp;, bool resolve = true);
</pre></blockquote>
<p>
which would of course produce an error if the path did not exist (or, with the default <tt>resolve</tt>, was a broken symlink).
<p/>
See Late 30 and 32 (31 has been resolved). FIFOs pose no trouble: you can even <tt>fstat(2)</tt> on the naked file
descriptors produced by <tt>pipe(2)</tt>. (That said, I observe the strange inconsistency that Linux but not macOS
gives both ends of a pipe the same <tt>st_ino</tt>.)
<p/>
POSIX has no reason that I know of to treat any file type specially for <tt>equivalent()</tt>.
</p>
</blockquote>
<p>
Billy O'Neal:
</p>
<blockquote>
<p>
I think such a <tt>file_identity</tt> feature would be useful but we can always add it in addition to <tt>equivalent</tt>
post-C++17.
</p>
</blockquote>
<p>
Beman Dawes:
</p>
<blockquote>
<p>
Looks good to me. Maybe submit this as an issue right away in the hopes it can go in C++17?
</p>
</blockquote>

<p><i>[2017-03-04, Kona]</i></p>

<p>Set priority to 0; Tentatively Ready</p>


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

<ol>
<li><p>Make the following edits to 27.10.15.12 [fs.op.equivalent]:</p>

<blockquote>
<pre>
bool equivalent(const path&amp; p1, const path&amp; p2);
bool equivalent(const path&amp; p1, const path&amp; p2, error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
<del>-1- Let <tt>s1</tt> and <tt>s2</tt> be <tt>file_status</tt>s determined as if by <tt>status(p1)</tt> and <tt>status(p2)</tt>,
respectively.</del>
<p/>
<del>-2- <i>Effects:</i> Determines <tt>s1</tt> and <tt>s2</tt>. If <tt>(!exists(s1) &amp;&amp; !exists(s2)) || (is_other(s1) &amp;&amp;
is_other(s2))</tt> an error is reported (27.10.7).</del>
<p/>
-3- <i>Returns:</i> <tt>true</tt>, if <del><tt>s1 == s2</tt> and</del> <tt>p1</tt> and <tt>p2</tt> resolve to the same file system
entity, else <tt>false</tt>. The signature with argument <tt>ec</tt> returns <tt>false</tt> if an error occurs.
<p/>
-4- Two paths are considered to resolve to the same file system entity if two candidate entities reside on the
same device at the same location. <ins>[<i>Note:</i> On POSIX platforms, t</ins><del>T</del>his is determined as if by the values
of the POSIX <tt>stat</tt> structure, obtained as if by <tt>stat()</tt> for the two paths, having equal <tt>st_dev</tt> values and
equal <tt>st_ino</tt> values. <ins>&mdash; <i>end note</i>]</ins>
<p/>
<ins>-?- <i>Remarks:</i> <tt>!exists(p1) || !exists(p2)</tt> is an error.</ins>
<p/>
-5- <i>Throws:</i> As specified in 27.10.7.
</p>
</blockquote>
</blockquote>

</li>
</ol>







<hr>
<h3><a name="2940" href="#2940">2940.</a> <tt>result_of</tt> specification also needs a little cleanup</h3>
<p><b>Section:</b> D.11 [depr.meta.types] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2017-03-04 <b>Last modified:</b> 2017-06-15</p>
<p><b>Priority: </b>3
</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="http://wg21.link/p0604r0">P0604R0</a> missed a similar adjustment that was performed for the
deprecated type trait templates <tt>is_literal_type</tt> and <tt>is_literal_type_v</tt> via LWG <a href="lwg-defects.html#2838">2838</a>:
<p/>
Moving the <tt>result_of</tt> to Annex D means that the general prohibition against specializing type traits
in [meta.type.synop]/1 does no longer exist, so should be explicitly spelled out. Wording will be provided
after publication of the successor of <a href="http://wg21.link/n4640">N4640</a>.
</p>

<p><i>[2017-03-04, Kona]</i></p>

<p>Set priority to 3</p>

<p><i>[2017-04-24, Daniel provides wording]</i></p>

<p>
Instead of enumerating all the templates where adding a specialization is valid, a general exclusion rule is provided.
Albeit currently not needed for the templates handled by this sub-clause, a potential exception case is constructed
to ensure correctness for the first deprecated trait template that would permit specializations by the user.
</p>

<p><i>[2017-06-10, 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/n4659">N4659</a>.</p>

<ol>
<li><p>Change D.11 [depr.meta.types] as indicated:</p>
<blockquote>
<p>
-4- The behavior of a program that adds specializations for <ins>any of the templates defined in this subclause</ins>
<del><tt>is_literal_type</tt> or <tt>is_literal_type_v</tt></del> is undefined<ins>, unless explicitly permitted by the
specification of the corresponding template</ins>.
</p>
</blockquote>
</li>
</ol>







<hr>
<h3><a name="2942" href="#2942">2942.</a> LWG 2873's resolution missed <tt>weak_ptr::owner_before</tt></h3>
<p><b>Section:</b> 20.11.2.3.5 [util.smartptr.weak.obs] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-03-09 <b>Last modified:</b> 2017-06-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.weak.obs">issues</a> in [util.smartptr.weak.obs].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The NB comment asked for <tt>noexcept</tt> on <tt>shared_ptr::owner_before</tt>, <tt>weak_ptr::owner_before</tt>, and
<tt>owner_less::operator()</tt>, but the PR of LWG <a href="lwg-defects.html#2873">2873</a> only added it to the first and the third one.
</p>

<p><i>[2017-06-03, 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/n4659">N4659</a>.
</p>

<ol>
<li><p>Edit 20.11.2.3 [util.smartptr.weak],  class template <tt>weak_ptr</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
[&hellip;]
<i>// 20.11.2.3.5 [util.smartptr.weak.obs], observers</i>
[&hellip;]
template&lt;class U&gt; bool owner_before(const shared_ptr&lt;U&gt;&amp; b) const <ins>noexcept</ins>;
template&lt;class U&gt; bool owner_before(const weak_ptr&lt;U&gt;&amp; b) const <ins>noexcept</ins>;
</pre>
</blockquote>
</li>

<li><p>Edit 20.11.2.3.5 [util.smartptr.weak.obs] immediately before p4 as indicated:</p>
<blockquote>
<pre>
template&lt;class U&gt; bool owner_before(const shared_ptr&lt;U&gt;&amp; b) const <ins>noexcept</ins>;
template&lt;class U&gt; bool owner_before(const weak_ptr&lt;U&gt;&amp; b) const <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-4- <i>Returns:</i> An unspecified value such that [&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2954" href="#2954">2954.</a> Specialization of the convenience variable templates should be prohibited</h3>
<p><b>Section:</b> 17.5.4 [constraints] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-03-31 <b>Last modified:</b> 2017-06-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There's currently no rule against specializing the various <tt>_v</tt>
convenience variable templates outside of <tt>&lt;type_traits&gt;</tt>.
<p/>
There should be; <tt>foo_v&lt;T&gt;</tt> should be always equal to
<tt>foo&lt;T&gt;::value</tt>. The correct way to influence, say,
<tt>is_placeholder_v&lt;T&gt;</tt> should be to specialize <tt>is_placeholder</tt>,
not <tt>is_placeholder_v</tt>. Otherwise, the editorial changes to use the
<tt>_v</tt> form to the specification would no longer be editorial but have
normative impact.
<p/>
Adding a global prohibition in 17.5.4.2.1 [namespace.std] seems preferable to
adding individual prohibitions to each affected template; the PR below
carves out an exception for variable templates that are intended to be
specialized by users. As far as I know there are no such templates in
the current WP, but the Ranges TS does use them.
</p>

<p><i>[2017-06-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/n4659">N4659</a>.
</p>

<ol>
<li><p>Add a paragraph to 17.5.4.2.1 [namespace.std], before p2:</p>

<blockquote>
<p>
-1- The behavior of a C++ program is undefined if it adds declarations or definitions to namespace <tt>std</tt> or to a
namespace within namespace <tt>std</tt> unless otherwise specified. A program may add a template specialization
for any standard library template to namespace <tt>std</tt> only if the declaration depends on a user-defined type
and the specialization meets the standard library requirements for the original template and is not explicitly
prohibited.(footnote: [&hellip;])
<p/>
<ins>-?- The behavior of a C++ program is undefined if it declares an explicit or partial specialization of any
standard library variable template, except where explicitly permitted by the specification of that variable template.</ins>
<p/>
-2- The behavior of a C++ program is undefined if it declares [&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2961" href="#2961">2961.</a> Bad postcondition for <tt>set_default_resource</tt></h3>
<p><b>Section:</b> 20.12.4 [mem.res.global] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2017-05-09 <b>Last modified:</b> 2017-06-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specification of <tt>set_default_resource</tt> in <a href="http://wg21.link/n4659">N4659</a>
20.12.4 [mem.res.global] reads:
</p>
<blockquote>
<pre>
memory_resource* set_default_resource(memory_resource* r) noexcept;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> If <tt>r</tt> is non-null, sets the value of the default memory resource pointer to <tt>r</tt>,
otherwise sets the default memory resource pointer to <tt>new_delete_resource()</tt>.
<p/>
-5- <i>Postconditions:</i> <tt>get_default_resource() == r</tt>.
<p/>
-6- <i>Returns:</i> The previous value of the default memory resource pointer.
<p/>
-7- Remarks: [&hellip;]
</p>
</blockquote>
</blockquote>
<p>
It is apparent that the effects specified in para 4 cannot &mdash; and indeed should not &mdash; achieve the
postcondition specified in para 5 when <tt>r</tt> is null.
</p>

<p><i>[2017-05-13, Tim comments]</i></p>

<p>
This is the same issue as LWG <a href="lwg-defects.html#2522">2522</a>, which <i>just</i> missed the Fundamentals TS working draft used for the merge.
A similar resolution (simply striking the <i>Postconditions:</i> paragraph) might be better.
</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>Modify 20.12.4 [mem.res.global] as follows:</p>

<blockquote>
<pre>
memory_resource* set_default_resource(memory_resource* r) noexcept;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> If <tt>r</tt> is non-null, sets the value of the default memory resource pointer to <tt>r</tt>,
otherwise sets the default memory resource pointer to <tt>new_delete_resource()</tt>.
<p/>
-5- <i>Postconditions:</i> <ins>If <tt>r</tt> is non-null,</ins> <tt>get_default_resource() == r</tt>. <ins>Otherwise,
<tt>get_default_resource() == new_delete_resource()</tt>.</ins>
<p/>
-6- <i>Returns:</i> The previous value of the default memory resource pointer.
<p/>
-7- Remarks: [&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2017-06-13, Casey Carter revises proposed wording]</i></p>

<p>
I suggest to strike the Postconditions paragraph ([mem.res.global]/5) completely, as in LWG <a href="lwg-defects.html#2522">2522</a>
</p>

<p><i>[2017-06-15, 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/n4659">N4659</a>.</p>

<ol>
<li>
<p>Modify 20.12.4 [mem.res.global] as follows:</p>

<blockquote>
<pre>
memory_resource* set_default_resource(memory_resource* r) noexcept;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> If <tt>r</tt> is non-null, sets the value of the default memory resource pointer to <tt>r</tt>,
otherwise sets the default memory resource pointer to <tt>new_delete_resource()</tt>.
<p/>
<del>-5- <i>Postconditions:</i> <tt>get_default_resource() == r</tt>.</del>
<p/>
-6- <i>Returns:</i> The previous value of the default memory resource pointer.
<p/>
-7- Remarks: [&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2966" href="#2966">2966.</a> Incomplete resolution of US 74</h3>
<p><b>Section:</b> 99 [fs.path.native.obs] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2017-05-25 <b>Last modified:</b> 2017-06-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://wg21.link/p0492r1#US74">P0492R1 US-74</a> failed to replace one occurrence of <tt>pathstring</tt>,
in [fs.path.native.obs] p8. It should be changed to <tt>native()</tt>, as with the other native format observers.
</p>

<p><i>[2017-06-12, 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/n4659">N4659</a>.</p>

<ol>
<li>
<p>Edit 99 [fs.path.native.obs] as indicated:</p>

<blockquote>
<pre>
std::string string() const;
std::wstring wstring() const;
std::string u8string() const;
std::u16string u16string() const;
std::u32string u32string() const;
</pre>
<blockquote>
<p>
-8- <i>Returns:</i> <tt><del>pathstring</del><ins>native()</ins></tt>.
<p/>
-9- <i>Remarks:</i> Conversion, if any, is performed as specified by  [fs.path.cvt]. The encoding of the string
returned by <tt>u8string()</tt> is always UTF-8.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2974" href="#2974">2974.</a> Diagnose out of bounds <tt>tuple_element</tt>/<tt>variant_alternative</tt></h3>
<p><b>Section:</b> 20.4.4 [pair.astuple], 20.7.4 [variant.helper] <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-06-10 <b>Last modified:</b> 2017-06-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#pair.astuple">issues</a> in [pair.astuple].</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>
Instantiating <tt>tuple_element</tt> with an out-of-bounds index requires a diagnostic for <tt>tuple</tt> and <tt>array</tt>,
but not for <tt>pair</tt>. The specification requires an out-of-bounds index for <tt>pair</tt> to go to the base template
instead, which is undefined.
<p/>
Similarly, instantiating <tt>variant_alternative</tt> with an out-of-bounds index violates a requirement, but it is not
required to be diagnosed.
</p>

<p><i>[2017-06-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/n4659">N4659</a>.</p>

<ol>
<li>
<p>Modify 20.2.1 [utility.syn], header <tt>&lt;utility&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]

<i>// 20.4.4 [pair.astuple], tuple-like access to pair</i>
template &lt;class T&gt; class tuple_size;
template &lt;size_t I, class T&gt; class tuple_element;
template &lt;class T1, class T2&gt; struct tuple_size&lt;pair&lt;T1, T2&gt;&gt;;
<ins>template &lt;size_t I, class T1, class T2&gt; struct tuple_element&lt;I, pair&lt;T1, T2&gt;&gt;;</ins>
<del>template &lt;class T1, class T2&gt; struct tuple_element&lt;0, pair&lt;T1, T2&gt;&gt;;
template &lt;class T1, class T2&gt; struct tuple_element&lt;1, pair&lt;T1, T2&gt;&gt;;</del>

[&hellip;]
</pre>
</blockquote>
</li>

<li>
<p>Modify 20.4.4 [pair.astuple] as indicated:</p>

<blockquote>
<pre>
<del>tuple_element&lt;0, pair&lt;T1, T2&gt;&gt;::type</del>
</pre>
<blockquote>
<p>
<del>-1- <i>Value:</i> The type <tt>T1</tt>.</del>
</p>
</blockquote>
<pre>
<del>tuple_element&lt;1, pair&lt;T1, T2&gt;&gt;::type</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Value:</i> The type <tt>T2</tt>.</del>
</p>
</blockquote>
<pre>
<ins>tuple_element&lt;I, pair&lt;T1, T2&gt;&gt;::type</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires:</i> <tt>I &lt; 2</tt>. The program is ill-formed if <tt>I</tt> is out of bounds.</ins>
<p/>
<ins>-?- <i>Value:</i> The type <tt>T1</tt> if <tt>I == 0</tt>, otherwise the type <tt>T2</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>Modify 20.7.4 [variant.helper] as indicated:</p>

<blockquote>
<pre>
variant_alternative&lt;I, variant&lt;Types...&gt;&gt;::type
</pre>
<blockquote>
<p>
-4- <i>Requires:</i> <tt>I &lt; sizeof...(Types)</tt>. <ins>The program is ill-formed if <tt>I</tt> is out of bounds.</ins>
<p/>
-5- <i>Value:</i> The type <tt>T<sub><i>I</i></sub></tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






</body>
</html>
