<!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 Virtual Plenary, Nov. 2020</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 Virtual Plenary, Nov. 2020</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P2236R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>2020-10-14</p>
</td>
</tr>
<tr>
<td align="left">Audience:</td>
<td align="left">WG21</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Jonathan Wakely &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<ul>
<li><a href="#ready">Ready Issues</a></li>
<li><a href="#tentatively_ready">Tentatively Ready Issues</a></li>
<li><a href="#tentatively_nad">Tentatively NAD Issues</a></li>
</ul>
<h2 id="ready">Ready Issues</h2>
<p>
These 13 issues were moved to <b>Ready</b> at the end of the Prague meeting.
</p>
<hr>
<h3><a name="2839" href="https://cplusplus.github.io/LWG/lwg-active.html#2839">2839</a>. Self-move-assignment of library types, again</h3>
<p><b>Section:</b> 16.4.6.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>, 16.4.5.9 <a href="https://wg21.link/res.on.arguments">[res.on.arguments]</a>, 22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-12-09 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2468">2468</a>'s resolution added to <tt>MoveAssignable</tt> the requirement to tolerate self-move-assignment,
but that does nothing for library types that aren't explicitly specified to meet <tt>MoveAssignable</tt> other than make
those types not meet <tt>MoveAssignable</tt> any longer.
</p>
<p>
To realize the intent here, we need to carve out an exception to 16.4.5.9 <a href="https://wg21.link/res.on.arguments">[res.on.arguments]</a>'s restriction for
move assignment operators and specify that self-move-assignment results in valid but unspecified state unless otherwise
specified. The proposed wording below adds that to 16.4.6.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a> since it seems to fit well with the
theme of the current paragraph in that section.
</p>
<p> In addition, to address the issue with 22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> noted in LWG
<a href="https://cplusplus.github.io/LWG/lwg-defects.html#2468">2468</a>'s discussion, the requirement tables in that subclause will need to be edited in a way similar to
LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2468">2468</a>.
</p>

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

<p>Priority 2</p>

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

<p>Status to 'Open'; Howard to reword using 'MoveAssignable'.</p>

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

<ol>
<li><p>Add a new paragraph at the end of 16.4.6.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>:</p>
<blockquote>
<p>
-1- Objects of types defined in the C++ standard library may be moved from (12.8). Move operations may be
explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be
placed in a valid but unspecified state.
</p>
<p>
<ins>-?- An object of a type defined in the C++ standard library may be move-assigned (11.4.6 <a href="https://wg21.link/class.copy.assign">[class.copy.assign]</a>)
to itself. Such an assignment places the object in a valid but unspecified state unless otherwise specified.</ins>
</p>
</blockquote>
</li>

<li><p>Add a note at the end of 16.4.5.9 <a href="https://wg21.link/res.on.arguments">[res.on.arguments]</a>/1, bullet 3, as indicated:</p>
<blockquote>
<p>
-1- Each of the following applies to all arguments to functions defined in the C++ standard library, unless
explicitly stated otherwise.
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; [&hellip;]</p></li>
<li><p>(1.2) &mdash; [&hellip;]</p></li>
<li><p>(1.3) &mdash; If a function argument binds to an rvalue reference parameter, the implementation may
assume that this parameter is a unique reference to this argument. [<i>Note:</i> If the parameter is a generic parameter
of the form <tt>T&amp;&amp;</tt> and an lvalue of type <tt>A</tt> is bound, the argument binds to an lvalue reference
(14.8.2.1) and thus is not covered by the previous sentence. &mdash; <i>end note</i>] [<i>Note:</i> If a program
casts an lvalue to an xvalue while passing that lvalue to a library function (e.g. by calling the function with the argument
<tt>std::move(x)</tt>), the program is effectively asking that function to treat that lvalue as a temporary.
The implementation is free to optimize away aliasing checks which might be needed if the argument
was an lvalue. &mdash; <i>end note</i>] <ins>[<i>Note:</i> This does not apply to the argument passed to a
move assignment operator (16.4.6.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>). &mdash; <i>end note</i>]</ins></p></li>
</ol>
</blockquote>
</li>

<li><p>Edit Table 83 "Container requirements" in 22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 83 &mdash; Container requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational<br/>semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

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

<tr>
<td><tt>a = rv</tt></td>
<td><tt>T&amp;</tt></td>
<td>All existing elements of <tt>a</tt><br/>
are either move<br/>
assigned to or<br/>
destroyed</td>
<td><ins>post: If <tt>a</tt> and <tt>rv</tt> do not refer to the same object,</ins><br/>
<tt>a</tt> shall be equal to the value that<br/>
<tt>rv</tt> had before this assignment</td>
<td>linear</td>
</tr>

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

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

<li><p>Edit Table 86 "Allocator-aware container requirements" in 22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 86 &mdash;  Allocator-aware container requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>
<tr>
<td><tt>a = rv</tt></td>
<td><tt>T&amp;</tt></td>
<td>
<i>Requires</i>: If <tt>allocator_traits&lt;allocator_type<br/>
&gt;::propagate_on_container_move_assignment::value</tt><br/>
is <tt>false</tt>, <tt>T</tt> is <tt>MoveInsertable</tt><br/>
into <tt>X</tt> and <tt>MoveAssignable</tt>.<br/>
All existing elements of <tt>a</tt> are either<br/>
move assigned to or destroyed.<br/>
post: <ins>If <tt>a</tt> and <tt>rv</tt> do not refer<br/>
to the same object,</ins> <tt>a</tt> shall be equal<br/>
to the value that <tt>rv</tt> had before this assignment</td>
<td>linear</td>
</tr>
<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2018-08-16, Howard comments and provides updated wording]</i></p>

<p>
I agreed to provide proposed wording for LWG 2839 that was reworded to use <tt>MoveAssignable</tt>. The advantage of
this is that <tt>MoveAssignable</tt> specifies the self-assignment case, thus we do not need to repeat ourselves.
</p>

<p><i>[2018-08-23 Batavia Issues processing]</i></p>

<p>Howard and Tim to discuss a revised P/R.</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to <a href="https://wg21.link/n4762">N4762</a>.</p>
<ol>
<li><p>Add a new subsection to 16.4.6 <a href="https://wg21.link/conforming">[conforming]</a> after 16.4.6.5 <a href="https://wg21.link/member.functions">[member.functions]</a>:</p>
<blockquote>
<p>
<ins><b>Special members [conforming.special]</b></ins>
</p>
<p>
<ins>Class types defined by the C++ standard library and specified to be default constructible, move constructible,
copy constructible, move assignable, copy assignable, or destructible, shall meet the associated requirements
<i>Cpp17DefaultConstructible</i>, <i>Cpp17MoveConstructible</i>, <i>Cpp17CopyConstructible</i>,
<i>Cpp17MoveAssignable</i>, <i>Cpp17CopyAssignable</i>, and <i>Cpp17Destructible</i>, respectively
(16.4.4.2 <a href="https://wg21.link/utility.arg.requirements">[utility.arg.requirements]</a>).</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-06-06 Tim restores and updates P/R following 2020-05-29 telecon discussion]</i></p>

<p>The standard doesn't define phrases like "default constructible" used in the
previous P/R. Moreover, the library provides a variety of wrapper types, and
whether these types meet the semantic requirements of <i>Cpp17Meowable</i>
(and maybe even syntactic, depending on how "copy constructible" is interpreted)
depends on the property of their underlying wrapped types, which might not even
be an object type (e.g., <tt>tuple</tt> or <tt>pair</tt> of references). This is
a large can of worms (see LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#2146">2146</a>) that we don't want to get into.
</p>
<p>
There is a suggestion in the telecon to blanket-exempt move-assignment operators from
the 16.4.5.9 <a href="https://wg21.link/res.on.arguments">[res.on.arguments]</a> 1.3 requirement. The revised wording below
does not do so, as that would carve out not just self-move-assignment but also
other aliasing scenarios in which the target object owns the source object.
Whether such scenarios should be permitted is outside the scope of this issue,
though notably <tt>assignable_from</tt> (18.4.8 <a href="https://wg21.link/concept.assignable">[concept.assignable]</a>)
contains a note alluding to these cases and suggesting that they should be
considered to be outside the domain of <tt>=</tt> entirely.
</p>

<p><i>[2020-07-17; issue processing telecon]</i></p>

<p>
LWG reviewed the latest proposed resolution.
Unanimous consent to move to Ready.
</p>


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

<ol>
<li><p>Add a new paragraph at the end of 16.4.6.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>:</p>
<blockquote>
<p>
-1- Objects of types defined in the C++ standard library may be moved from
( [clss.copy.ctor]). Move operations may be explicitly specified or
implicitly generated. Unless otherwise specified, such moved-from objects shall
be placed in a valid but unspecified state.
</p>
<p>
<ins>-?- An object of a type defined in the C++ standard library may be
move-assigned (11.4.6 <a href="https://wg21.link/class.copy.assign">[class.copy.assign]</a>) to itself. Unless otherwise
specified, such an assignment places the object in a valid but unspecified state.</ins>
</p>
</blockquote>
</li>

<li><p>Edit 16.4.5.9 <a href="https://wg21.link/res.on.arguments">[res.on.arguments]</a>/1, bullet 3, as indicated:</p>
<blockquote>
<p>
-1- Each of the following applies to all arguments to functions defined in the C++ standard library, unless
explicitly stated otherwise.
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; [&hellip;]</p></li>
<li><p>(1.2) &mdash; [&hellip;]</p></li>
<li><p>(1.3) &mdash; If a function argument binds to an rvalue reference parameter, the implementation may
assume that this parameter is a unique reference to this argument<ins>, except that the argument passed to a
move-assignment operator may be a reference to <tt>*this</tt> (16.4.6.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>)</ins>.
[<i>Note:</i> If the <ins>type of a</ins> parameter is a <del>generic parameter
of the form <tt>T&amp;&amp;</tt> and an lvalue of type <tt>A</tt> is bound, the argument binds to an lvalue reference
(13.10.3.2 <a href="https://wg21.link/temp.deduct.call">[temp.deduct.call]</a>) and thus is not covered by the previous sentence.</del>
<ins>forwarding reference (13.10.3.2 <a href="https://wg21.link/temp.deduct.call">[temp.deduct.call]</a>) that is deduced to an lvalue reference type,
then the argument is not bound to an rvalue reference.</ins> &mdash; <i>end note</i>] [<i>Note:</i> If a program
casts an lvalue to an xvalue while passing that lvalue to a library function (e.g. by calling the function with the argument
<tt>std::move(x)</tt>), the program is effectively asking that function to treat that lvalue as a temporary.
The implementation is free to optimize away aliasing checks which might be needed if the argument
was an lvalue. &mdash; <i>end note</i>]</p></li>
</ol>
</blockquote>
</li>

<li><p>Edit Table 73 "Container requirements" in 22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 73 &mdash; Container requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational<br/>semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

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

<tr>
<td><tt>a = rv</tt></td>
<td><tt>T&amp;</tt></td>
<td>All existing elements of <tt>a</tt> are either move assigned to or destroyed</td>
<td><i>Postconditions:</i>
<ins>If <tt>a</tt> and <tt>rv</tt> do not refer to the same object,</ins>
<tt>a</tt> is equal to the value that <tt>rv</tt> had before this assignment<ins>.</ins></td>
<td>linear</td>
</tr>

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

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

<li><p>Edit Table 76 "Allocator-aware container requirements" in 22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 86 &mdash;  Allocator-aware container requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>
<tr>
<td><tt>a = rv</tt></td>
<td><tt>T&amp;</tt></td>
<td>
<i>Preconditions</i>: If <tt>allocator_traits&lt;allocator_type&gt;<br/>
::propagate_on_container_move_assignment::value</tt> is <tt>false</tt>,<br/>
<tt>T</tt> is <i>Cpp17MoveInsertable</i>
into <tt>X</tt> and <i>Cpp17MoveAssignable</i>.<br/>
<i>Effects:</i> All existing elements of <tt>a</tt> are either
move assigned to or destroyed.<br/>
<i>Postconditions:</i> <ins>If <tt>a</tt> and <tt>rv</tt> do not refer
to the same object,</ins> <tt>a</tt> is equal
to the value that <tt>rv</tt> had before this assignment.</td>
<td>linear</td>
</tr>
<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3117" href="https://cplusplus.github.io/LWG/lwg-active.html#3117">3117</a>. Missing <tt>packaged_task</tt> deduction guides</h3>
<p><b>Section:</b> 32.9.10 <a href="https://wg21.link/futures.task">[futures.task]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Marc Mutz <b>Opened:</b> 2018-06-08 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#futures.task">issues</a> in [futures.task].</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::function</tt> has deduction guides, but <tt>std::packaged_task</tt>, which is otherwise very
similar, does not. This is surprising to users and I can think of no reason for the former
to be treated differently from the latter. I therefore propose to add deduction guides for
packaged task with the same semantics as the existing ones for function.
</p>

<p><i>[2018-06-23 after reflector discussion]</i></p>

<p>Priority set to 3</p>

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

<ol>
<li><p>Modify 32.9.10 <a href="https://wg21.link/futures.task">[futures.task]</a>, class template <tt>packaged_task</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
  [&hellip;]
  template&lt;class R, class... ArgTypes&gt;
  class packaged_task&lt;R(ArgTypes...)&gt; {
    [&hellip;]
  };
  
  <ins>template&lt;class R, class... ArgTypes&gt;
  packaged_task(R (*)( ArgTypes ...)) -&gt; packaged_task&lt;R( ArgTypes...)&gt;;

  template&lt;class F&gt; packaged_task(F) -&gt; packaged_task&lt;<i>see below</i>&gt;;</ins>
  
  template&lt;class R, class... ArgTypes&gt;
    void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp; x, packaged_task&lt;R(ArgTypes...)&gt;&amp; y) noexcept;
}
</pre>
</blockquote>
</li>

<li><p>Modify 32.9.10.2 <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>
[&hellip;]
<pre>
<ins>template&lt;class F&gt; packaged_task(F) -&gt; packaged_task&lt;<i>see below</i>&gt;;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Remarks:</i> This deduction guide participates in overload resolution only if <tt>&amp;F::operator()</tt> 
is well-formed when treated as an unevaluated operand. In that case, if <tt>decltype(&amp;F::operator())</tt> is of the 
form <tt>R(G::*)(A...) <i>cv</i> &amp;<sub><i>opt</i></sub> noexcept<sub><i>opt</i></sub></tt> for a class type <tt>G</tt>, 
then the deduced type is <tt>packaged_task&lt;R(A...)&gt;</tt>.</ins>
</p>
</blockquote>
[&hellip;]
<pre>
packaged_task(packaged_task&amp;&amp; rhs) noexcept;
</pre>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-13; Prague]</i></p>

<p>
LWG improves wording matching Marshall's Mandating paper.
</p>

<p><i>[2020-02-14; Prague]</i></p>

<p>
Do we want a feature test macro for this new feature?
</p>
<blockquote><pre>
F N A
1 7 6
</pre></blockquote>

<p><i>[Status to Ready on Friday in Prague.]</i></p>



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

<ol>
<li><p>Modify 32.9.10 <a href="https://wg21.link/futures.task">[futures.task]</a>, class template <tt>packaged_task</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
  [&hellip;]
  template&lt;class R, class... ArgTypes&gt;
  class packaged_task&lt;R(ArgTypes...)&gt; {
    [&hellip;]
  };
  
  <ins>template&lt;class R, class... ArgTypes&gt;
  packaged_task(R (*)(ArgTypes...)) -&gt; packaged_task&lt;R(ArgTypes...)&gt;;

  template&lt;class F&gt; packaged_task(F) -&gt; packaged_task&lt;<i>see below</i>&gt;;</ins>
  
  template&lt;class R, class... ArgTypes&gt;
    void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp; x, packaged_task&lt;R(ArgTypes...)&gt;&amp; y) noexcept;
}
</pre>
</blockquote>
</li>

<li><p>Modify 32.9.10.2 <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>
[&hellip;]
<pre>
<ins>template&lt;class F&gt; packaged_task(F) -&gt; packaged_task&lt;<i>see below</i>&gt;;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>&amp;F::operator()</tt> is well-formed when treated as an unevaluated operand 
and <tt>decltype(&amp;F::operator())</tt> is of the form <tt>R(G::*)(A...) <i>cv</i> &amp;<sub><i>opt</i></sub> 
noexcept<sub><i>opt</i></sub></tt> for a class type <tt>G</tt>.</ins>
<p/>
<ins>-?- <i>Remarks:</i> The deduced type is <tt>packaged_task&lt;R(A...)&gt;</tt>.</ins>
</p>
</blockquote>
[&hellip;]
<pre>
packaged_task(packaged_task&amp;&amp; rhs) noexcept;
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3143" href="https://cplusplus.github.io/LWG/lwg-active.html#3143">3143</a>. <tt>monotonic_buffer_resource</tt> growth policy is unclear</h3>
<p><b>Section:</b> 20.12.6 <a href="https://wg21.link/mem.res.monotonic.buffer">[mem.res.monotonic.buffer]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2018-07-20 <b>Last modified:</b> 2020-07-17</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
During the discussion of LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3120">3120</a> it was pointed out that the current
wording in 20.12.6 <a href="https://wg21.link/mem.res.monotonic.buffer">[mem.res.monotonic.buffer]</a> is contradictory. The introductory text for 
the class says "Each additional buffer is larger than the previous one, following 
a geometric progression" but the spec for <tt>do_allocate</tt> doesn't agree.
<p/>
Firstly, it's impossible for the implementation to ensure a single geometric progression, 
because the size of the next buffer can be arbitrarily large. If the caller asks for an 
allocation that is <tt>N</tt> times bigger than the previous buffer, the next buffer will be at
least <tt>N</tt> times larger than the previous one. If <tt>N</tt> is larger than the
implementation-defined growth factor it's not a geometric progression.
<p/>
Secondly, it's not even clear that each additional buffer will be larger than the previous one. 
Given a <tt>monotonic_buffer_resource</tt> object with little remaining space in <tt>current_buffer</tt>, 
a request to allocate <tt>10*next_buffer_size</tt> will:
<p/>
"set <tt>current_buffer</tt> to <tt>upstream_rsrc-&gt;allocate(n, m)</tt>, where <tt>n</tt> is not
less than <tt>max(bytes, next_buffer_size)</tt> and <tt>m</tt> is not less than <tt>alignment</tt>, 
and increase <tt>next_buffer_size</tt> by an implementation-defined growth factor (which need not 
be integral), then allocate the return block from the newly-allocated <tt>current_buffer</tt>."
<p/>
The effects are to allocate a new buffer of at least <tt>max(10*next_buffer_size, next_buffer_size)</tt> 
bytes, and then do <tt>next_buffer_size *= growth_factor</tt>. If <tt>growth_factor &lt; 10</tt> then 
the next allocated buffer might be smaller than the last one. This means that although 
<tt>next_buffer_size</tt> itself follows a geometric progression, the actual size of any single 
allocated buffer can be much larger than <tt>next_buffer_size</tt>. A graph of the allocated sizes looks 
like a geometric progression with spikes where an allocation size is larger than <tt>next_buffer_size</tt>.
<p/>
If the intention is to set <tt>next_buffer_size = max(n, next_buffer_size * growth_factor)</tt> so 
that every allocation from upstream is larger than the previous one, then we need a change to the 
<i>Effects:</i> to actually say that. Rather than a geometric progression with anomalous spikes,
this would produce a number of different geometric progressions with discontinuous jumps between them.
<p/>
If the spiky interpretation is right then we need to weaken the "Each additional buffer is larger" 
statement. Either way, we need to add a caveat to the "following a geometric progression" text 
because that isn't true for the spiky interpretation or the jumpy interpretation.
<p/>
Thirdly, the <i>Effects:</i> says that the size of the allocated block, <tt>n</tt>, is not less than 
<tt>max(bytes, next_buffer_size)</tt>. This seems to allow an implementation to choose to do 
<tt>n = ceil2(max(bytes, next_buffer_size))</tt> if it wishes (maybe because allocating sizes that 
are a power of 2 simplifies the <tt>monotonic_buffer_resource</tt> implementation, or allows reducing 
the bookkeeping overhead). This still results in an approximate geometric progression (under either 
the spiky or jumpy interpretation) but the graph has steps rather than being a smooth curve (but 
always above the curve). This is another way that "Each additional buffer is larger than the previous 
one" is not guaranteed. Even if <tt>max(bytes, next_buffer_size)</tt> is greater on every call, for a
growth factor between <tt>1.0</tt> and <tt>2.0</tt> the result of <tt>ceil2</tt> might be the same 
for two successive buffers. I see no reason to forbid this, but Pablo suggested it's not allowed 
because it doesn't result in exponential growth (which I disagree with). If this is supposed to be
forbidden, the wording needs to be fixed to forbid it.
</p>

<p><i>[2019-01-20 Reflector prioritization]</i></p>

<p>Set Priority to 2</p>

<p><i>[2020-02-13, Prague]</i></p>

<p>
LWG looked at the issue and a suggestion was presented to eliminate most of 20.12.6 <a href="https://wg21.link/mem.res.monotonic.buffer">[mem.res.monotonic.buffer]</a>
to solve the problem the current requirements impose.
</p>

<p><i>[2020-02-16; Prague]</i></p>

<p>Reviewed revised wording and moved to Ready for Varna.</p>



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

<ol>
<li><p>Modify 20.12.6 <a href="https://wg21.link/mem.res.monotonic.buffer">[mem.res.monotonic.buffer]</a>, as indicated:</p>

<blockquote>
<p>
-1- A <tt>monotonic_buffer_resource</tt> is a special-purpose memory resource intended for very fast memory allocations
in situations where memory is used to build up a few objects and then is released all at once when the
memory resource object is destroyed. <del>It has the following qualities:</del>
</p>
<ol style="list-style-type: none"> 
<li><p><del>(1.1) &mdash; A call to <tt>deallocate</tt> has no effect, thus the amount of memory consumed increases 
monotonically until the resource is destroyed.</del></p></li>
<li><p><del>(1.2) &mdash; The program can supply an initial buffer, which the allocator uses to satisfy memory requests.</del></p></li>
<li><p><del>(1.3) &mdash; When the initial buffer (if any) is exhausted, it obtains additional buffers from an upstream 
memory resource supplied at construction. Each additional buffer is larger than the previous one, following a
geometric progression.</del></p></li>
<li><p><del>(1.4) &mdash; It is intended for access from one thread of control at a time. Specifically, calls to <tt>allocate</tt> and
<tt>deallocate</tt> do not synchronize with one another.</del></p></li>
<li><p><del>(1.5) &mdash; It frees the allocated memory on destruction, even if <tt>deallocate</tt> has not been called 
for some of the allocated blocks.</del></p></li>
</ol>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3195" href="https://cplusplus.github.io/LWG/lwg-active.html#3195">3195</a>. What is the stored pointer value of an empty <tt>weak_ptr</tt>?</h3>
<p><b>Section:</b> 20.11.4.2 <a href="https://wg21.link/util.smartptr.weak.const">[util.smartptr.weak.const]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-03-15 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
20.11.4.2 <a href="https://wg21.link/util.smartptr.weak.const">[util.smartptr.weak.const]</a> specifies <tt>weak_ptr</tt>'s default constructor:
</p>
<blockquote>
<pre>
constexpr weak_ptr() noexcept;
</pre>
<blockquote>
<p>
1 <i>Effects:</i> Constructs an empty <tt>weak_ptr</tt> object.
<p/>
2 <i>Ensures:</i> <tt>use_count() == 0</tt>.
</p>
</blockquote>
</blockquote>
<p>
and <tt>shared_ptr</tt> converting constructor template:
</p>
<blockquote>
<pre>
weak_ptr(const weak_ptr&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr(const weak_ptr&lt;Y&gt;&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr(const shared_ptr&lt;Y&gt;&amp; r) noexcept;
</pre>
<blockquote>
<p>
3 <i>Remarks:</i> The second and third constructors shall not participate in overload resolution unless <tt>Y*</tt> is
compatible with <tt>T*</tt>.
<p/>
4 <i>Effects:</i> If <tt>r</tt> is empty, constructs an empty <tt>weak_ptr</tt> object; otherwise, constructs a
<tt>weak_ptr</tt> object that shares ownership with <tt>r</tt> and stores a copy of the pointer stored in <tt>r</tt>.
<p/>
5 <i>Ensures:</i> <tt>use_count() == r.use_count()</tt>.
</p>
</blockquote>
</blockquote>
<p>
Note that neither specifies the value of the stored pointer when the resulting <tt>weak_ptr</tt> is empty.
This didn't matter &mdash; the stored pointer value was unobservable for an empty <tt>weak_ptr</tt> &mdash;
until we added <tt>atomic&lt;weak_ptr&gt;</tt>. 31.8.7.3 <a href="https://wg21.link/util.smartptr.atomic.weak">[util.smartptr.atomic.weak]</a>/15 says:
</p>
<blockquote>
<p>
<i>Remarks:</i> Two <tt>weak_ptr</tt> objects are equivalent if they store the same pointer value and either
share ownership, or both are empty. The weak form may fail spuriously. See 31.8.2 <a href="https://wg21.link/atomics.types.operations">[atomics.types.operations]</a>.
</p>
</blockquote>
<p>
Two empty <tt>weak_ptr</tt> objects that store different pointer values are not equivalent. We <em>could</em>
correct this by changing 31.8.7.3 <a href="https://wg21.link/util.smartptr.atomic.weak">[util.smartptr.atomic.weak]</a>/15 to "Two <tt>weak_ptr</tt> objects are
equivalent if they are both empty, or if they share ownership and store the same pointer value." In practice,
an implementation of <tt>atomic&lt;weak_ptr&gt;</tt> will CAS on both the ownership (control block pointer)
and stored pointer value, so it seems cleaner to pin down the stored pointer value of an empty <tt>weak_ptr</tt>.
</p>

<p><i>[2019-06-09 Priority set to 2 after reflector discussion]</i></p>


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

<blockquote class="note">
<p>This wording is relative to <a href="https://wg21.link/n4810">N4810</a>.</p>

<ol>
<li><p>Modify 20.11.4.2 <a href="https://wg21.link/util.smartptr.weak.const">[util.smartptr.weak.const]</a> as indicated (note the drive-by edit to cleanup the occurrences of "constructs
an object of class foo"):</p>

<blockquote><pre>
constexpr weak_ptr() noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Constructs an empty <del><tt>weak_ptr</tt></del> object <ins>that stores a null pointer value</ins>.
<p/>
-2- <i>Ensures:</i> <tt>use_count() == 0</tt>.
</p>
</blockquote>
<pre>
weak_ptr(const weak_ptr&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr(const weak_ptr&lt;Y&gt;&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr(const shared_ptr&lt;Y&gt;&amp; r) noexcept;
</pre>
<blockquote>
<p>
-3- <i>Remarks:</i> The second and third constructors shall not participate in overload resolution unless <tt>Y*</tt> is
compatible with <tt>T*</tt>.
<p/>
-4- <i>Effects:</i> If <tt>r</tt> is empty, constructs an empty <del><tt>weak_ptr</tt></del> object <ins>that stores a
null pointer value</ins>; otherwise, constructs a <tt>weak_ptr</tt> object that shares ownership with <tt>r</tt>
and stores a copy of the pointer stored in <tt>r</tt>.
<p/>
-5- <i>Ensures:</i> <tt>use_count() == r.use_count()</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-14 Casey updates P/R per LWG instruction]</i></p>

While reviewing the P/R in Prague, Tim Song noticed that the stored pointer
value of a moved-from <tt>weak_ptr</tt> must also be specified.

<p><i>[2020-02-16; Prague]</i></p>

<p>Reviewed revised wording and moved to Ready for Varna.</p>



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

<ol>
<li><p>Modify 20.11.4.2 <a href="https://wg21.link/util.smartptr.weak.const">[util.smartptr.weak.const]</a> as indicated:</p>

<blockquote><pre>
constexpr weak_ptr() noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Constructs an empty <tt>weak_ptr</tt> object <ins>that stores a null pointer value</ins>.
<p/>
-2- <i>Postconditions:</i> <tt>use_count() == 0</tt>.
</p>
</blockquote>
<pre>
weak_ptr(const weak_ptr&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr(const weak_ptr&lt;Y&gt;&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr(const shared_ptr&lt;Y&gt;&amp; r) noexcept;
</pre>
<blockquote>
<p>
-3- <i>Remarks:</i> The second and third constructors shall not participate in overload resolution unless <tt>Y*</tt> is
compatible with <tt>T*</tt>.
<p/>
-4- <i>Effects:</i> If <tt>r</tt> is empty, constructs an empty <tt>weak_ptr</tt> object <ins>that stores a
null pointer value</ins>; otherwise, constructs a <tt>weak_ptr</tt> object that shares ownership with <tt>r</tt>
and stores a copy of the pointer stored in <tt>r</tt>.
<p/>
-5- <i>Postconditions:</i> <tt>use_count() == r.use_count()</tt>.
</p>
</blockquote>
<pre>
weak_ptr(weak_ptr&amp;&amp; r) noexcept;
template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt;&amp;&amp; r) noexcept;
</pre>
<blockquote>
<p>
-6- <i>Remarks</i>: The second constructor shall not participate in overload resolution unless <tt>Y*</tt>
is compatible with <tt>T*</tt>.
<p/>
-7- <i>Effects</i>: Move constructs a <tt>weak_ptr</tt> instance from <tt>r</tt>.
<p/>
-8- <i>Postconditions</i>: <tt>*this</tt> <del>shall contain</del><ins>contains</ins> the old value of <tt>r</tt>. <tt>r</tt>
<del>shall be</del><ins>is</ins> empty<del>.</del><ins>, stores a null pointer value, and</ins>
<tt>r.use_count() == 0</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3211" href="https://cplusplus.github.io/LWG/lwg-active.html#3211">3211</a>. <tt>std::tuple&lt;&gt;</tt> should be trivially constructible</h3>
<p><b>Section:</b> 20.5.3.1 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Louis Dionne <b>Opened:</b> 2019-05-29 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
<p><b>Discussion:</b></p>
<p>
That requirement is really easy to enforce, and it has been requested by users (e.g. 
<a href="https://bugs.llvm.org/show_bug.cgi?id=41714">libc++ bug 41714</a>).
</p>

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

<ol>
<li><p>Modify 20.5.3.1 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a> as indicated:</p>

<blockquote>
<p>
-4- If <tt>is_trivially_destructible_v&lt;T<sub><i>i</i></sub>&gt;</tt> is <tt>true</tt> for all 
<tt>T<sub><i>i</i></sub></tt>, then the destructor of <tt>tuple</tt> is trivial. 
<ins>The default constructor of <tt>tuple&lt;&gt;</tt> is trivial.</ins>
</p>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
LWG discussion revealed that all where happy that we want this, except that the new wording should become 
a separate paragraph.
</p>


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

<ol>
<li><p>Modify 20.5.3.1 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a> as indicated:</p>

<blockquote>
<p>
-4- If <tt>is_trivially_destructible_v&lt;T<sub><i>i</i></sub>&gt;</tt> is <tt>true</tt> for all 
<tt>T<sub><i>i</i></sub></tt>, then the destructor of <tt>tuple</tt> is trivial. 
<p/>
<ins>-?- The default constructor of <tt>tuple&lt;&gt;</tt> is trivial.</ins>
</p>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3236" href="https://cplusplus.github.io/LWG/lwg-active.html#3236">3236</a>. Random access iterator requirements lack limiting relational operators domain to comparing 
those from the same range</h3>
<p><b>Section:</b> 23.3.5.7 <a href="https://wg21.link/random.access.iterators">[random.access.iterators]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Peter Sommerlad <b>Opened:</b> 2019-07-15 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
<p><b>Discussion:</b></p>
<p>
For forward iterators we have very clear wording regarding the restricted domain of <tt>operator==</tt>
in 23.3.5.5 <a href="https://wg21.link/forward.iterators">[forward.iterators]</a> p2:
</p>
<blockquote><p>
The domain of <tt>==</tt> for forward iterators is that of iterators over the same underlying sequence. 
However, value-initialized iterators may be compared and shall compare equal to other value-initialized 
iterators of the same type. [<i>Note:</i> Value-initialized iterators behave as if they refer past the 
end of the same empty sequence. &mdash; <i>end note</i>]
</p></blockquote>
<p>
But for the relational operators of random access iterators specified in 
23.3.5.7 <a href="https://wg21.link/random.access.iterators">[random.access.iterators]</a>, Table  [tab:randomaccessiterator],
no such domain constraints are clearly defined, except that we can infer that they are
similarly constrained as the difference of the compared iterators by means of the
operational semantics of <tt>operator&lt;</tt>.
</p>

<p><i>[2019-07-29; Casey comments and provides wording]</i></p>

<p>
Change the "Operational Semantics" column of the "<tt>a &lt; b</tt>" row of [tab:randomaccessiterator] to 
"<ins><i>Effects:</i> Equivalent to: <tt>return</tt></ins> <tt>b - a &gt; 0</tt><ins>;</ins>
<p/>
It then follows that <tt>a &lt; b</tt> is required to be well-defined over the domain for which 
<tt>b - a</tt> is required to be well-defined, which is the set of pairs <tt>(x, y)</tt> such that 
there exists a value <tt>n</tt> of type difference_type such that <tt>x + n == b</tt>.
</p>

<p><i>[2020-02-13, Prague]</i></p>

<p>
P3, but some hesitation to make it Immediate, therefore moving to Ready.
</p>


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

<ol>
<li><p>Modify 23.3.5.7 <a href="https://wg21.link/random.access.iterators">[random.access.iterators]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 87: <i>Cpp17RandomAccessIterator</i> requirements (in addition to 
<i>Cpp17BidirectionalIterator</i>) [tab:randomaccessiterator]</caption>
<tr align="center">
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr> 

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

<tr>
<td>
<tt>a &lt; b</tt>
</td>
<td>
contextually convertible to <tt>bool</tt>
</td>
<td>
<ins><i>Effects:</i> Equivalent to: <tt>return</tt></ins> <tt>b - a &gt; 0<ins>;</ins></tt>
</td>
<td>
<tt>&lt;</tt> is a total ordering relation
</td>
</tr>

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




<hr>
<h3><a name="3249" href="https://cplusplus.github.io/LWG/lwg-active.html#3249">3249</a>. There are no 'pointers' in &sect;[atomics.lockfree]</h3>
<p><b>Section:</b> 31.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2019-08-03 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>4
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#atomics.lockfree">issues</a> in [atomics.lockfree].</p>
<p><b>Discussion:</b></p>
<p>
According to SG1 experts, the requirement in [atomics.lockfree]/2 is intended to require that 
the answer for <tt>is_lock_free()</tt> be the same for a given <tt>T</tt> for a given run of 
the program. The wording does not achieve that because it's described in terms of 'pointers', 
but there are no pointers in an <tt>atomic&lt;int&gt;</tt>.
</p>

<p><i>[2020-02 Status to Ready on Thursday morning in Prague.]</i></p>



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

<ol>
<li><p>Modify 31.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> as indicated:</p>

<blockquote>
<p>
-2- The function<ins>s <tt>atomic&lt;T&gt;::is_lock_free</tt>, and</ins> <tt>atomic_is_lock_free</tt> 
(31.8.2 <a href="https://wg21.link/atomics.types.operations">[atomics.types.operations]</a>) indicate<del>s</del> whether the object is lock-free. In any given program execution, the result of the lock-free query <ins>is the same for all atomic objects</ins> <del>shall 
be consistent for all pointers</del> of the same type.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3265" href="https://cplusplus.github.io/LWG/lwg-active.html#3265">3265</a>. <tt>move_iterator</tt>'s conversions are more broken after P1207</h3>
<p><b>Section:</b> 23.5.3.4 <a href="https://wg21.link/move.iter.cons">[move.iter.cons]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-08-23 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#move.iter.cons">active issues</a> in [move.iter.cons].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#move.iter.cons">issues</a> in [move.iter.cons].</p>
<p><b>Discussion:</b></p>
<p>
The converting constructor and assignment operator specified in 23.5.3.4 <a href="https://wg21.link/move.iter.cons">[move.iter.cons]</a> 
were technically broken before P1207:
</p>
<ul>
<li><p>23.5.3.4 <a href="https://wg21.link/move.iter.cons">[move.iter.cons]</a> para 3 (and 5 for that matter) is an instance of LWG 
<a href="https://cplusplus.github.io/LWG/lwg-active.html#3105">3105</a>; it should instead mandate that <tt>u.base()</tt> is convertible to <tt>Iterator</tt>.</p></li>
<li><p>23.5.3.4 <a href="https://wg21.link/move.iter.cons">[move.iter.cons]</a> para 5 uses "is convertible" to guard an assignment operation 
instead of a conversion; it should instead mandate.</p></li>
</ul>
<p>
After applying <a href="https://wg21.link/p1207r4">P1207R4</a> "Movability of Single-pass Iterators", 
<tt>u.base()</tt> is not always well-formed, exacerbating the problem. These operations must ensure 
that <tt>u.base()</tt> is well-formed.
<p/>
Drive-by:
</p>
<ul>
<li><p>Let's burninate "Constructs a <tt>move_iterator</tt>" while we're touching this subclause.</p></li>
<li><p>We'll also burninate "Iterator operations applied..." since the requirement it wants to impose 
is covered (and indeed must be covered) by the specifications of those other operations.</p></li>
</ul>

<p><i>[2019-09-14 Priority set to 2 based on reflector discussion]</i></p>


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

<ol>
<li><p>Modify 23.5.3.4 <a href="https://wg21.link/move.iter.cons">[move.iter.cons]</a> as indicated:</p>

<blockquote>
<pre>
constexpr move_iterator();
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> <del>Constructs a <tt>move_iterator</tt>, 
v</del><ins>V</ins>alue-initializ<ins>es</ins><del>ing</del> <tt>current</tt>. <del>Iterator operations applied to the
resulting iterator have defined behavior if and only if the corresponding operations are defined on a
value-initialized iterator of type <tt>Iterator</tt>.</del>
</p>
</blockquote>
<pre>
constexpr explicit move_iterator(Iterator i);
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> <del>Constructs a move_iterator, i</del><ins>I</ins>nitializ<ins>es</ins><del>ing</del> 
<tt>current</tt> with <tt>std::move(i)</tt>.
</p>
</blockquote>
<pre>
template&lt;class U&gt; constexpr move_iterator(const move_iterator&lt;U&gt;&amp; u);
</pre>
<blockquote>
<p>
-3- <i>Mandates:</i> <tt><del>U</del><ins>u.base()</ins></tt> is <ins>well-formed and</ins> convertible 
to <tt>Iterator</tt>.
<p/>
-4- <i>Effects:</i> <del>Constructs a <tt>move_iterator</tt>, i</del><ins>I</ins>nitializ<ins>es</ins><del>ing</del> 
<tt>current</tt> with <tt>u.base()</tt>.
</p>
</blockquote>
<pre>
template&lt;class U&gt; constexpr move_iterator&amp; operator=(const move_iterator&lt;U&gt;&amp; u);
</pre>
<blockquote>
<p>
-5- <i>Mandates:</i> <del><tt>U</tt> is convertible to <tt>Iterator</tt></del><ins><tt>u.base()</tt> is 
well-formed and <tt>is_assignable_v&lt;Iterator&amp;, const U&amp;&gt;</tt> is <tt>true</tt></ins>.
<p/>
-6- <i>Effects:</i> Assigns <tt>u.base()</tt> to <tt>current</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-14; Prague]</i></p>

<p>
LWG Review. Some wording improvements have been made and lead to revised wording.
</p>

<p><i>[2020-02-16; Prague]</i></p>

<p>Reviewed revised wording and moved to Ready for Varna.</p>

<p><i>[2020-07-17; superseded by <a href="https://cplusplus.github.io/LWG/lwg-active.html#3435">3435</a>]</i></p>



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

<ol>
<li><p>Modify 23.5.3.4 <a href="https://wg21.link/move.iter.cons">[move.iter.cons]</a> as indicated:</p>

<blockquote>
<pre>
constexpr move_iterator();
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> <del>Constructs a <tt>move_iterator</tt>, 
v</del><ins>V</ins>alue-initializ<ins>es</ins><del>ing</del> <tt>current</tt>. <del>Iterator operations applied to the
resulting iterator have defined behavior if and only if the corresponding operations are defined on a
value-initialized iterator of type <tt>Iterator</tt>.</del>
</p>
</blockquote>
<pre>
constexpr explicit move_iterator(Iterator i);
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> <del>Constructs a move_iterator, i</del><ins>I</ins>nitializ<ins>es</ins><del>ing</del> 
<tt>current</tt> with <tt>std::move(i)</tt>.
</p>
</blockquote>
<pre>
template&lt;class U&gt; constexpr move_iterator(const move_iterator&lt;U&gt;&amp; u);
</pre>
<blockquote>
<p>
-3- <i>Mandates:</i> <tt><del>U</del><ins>u.base()</ins></tt> is <ins>well-formed and</ins> convertible 
to <tt>Iterator</tt>.
<p/>
-4- <i>Effects:</i> <del>Constructs a <tt>move_iterator</tt>, i</del><ins>I</ins>nitializ<ins>es</ins><del>ing</del> 
<tt>current</tt> with <tt>u.base()</tt>.
</p>
</blockquote>
<pre>
template&lt;class U&gt; constexpr move_iterator&amp; operator=(const move_iterator&lt;U&gt;&amp; u);
</pre>
<blockquote>
<p>
-5- <i>Mandates:</i> <del><tt>U</tt> is convertible to <tt>Iterator</tt></del><ins><tt>u.base()</tt> is 
well-formed and <tt>is_assignable_v&lt;Iterator&amp;, U&gt;</tt> is <tt>true</tt></ins>.
<p/>
-6- <i>Effects:</i> Assigns <tt>u.base()</tt> to <tt>current</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3432" href="https://cplusplus.github.io/LWG/lwg-active.html#3432">3432</a>. Missing requirement for <tt>comparison_category</tt></h3>
<p><b>Section:</b> 21.4.5 <a href="https://wg21.link/string.view.comparison">[string.view.comparison]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-04-19 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p>
It's not clear what happens if a program-defined character traits type
defines <tt>comparison_category</tt> as a synonym for <tt>void</tt>,
or some other bogus type.
</p>
<p>
Discussion on the LWG reflector settled on making it ill-formed at the
point of use.
</p>

<p><i>[2020-07-17; Moved to Ready in telecon]</i></p>



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

<ol>
<li><p>Modify 21.4.5 <a href="https://wg21.link/string.view.comparison">[string.view.comparison]</a> by adding a new paragraph after p3:</p>

<blockquote class="note">
<p>
As result of reflector discussion we decided to make a drive-by fix in p3 below.
</p>
</blockquote>

<blockquote>
<pre>
template&lt;class charT, class traits&gt;
  constexpr <i>see below</i> operator&lt;=&gt;(basic_string_view&lt;charT, traits&gt; lhs,
                                  basic_string_view&lt;charT, traits&gt; rhs) noexcept;
</pre>
<blockquote>
<p>-3- Let <tt>R</tt> denote the type <tt>traits::comparison_category</tt> if <ins>that <i>qualified-id</i>
is valid and denotes a type (13.10.3 <a href="https://wg21.link/temp.deduct">[temp.deduct]</a>)</ins><del>it exists</del>, otherwise <tt>R</tt> 
is <tt>weak_ordering</tt>.</p>

<p><ins>-?- <i>Mandates:</i> <tt>R</tt> denotes a comparison category type (17.11.2 <a href="https://wg21.link/cmp.categories">[cmp.categories]</a>).</ins></p>

<p>-4- <i>Returns:</i> <tt>static_cast&lt;R&gt;(lhs.compare(rhs) &lt;=&gt; 0)</tt>.</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3443" href="https://cplusplus.github.io/LWG/lwg-active.html#3443">3443</a>. [networking.ts] <tt>net::basic_socket_iostream</tt> should use <tt>addressof</tt></h3>
<p><b>Section:</b> 19.2.1 [networking.ts::socket.iostream.cons] <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-05-14 <b>Last modified:</b> 2020-07-17</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#networking.ts::socket.iostream.cons">active issues</a> in [networking.ts::socket.iostream.cons].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#networking.ts::socket.iostream.cons">issues</a> in [networking.ts::socket.iostream.cons].</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: networking.ts</b></p>
<p>
19.2.1 [networking.ts::socket.iostream.cons] uses <tt>&amp;sb_</tt> which could find something bad via ADL.
</p>

<p><i>[2020-07-17; Moved to Ready in telecon]</i></p>

<p>
Jens suggested we should have blanket wording saying that when the library
uses the <tt>&amp;</tt> operator, it means <tt>std::addressof</tt>.
</p>


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

<ol>
<li><p>Modify 19.2.1 [networking.ts::socket.iostream.cons] as indicated:</p>

<blockquote>
<pre>
basic_socket_iostream();
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Initializes the base class as <tt>basic_iostream&lt;char&gt;(<del>&amp;</del><ins>addressof(</ins>sb_<ins>)</ins>)</tt>, value-initializes <tt>sb_</tt>, and performs <tt>setf(std::ios_base::unitbuf)</tt>.
</p>
</blockquote>
<pre>
explicit basic_socket_iostream(basic_stream_socket&lt;protocol_type&gt; s);
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> Initializes the base class as <tt>basic_iostream&lt;char&gt;(<del>&amp;</del><ins>addressof(</ins>sb_<ins>)</ins>)</tt>, 
initializes <tt>sb_</tt> with <tt>std::move(s)</tt>, and performs <tt>setf(std::ios_base::unitbuf)</tt>.
</p>
</blockquote>
<pre>
basic_socket_iostream(basic_socket_iostream&amp;&amp; rhs);
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Move constructs from the rvalue <tt>rhs</tt>. This is accomplished by move constructing the base class, 
and the contained <tt>basic_socket_streambuf</tt>. Next <tt>basic_iostream&lt;char&gt;::set_rdbuf(<del>&amp;</del><ins>addressof(</ins>sb_<ins>)</ins>)</tt> is called to install the contained <tt>basic_socket_streambuf</tt>.
</p>
</blockquote>
<pre>
template&lt;class... Args&gt;
  explicit basic_socket_iostream(Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Initializes the base class as <tt>basic_iostream&lt;char&gt;(<del>&amp;</del><ins>addressof(</ins>sb_<ins>)</ins>)</tt>, 
value-initializes <tt>sb_</tt>, and performs <tt>setf(std::ios_base::unitbuf)</tt>. Then calls 
<tt>rdbuf()-&gt;connect(forward&lt;Args&gt;(args)...)</tt>. If that function returns a null pointer, calls <tt>setstate(failbit)</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3447" href="https://cplusplus.github.io/LWG/lwg-active.html#3447">3447</a>. Deduction guides for <tt>take_view</tt> and <tt>drop_view</tt> have different constraints</h3>
<p><b>Section:</b> 24.7.7.2 <a href="https://wg21.link/range.take.view">[range.take.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2020-05-15 <b>Last modified:</b> 2020-07-17</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.take.view">issues</a> in [range.take.view].</p>
<p><b>Discussion:</b></p>
<p>
From this <a href="https://github.com/cplusplus/draft/issues/3997">editorial issue request</a>:
<p/>
(Note "<tt>range R</tt>" vs "<tt>class R</tt>".)
<p/>
In 24.7.7.2 <a href="https://wg21.link/range.take.view">[range.take.view]</a>, the deduction guide for <tt>take_view</tt> is declared as:
</p>
<blockquote><pre>
template&lt;range R&gt;
  take_view(R&amp;&amp;, range_difference_t&lt;R&gt;)
    -&gt; take_view&lt;views::all_t&lt;R&gt;&gt;;
</pre></blockquote>
<p>
In 24.7.9.2 <a href="https://wg21.link/range.drop.view">[range.drop.view]</a>, the deduction guide for <tt>drop_view</tt> is declared as:
</p>
<blockquote><pre>
template&lt;class R&gt;
  drop_view(R&amp;&amp;, range_difference_t&lt;R&gt;) -&gt; drop_view&lt;views::all_t&lt;R&gt;&gt;;
</pre></blockquote>
<p>
Note the difference between their template parameter lists.
<p/>
Suggested resolution:
<p/>
Change the deduction guide of <tt>take_view</tt> from
</p>
<blockquote><pre>
template&lt;range R&gt;
</pre></blockquote>
<p>
to
</p>
<blockquote><pre>
template&lt;class R&gt;
</pre></blockquote>
<p>
</p>

<p><i>[2020-07-17; Moved to Ready in telecon]</i></p>



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

<ol>
<li><p>Modify 24.7.7.2 <a href="https://wg21.link/range.take.view">[range.take.view]</a>, class template <tt>take_view</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
template&lt;<del>range</del><ins>class</ins> R&gt;
  take_view(R&amp;&amp;, range_difference_t&lt;R&gt;)
    -&gt; take_view&lt;views::all_t&lt;R&gt;&gt;;
[&hellip;]
</pre>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3450" href="https://cplusplus.github.io/LWG/lwg-active.html#3450">3450</a>. The <tt>const</tt> overloads of <tt>take_while_view::begin/end</tt> are underconstrained</h3>
<p><b>Section:</b> 24.7.8.2 <a href="https://wg21.link/range.take.while.view">[range.take.while.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-06-06 <b>Last modified:</b> 2020-07-17</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.take.while.view">issues</a> in [range.take.while.view].</p>
<p><b>Discussion:</b></p>
<p>
The <tt>const</tt> overloads of <tt>take_while_view::begin</tt>
and <tt>take_while_view::end</tt> are underconstrained: they should require
the predicate to model <tt>indirect_unary_predicate&lt;iterator_t&lt;const V&gt;&gt;</tt>.
A simple example is
</p>
<blockquote><pre>
    #include &lt;ranges&gt;

    auto v = std::views::single(1) | std::views::take_while([](int&amp; x) { return true;});
    static_assert(std::ranges::range&lt;decltype(v)&gt;);
    static_assert(std::ranges::range&lt;decltype(v) const&gt;);
    bool b = std::ranges::cbegin(v) == std::ranges::cend(v);
</pre></blockquote>
<p>
Here, the <tt>static_assert</tt>s pass but the comparison fails to compile. The other
views using <tt>indirect_unary_predicate</tt> (<tt>filter_view</tt> and
<tt>drop_while_view</tt>) do not have this problem because they do not support
const-iteration.
</p>

<p><i>[2020-07-17; Moved to Ready in telecon]</i></p>



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

<ol>
<li>
<p>Modify 24.7.8.2 <a href="https://wg21.link/range.take.while.view">[range.take.while.view]</a>, class template <tt>take_while_view</tt> synopsis, as indicated:</p>
<blockquote>
<blockquote>
<pre>
namespace std::ranges {
    template&lt;view V, class Pred&gt;
      requires input_range&lt;V&gt; &amp;&amp; is_object_v&lt;Pred&gt; &amp;&amp;
               indirect_unary_predicate&lt;const Pred, iterator_t&lt;V&gt;&gt;
    class take_while_view : public view_interface&lt;take_while_view&lt;V, Pred&gt;&gt; {
    [&hellip;]

    constexpr auto begin() requires (!<i>simple-view</i>&lt;V&gt;)
    { return ranges::begin(<i>base_</i>); }

    constexpr auto begin() const requires range&lt;const V&gt; <ins>&amp;&amp; indirect_unary_predicate&lt;const Pred, iterator_t&lt;const V&gt;&gt;</ins>
    { return ranges::begin(<i>base_</i>); }

    constexpr auto end() requires (!<i>simple-view</i>&lt;V&gt;)
    { return sentinel&lt;false&gt;(ranges::end(<i>base_</i>), addressof(*<i>pred_</i>)); }

    constexpr auto end() const requires range&lt;const V&gt; <ins>&amp;&amp; indirect_unary_predicate&lt;const Pred, iterator_t&lt;const V&gt;&gt;</ins>
    { return sentinel&lt;true&gt;(ranges::end(<i>base_</i>), addressof(*<i>pred_</i>)); }
    };
}
</pre>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3464" href="https://cplusplus.github.io/LWG/lwg-active.html#3464">3464</a>. <tt>istream::gcount()</tt> can overflow</h3>
<p><b>Section:</b> 29.7.4.4 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-07-10 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>Discussion:</b></p>
<p>
The standard doesn't say what <tt>gcount()</tt> should return if the last unformatted input 
operation extracted more than <tt>numeric_limits&lt;streamsize&gt;::max()</tt> characters. 
This is possible when using <tt>istream::ignore(numeric_limits&lt;streamsize&gt;::max(), delim)</tt>, 
which will keep extracting characters until the delimiter is found. On a 32-bit platform files 
larger than 2GB can overflow the counter, so can a streambuf reading from a network socket, 
or producing random characters.
<p/>
Libstdc++ saturates the counter in <tt>istream::ignore</tt>, so that <tt>gcount()</tt> returns 
<tt>numeric_limits&lt;streamsize&gt;::max()</tt>. Libc++ results in an integer overflow.
<p/>
As far as I'm aware, only <tt>istream::ignore</tt> can extract more than 
<tt>numeric_limits&lt;streamsize&gt;::max()</tt> characters at once. We could either fix it 
in the specification of <tt>ignore</tt>, or in <tt>gcount</tt>.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">

<p>
This wording is relative to <a href="https://wg21.link/n4861">N4861</a>. 
</p>

<b>Option A:</b>
<ol>
<li><p>Modify 29.7.4.4 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> as indicated:</p>

<blockquote>
<pre>
streamsize gcount() const;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> None. This member function does not behave as an unformatted input function (as described
above).
<p/>
-3- <i>Returns:</i> The number of characters extracted by the last unformatted input member function called for
the object. <ins>If the number cannot be represented, returns <tt>numeric_limits&lt;streamsize&gt;::max()</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>

<b>Option B:</b>
<ol>
<li><p>Modify 29.7.4.4 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> as indicated:</p>

<blockquote>
<pre>
basic_istream&lt;charT, traits&gt;&amp; ignore(streamsize n = 1, int_type delim = traits::eof());
</pre>
<blockquote>
<p>
-25- <i>Effects:</i> Behaves as an unformatted input function (as described above). After constructing a sentry
object, extracts characters and discards them. Characters are extracted until any of the following
occurs:
</p>
<ol style="list-style-type: none">
<li><p>(25.1) &mdash; <tt>n != numeric_limits&lt;streamsize&gt;::max()</tt> (17.3.5 <a href="https://wg21.link/numeric.limits">[numeric.limits]</a>) 
and <tt>n</tt> characters have been extracted so far</p></li>
<li><p>(25.2) &mdash; end-of-file occurs on the input sequence (in which case the function calls <tt>setstate(eofbit)</tt>,
which may throw <tt>ios_base::failure</tt> (29.5.5.4 <a href="https://wg21.link/iostate.flags">[iostate.flags]</a>));</p></li>
<li><p>(25.3) &mdash; <tt>traits::eq_int_type(traits::to_int_type(c), delim)</tt> for the next available input 
character <tt>c</tt> (in which case <tt>c</tt> is extracted).</p></li>
</ol>
<p>
<ins>-?- If the number of characters extracted is greater than <tt>numeric_limits&lt;streamsize&gt;::max()</tt> 
then for the purposes of <tt>gcount()</tt> the number is treated as <tt>numeric_limits&lt;streamsize&gt;::max()</tt>.</ins>
<p/>
-26- <i>Remarks:</i> The last condition will never occur if <tt>traits::eq_int_type(delim, traits::eof())</tt>.
<p/>
-27- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>

</blockquote>

<p><i>[2020-07-17; Moved to Ready in telecon]</i></p>

<p>
On the reflector Davis pointed out that there are other
members which can cause <tt>gcount()</tt> to overflow.
There was unanimous agreement on the reflector and the telecon
that Option A is better.
</p>


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

<ol>
<li><p>Modify 29.7.4.4 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> as indicated:</p>

<blockquote>
<pre>
streamsize gcount() const;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> None. This member function does not behave as an unformatted input function (as described
above).
<p/>
-3- <i>Returns:</i> The number of characters extracted by the last unformatted input member function called for
the object. <ins>If the number cannot be represented, returns <tt>numeric_limits&lt;streamsize&gt;::max()</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<h2 id="tentatively_ready">Tentatively Ready Issues</h2>
<p>
These issues were moved to <b>Tentatively Ready</b> since the Prague meeting,
either during LWG teleconferences or following reflector polls.
</p>
<hr>
<h3><a name="2731" href="https://cplusplus.github.io/LWG/lwg-active.html#2731">2731</a>. Existence of <tt>lock_guard&lt;MutexTypes...&gt;::mutex_type</tt> typedef unclear</h3>
<p><b>Section:</b> 32.5.5.2 <a href="https://wg21.link/thread.lock.guard">[thread.lock.guard]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Fiselier <b>Opened:</b> 2016-06-13 <b>Last modified:</b> 2020-05-16</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#thread.lock.guard">issues</a> in [thread.lock.guard].</p>
<p><b>Discussion:</b></p>
<p>
In the synopsis of 32.5.5.3 <a href="https://wg21.link/thread.lock.scoped">[thread.lock.scoped]</a> the <tt>mutex_type</tt> typedef is specified as follows:
</p>
<blockquote>
<pre>
template &lt;class... MutexTypes&gt;
class scoped_lock {
public:
  typedef Mutex mutex_type; <i>// If</i> MutexTypes... <i>consists of the single type</i> Mutex
  [&hellip;]
};
</pre>
</blockquote>
<p>
The comment seems ambiguous as it could mean either:
</p>
<ol>
<li><tt>sizeof...(MutexTypes) == 1</tt>.</li>
<li><tt>sizeof...(MutexTypes) &gt;= 1</tt> and every type in <tt>MutexTypes...</tt> is the same type.</li>
</ol>
<p>
I originally took the language to mean (2), but upon further review it seems that (1) is the intended interpretation, 
as suggested in the LEWG discussion in <a href="http://wiki.edg.com/bin/view/Wg21lenexa/N4470">Lenexa</a>.
<p/>
I think the language should be clarified to prevent implementation divergence.
</p>

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

<p>General feeling that <tt>sizeof(MutexTypes...) == 1</tt> is a better way to state the requirement.</p>
<p>Reworked the text to refer to <tt>scoped_lock</tt> instead of <tt>lock_guard</tt></p>
<p>Marshall and Eric to reword and discuss on reflector. Status to Open</p>

<p><i>[2018-3-14 Wednesday evening issues processing; general agreement to adopt once the wording is updated.]</i></p>

<p>2018-03-18 Marshall provides updated wording.</p>

<strong>Previous resolution: [SUPERSEDED]</strong>
<blockquote class="note">
<p>This wording is relative to N4594.</p>
<ol>
<li><p>Edit 32.5.5.2 <a href="https://wg21.link/thread.lock.guard">[thread.lock.guard]</a>/1, class template <tt>lock_guard</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
template &lt;class... MutexTypes&gt;
class lock_guard {
public:
  typedef Mutex mutex_type; <i>// <ins>Only i</ins><del>I</del>f</i> MutexTypes... <i><del>consists of the</del><ins>expands to a</ins> single type</i> <tt>Mutex</tt>
  [&hellip;]
};
</pre>
</blockquote>
</li>
</ol>
</blockquote>

<strong>Previous resolution: [SUPERSEDED]</strong>
<blockquote class="note">
<p>This wording is relative to N4727.</p>
<ol>
<li><p>Edit 32.5.5.2 <a href="https://wg21.link/thread.lock.guard">[thread.lock.guard]</a>/1, class template <tt>lock_guard</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
template &lt;class... MutexTypes&gt;
class scoped_lock {
public:
  using mutex_type = Mutex; <i>// <ins>Only i</ins><del>I</del>f</i> <ins><tt>sizeof(MutexTypes...) == 1</tt></ins> <del><tt>MutexTypes...</tt> <i>consists of the single type</i> <tt>Mutex</tt></del>
  [&hellip;]
};
</pre>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-05-11; Daniel provides improved wording]</i></p>


<p><i>[2020-05-16 Reflector discussions]</i></p>

<p>Status to Tentatively Ready after five positive votes on the reflector.</p>


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

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

<blockquote>
<blockquote>
<pre>
template &lt;class... MutexTypes&gt;
class scoped_lock {
public:
  <del>using mutex_type = Mutex; <i>// If</i> MutexTypes... <i>consists of the single type</i> Mutex</del>
  <ins>using mutex_type = <i>see below</i>; <i>// Only if </i> sizeof...(MutexTypes) == 1</ins>
  [&hellip;]
};
</pre>
</blockquote>
<p>
-1- An object of type <tt>scoped_lock</tt> controls the ownership of lockable objects within a scope. A 
<tt>scoped_lock</tt> object maintains ownership of lockable objects throughout the <tt>scoped_lock</tt> 
object's lifetime (6.7.3 <a href="https://wg21.link/basic.life">[basic.life]</a>). The behavior of a program is undefined if the lockable 
objects referenced by <tt>pm</tt> do not exist for the entire lifetime of the <tt>scoped_lock</tt> object.
</p>
<ul>
<li><p><del>When</del><ins>If</ins> <tt>sizeof...(MutexTypes)</tt> is <del><tt>1</tt></del><ins>one, let <tt>Mutex</tt> 
denote the sole type constituting the pack <tt>MutexTypes</tt>.</ins><del>, the supplied</del> <tt>Mutex</tt> 
<del>type</del> shall meet the <i>Cpp17BasicLockable</i> requirements (32.2.5.2 <a href="https://wg21.link/thread.req.lockable.basic">[thread.req.lockable.basic]</a>).
<ins>The member <i>typedef-name</i> <tt>mutex_type</tt> denotes the same type as <tt>Mutex</tt>.</ins></p></li>
<li><p>Otherwise, <del>each of the mutex types</del><ins>all types in the template parameter pack <tt>MutexTypes</tt></ins> 
shall meet the <i>Cpp17Lockable</i> requirements (32.2.5.3 <a href="https://wg21.link/thread.req.lockable.req">[thread.req.lockable.req]</a>) <ins>and there is 
no member <tt>mutex_type</tt></ins>.</p></li>
</ul> 
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2743" href="https://cplusplus.github.io/LWG/lwg-active.html#2743">2743</a>. p0083r3 <tt>node_handle</tt> private members missing "exposition only" comment</h3>
<p><b>Section:</b> 22.2.4.1 <a href="https://wg21.link/container.node.overview">[container.node.overview]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2016-07-08 <b>Last modified:</b> 2020-05-16</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#container.node.overview">active issues</a> in [container.node.overview].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#container.node.overview">issues</a> in [container.node.overview].</p>
<p><b>Discussion:</b></p>
<p>
The private members of <tt>node_handle</tt> are missing the usual "exposition only" comment. As a consequence, 
<tt>ptr_</tt> and <tt>alloc_</tt> now appear to be names defined by the library (so programs defining these names 
as macros before including a library header have undefined behavior).
<p/>
Presumably this is unintentional and these members should be considered to be for exposition only.
<p/>
It's also not clear whether the name <tt>node_handle</tt> is reserved for library usage or not; 
22.2.4.1 <a href="https://wg21.link/container.node.overview">[container.node.overview]</a>/3 says the implementation need not provide a type with this name, but 
doesn't seem to rule out the possibility that an implementation will choose to do so regardless.
</p>
<p>
<b>Daniel:</b>
<p/>
A similar problem seems to exist for the exposition-only type <tt><i>call_wrapper</i></tt> from 
<a href="https://wg21.link/p0358r1">p0358r1</a>, which exposes a private data member named <tt>fd</tt> and 
a typedef <tt>FD</tt>.
</p>

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

<p>Jonathan says that we need to make clear that the name <tt>node_handle</tt> is not reserved</p>

<p><i>[2019-03-17; Daniel comments and provides wording]</i></p>

<p>
Due to an editorial step, the previous name <tt>node_handle</tt>/<tt><i>node_handle</i></tt> has been replaced 
by the artificial <tt><i>node-handle</i></tt> name, so I see no longer any reason to talk about a
name <tt>node_handle</tt> reservation. The provided wording therefore only takes care of the private
members.
</p>

<p><i>[2020-05-16 Reflector discussions]</i></p>

<p>Status to Tentatively Ready after five positive votes on the reflector.</p>


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

<ol>
<li><p>Change 22.2.4.1 <a href="https://wg21.link/container.node.overview">[container.node.overview]</a>, exposition-only class template 
<tt><i>node-handle</i></tt> synopsis, as indicated:</p>

<blockquote>
<pre>
template&lt;<i>unspecified</i>&gt;
class <i>node-handle</i> {
public:
  [&hellip;]
private:
  using container_node_type = <i>unspecified</i>; <ins><i>// exposition only</i></ins>
  using ator_traits = allocator_traits&lt;allocator_type&gt;; <ins><i>// exposition only</i></ins>
  typename ator_traits::template rebind_traits&lt;container_node_type&gt;::pointer ptr_; <ins><i>// exposition only</i></ins>
  optional&lt;allocator_type&gt; alloc_; <ins><i>// exposition only</i></ins>

public:
  [&hellip;]
};
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2820" href="https://cplusplus.github.io/LWG/lwg-active.html#2820">2820</a>. Clarify <tt>&lt;cstdint&gt;</tt> macros</h3>
<p><b>Section:</b> 17.4 <a href="https://wg21.link/cstdint">[cstdint]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas K&ouml;ppe <b>Opened:</b> 2016-11-12 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
<p><b>Discussion:</b></p>
<p>
I would like clarification from LWG regarding the various limit macros like <tt>INT_8_MIN</tt> in <tt>&lt;cstdint&gt;</tt>, 
in pursuit of editorial cleanup of this header's synopsis. I have two questions:
</p>
<ol>
<li><p>At present, macros like <tt>INT_8_MIN</tt> that correspond to the optional type <tt>int8_t</tt> are required 
(unconditionally), whereas the underlying type to which they appertain is only optional. Is this deliberate? 
Should the macros also be optional?</p></li>
<li><p>Is it deliberate that C++ only specifies sized aliases for the sizes 8, 16, 32 and 64, whereas the corresponding 
C header allows type aliases and macros for arbitrary sizes for implementations that choose to provide extended integer 
types? Is the C++ wording more restrictive by accident?</p></li>
</ol>

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

<p>Priority 3</p>

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

<p>C11 ties the macro names to the existence of the types. Marshall to research the second question.</p>
<p>Close <a href="https://cplusplus.github.io/LWG/lwg-closed.html#2764">2764</a> as a duplicate of this issue.</p>

<p><i>[2017-03-18, Thomas comments and provides wording]</i></p>

<p>
This is as close as I can get to the C wording without resolving part (a) of the issue (whether we deliberately don't 
allow sized type aliases for sizes other than 8, 16, 32, 64, a departure from C). Once we resolve part (a), we need 
to revisit <tt>&lt;cinttypes&gt;</tt> and fix up the synopsis (perhaps to get rid of <tt>N</tt>) and add similar 
wording as the one below to make the formatting macros for the fixed-width types optional. For historical interest,
this issue is related to LWG <a href="https://cplusplus.github.io/LWG/lwg-closed.html#553">553</a> and LWG <a href="https://cplusplus.github.io/LWG/lwg-closed.html#841">841</a>.
</p>

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

<p>Status to Open</p>

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

<blockquote class="note">
<p>
This wording is relative to <a href="https://wg21.link/n4640">N4640</a>.
</p>

<ol>
<li><p>Append the following content to 17.4.2 <a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a> p2:</p>

<blockquote>
<p>
-2- The header defines all types and macros the same as the C standard library header <tt>&lt;stdint.h&gt;</tt>.
<ins>In particular, for each of the fixed-width types (<tt>int8_t</tt>, <tt>int16_t</tt>, <tt>int32_t</tt>, 
<tt>int64_t</tt>, <tt>uint8_t</tt>, <tt>uint16_t</tt>, <tt>uint32_t</tt>, <tt>uint64_t</tt>) the type alias and 
the corresponding limit macros are defined if and only if the implementation provides the corresponding type.</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2017-10-21, Thomas K&ouml;ppe provides improved wording]</i></p>


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

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

<blockquote>
<pre>
[&hellip;]
using int64_t = <i>signed integer type</i>; <i>// optional</i>
<ins>using int<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using int_fast64_t = <i>signed integer type</i>;
<ins>using int_fast<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using int_least64_t = <i>signed integer type</i>;
<ins>using int_least<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint64_t = <i>unsigned integer type</i>; <i>// optional</i>
<ins>using uint<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint_fast64_t = <i>unsigned integer type</i>;
<ins>using uint_fast<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint_least64_t = <i>unsigned integer type</i>;
<ins>using uint_least<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>

using uintmax_t = <i>unsigned integer type</i>;
using uintptr_t = <i>unsigned integer type</i>; <i>// optional</i>

<ins>#define INT_<i>N</i>_MIN  <i>see below</i>;
#define INT_<i>N</i>_MAX  <i>see below</i>;
#define UINT_<i>N</i>_MAX  <i>see below</i>;

#define INT_FAST<i>N</i>_MIN  <i>see below</i>;
#define INT_FAST<i>N</i>_MAX  <i>see below</i>;
#define UINT_FAST<i>N</i>_MAX  <i>see below</i>;

#define INT_LEAST<i>N</i>_MIN  <i>see below</i>;
#define INT_LEAST<i>N</i>_MAX  <i>see below</i>;
#define UINT_LEAST<i>N</i>_MAX  <i>see below</i>;

#define INTMAX_MIN  <i>see below</i>;
#define INTMAX_MAX  <i>see below</i>;
#define UINTMAX_MAX  <i>see below</i>;

#define INTPTR_MIN  <i>see below</i>;
#define INTPTR_MAX  <i>see below</i>;
#define UINTPTR_MAX  <i>see below</i>;

#define PTRDIFF_MIN  <i>see below</i>;
#define PTRDIFF_MAX  <i>see below</i>;
#define SIZE_MAX  <i>see below</i>;

#define SIGATOMIC_MIN  <i>see below</i>;
#define SIGATOMIC_MAX  <i>see below</i>;

#define WCHAR_MIN  <i>see below</i>;
#define WCHAR_MAX  <i>see below</i>;

#define WINT_MIN  <i>see below</i>;
#define WINT_MAX  <i>see below</i>;

#define INT<i>N</i>_C(value)  <i>see below</i>;
#define UINT<i>N</i>_C(value)  <i>see below</i>;
#define INTMAX_C(value)  <i>see below</i>;
#define UINTMAX_C(value)  <i>see below</i>;</ins>
</pre>
<p>
<del>-1- The header also defines numerous macros of the form:</del>
</p>
<blockquote><pre>
<del>INT_[FAST LEAST]{8 16 32 64}_MIN
[U]INT_[FAST LEAST]{8 16 32 64}_MAX
INT{MAX PTR}_MIN
[U]INT{MAX PTR}_MAX
{PTRDIFF SIG_ATOMIC WCHAR WINT}{_MAX _MIN}
SIZE_MAX</del>
</pre></blockquote>
<p>
<del>plus function macros of the form:</del>
</p>
<blockquote><pre>
<del>[U]INT{8 16 32 64 MAX}_C</del>
</pre></blockquote>
<p>
-2- The header defines all types and macros the same as the C standard library header <tt>&lt;stdint.h&gt;</tt>.
<span style="font-variant: small-caps;">See also</span>: ISO C 7.20
<p/>
<ins>-?- In particular, all types that use the placeholder <tt><i>N</i></tt> are optional when <tt><i>N</i></tt> is not 8, 
16, 32 or 64. The exact-width types <tt>int<i>N</i>_t</tt> and <tt>uint<i>N</i>_t</tt> for <tt><i>N</i></tt> = 8, 16, 32, 64 
are also optional; however, if an implementation provides integer types with the corresponding width, no padding bits, and 
(for the signed types) that have a two's complement representation, it defines the corresponding typedef names. Only 
those macros are defined that correspond to typedef names that the implementation actually provides. [<i>Note:</i> The macros 
<tt>INT<i>N</i>_C</tt> and <tt>UINT<i>N</i>_C</tt> correspond to the typedef names <tt>int_least<i>N</i>_t</tt> and 
<tt>uint_least<i>N</i>_t</tt>, respectively. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</li>

<li><p>Change 29.12.2 <a href="https://wg21.link/cinttypes.syn">[cinttypes.syn]</a> as indicated:</p>

<blockquote><pre>
#define PRId<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIi<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIo<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIu<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIx<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIX<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNd<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNi<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNo<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNu<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNx<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIdLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIiLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIoLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIuLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIxLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIXLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNdLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNiLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNoLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNuLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNxLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIdFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIiFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIoFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIuFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIxFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIXFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNdFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNiFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNoFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNuFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNxFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
[&hellip;]
</pre>
<p>
-1- The contents and meaning of the header <tt>&lt;cinttypes&gt;</tt> [&hellip;]
<p/>
<ins>-?- In particular, macros that use the placeholder <tt><i>N</i></tt> are defined if and only if the implementation 
actually provides the corresponding typedef name in 17.4.2 <a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a>, and moreover, the <tt>fscanf</tt> macros 
are provided unless the implementation does not have a suitable <tt>fscanf</tt> length modifier for the type.</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2018-04-03; Geoffrey Romer suggests improved wording]</i></p>


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

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

<blockquote>
<pre>
[&hellip;]
using int64_t = <i>signed integer type</i>; <i>// optional</i>
<ins>using int<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using int_fast64_t = <i>signed integer type</i>;
<ins>using int_fast<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using int_least64_t = <i>signed integer type</i>;
<ins>using int_least<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint64_t = <i>unsigned integer type</i>; <i>// optional</i>
<ins>using uint<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint_fast64_t = <i>unsigned integer type</i>;
<ins>using uint_fast<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint_least64_t = <i>unsigned integer type</i>;
<ins>using uint_least<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>

using uintmax_t = <i>unsigned integer type</i>;
using uintptr_t = <i>unsigned integer type</i>; <i>// optional</i>

<ins>#define INT_<i>N</i>_MIN  <i>see below</i>;
#define INT_<i>N</i>_MAX  <i>see below</i>;
#define UINT_<i>N</i>_MAX  <i>see below</i>;

#define INT_FAST<i>N</i>_MIN  <i>see below</i>;
#define INT_FAST<i>N</i>_MAX  <i>see below</i>;
#define UINT_FAST<i>N</i>_MAX  <i>see below</i>;

#define INT_LEAST<i>N</i>_MIN  <i>see below</i>;
#define INT_LEAST<i>N</i>_MAX  <i>see below</i>;
#define UINT_LEAST<i>N</i>_MAX  <i>see below</i>;

#define INTMAX_MIN  <i>see below</i>;
#define INTMAX_MAX  <i>see below</i>;
#define UINTMAX_MAX  <i>see below</i>;

#define INTPTR_MIN  <i>see below</i>;
#define INTPTR_MAX  <i>see below</i>;
#define UINTPTR_MAX  <i>see below</i>;

#define PTRDIFF_MIN  <i>see below</i>;
#define PTRDIFF_MAX  <i>see below</i>;
#define SIZE_MAX  <i>see below</i>;

#define SIGATOMIC_MIN  <i>see below</i>;
#define SIGATOMIC_MAX  <i>see below</i>;

#define WCHAR_MIN  <i>see below</i>;
#define WCHAR_MAX  <i>see below</i>;

#define WINT_MIN  <i>see below</i>;
#define WINT_MAX  <i>see below</i>;

#define INT<i>N</i>_C(value)  <i>see below</i>;
#define UINT<i>N</i>_C(value)  <i>see below</i>;
#define INTMAX_C(value)  <i>see below</i>;
#define UINTMAX_C(value)  <i>see below</i>;</ins>
</pre>
<p>
<del>-1- The header also defines numerous macros of the form:</del>
</p>
<blockquote><pre>
<del>INT_[FAST LEAST]{8 16 32 64}_MIN
[U]INT_[FAST LEAST]{8 16 32 64}_MAX
INT{MAX PTR}_MIN
[U]INT{MAX PTR}_MAX
{PTRDIFF SIG_ATOMIC WCHAR WINT}{_MAX _MIN}
SIZE_MAX</del>
</pre></blockquote>
<p>
<del>plus function macros of the form:</del>
</p>
<blockquote><pre>
<del>[U]INT{8 16 32 64 MAX}_C</del>
</pre></blockquote>
<p>
-2- The header defines all types and macros the same as the C standard library header <tt>&lt;stdint.h&gt;</tt>.
<span style="font-variant: small-caps;">See also</span>: ISO C 7.20
<p/>
<ins>-?- In particular, all types that use the placeholder <tt><i>N</i></tt> are optional when <tt><i>N</i></tt> is not 8, 
16, 32 or 64. The exact-width types <tt>int<i>N</i>_t</tt> and <tt>uint<i>N</i>_t</tt> for <tt><i>N</i></tt> = 8, 16, 32, 64 
are also optional; however, if an implementation provides integer types with the corresponding width, no padding bits, and 
(for the signed types) that have a two's complement representation, it defines the corresponding typedef names. Only 
those macros are defined that correspond to typedef names that the implementation actually provides. [<i>Note:</i> The macros 
<tt>INT<i>N</i>_C</tt> and <tt>UINT<i>N</i>_C</tt> correspond to the typedef names <tt>int_least<i>N</i>_t</tt> and 
<tt>uint_least<i>N</i>_t</tt>, respectively. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</li>

<li><p>Change 29.12.2 <a href="https://wg21.link/cinttypes.syn">[cinttypes.syn]</a> as indicated:</p>

<blockquote><pre>
#define PRId<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIi<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIo<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIu<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIx<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIX<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNd<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNi<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNo<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNu<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNx<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIdLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIiLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIoLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIuLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIxLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIXLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNdLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNiLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNoLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNuLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNxLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIdFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIiFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIoFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIuFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIxFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIXFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNdFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNiFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNoFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNuFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNxFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
[&hellip;]
</pre>
<p>
-1- The contents and meaning of the header <tt>&lt;cinttypes&gt;</tt> [&hellip;]
<p/>
<ins>-?- <tt>PRI</tt> macros that use the placeholder <tt><i>N</i></tt> are defined if and only if the implementation actually 
provides the corresponding typedef name in 17.4.2 <a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a>. <tt>SCN</tt> macros that use the placeholder 
<tt><i>N</i></tt> are defined if and only if the implementation actually provides the corresponding typedef name 
and the implementation has a suitable <tt>fscanf</tt> length modifier for the type.</ins>
</p>
</blockquote>
</li>
</ol></blockquote>

<p><i>[2019-03-11; Reflector review and improved wording]</i></p>

<p>
Wording simplifications due to new general two's complement requirements of integer types; removal of wording
redundancies and applying some typo fixes in macro names.
</p>

<p><i>[2019-03-16; Daniel comments and updates wording]</i></p>

<p>
Hubert Tong pointed out that we do not have a statement about <tt>[U]INTPTR_{MIN|MAX}</tt> being optional.
Interestingly, the C11 Standard does not say directly that the <tt>[U]INTPTR_{MIN|MAX}</tt> macros are optional,
but this follows indirectly from the fact that <tt>intptr_t</tt> and <tt>uintptr_t</tt> are indeed optional. 
The updated wording therefore realizes Hubert's suggestion.
<p/>
In addition, the reference document has been rebased to <a href="https://wg21.link/n4810">N4810</a>, because
that draft version contains an <a href="https://github.com/cplusplus/draft/pull/2638">editorial change</a>, 
which renames the term "range exponent" of integer types to "width", which is the vocabulary used below and
also matches C's use.
<p/>
Finally, Hubert Tong suggested the following rewording replacements of
</p>
<blockquote><p>
If and only if the implementation defines such a typedef name, it also defines the corresponding macros.
</p></blockquote>
<p>
to:
</p>
<blockquote><p>
Each of the macros listed in this subclause is defined if and only if the implementation defines the corresponding typedef name.
</p></blockquote>
<p>
and of
</p>
<blockquote><p>
<tt>PRI</tt> macros that use the placeholder N are defined if and only if the implementation actually defines the 
corresponding typedef name in 17.4.2 <a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a>. <tt>SCN</tt> macros that use the placeholder <tt><i>N</i></tt> 
are defined if and only if the implementation actually defines the corresponding typedef name and the implementation 
has a suitable <tt>fscanf</tt> length modifier for the type.
</p></blockquote>
<p>
to:
</p>
<blockquote><p>
Each of the macros listed in this subclause is defined if and only if the implementation actually defines the corresponding 
typedef name in 17.4.2 <a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a>.
</p></blockquote>
<p>
Those changes have been applied as well.
</p>

<p><i>[2019-03-26; Reflector discussion and minor wording update]</i></p>

<p>
Geoffrey pointed out that the revised wording has the effect that it requires an implementation to define <tt>SCN</tt>
macros for all mentioned typedefs, but the C11 standard says "the corresponding <tt>fscanf</tt> macros shall be
defined unless the implementation does not have a suitable <tt>fscanf</tt> length modifier for the type.". An additional 
wording update repairs this problem below.
</p>

<p><i>[2020-02-22; Reflector discussion]</i></p>

<p>
Status set to Tentatively Ready after seven positive votes on the reflector.
</p>


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

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

<blockquote>
<pre>
[&hellip;]
using int64_t = <i>signed integer type</i>; <i>// optional</i>
<ins>using int<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using int_fast64_t = <i>signed integer type</i>;
<ins>using int_fast<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using int_least64_t = <i>signed integer type</i>;
<ins>using int_least<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint64_t = <i>unsigned integer type</i>; <i>// optional</i>
<ins>using uint<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint_fast64_t = <i>unsigned integer type</i>;
<ins>using uint_fast<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>
[&hellip;]
using uint_least64_t = <i>unsigned integer type</i>;
<ins>using uint_least<i>N</i>_t = <i>see below</i>; <i>// optional, see below</i></ins>

using uintmax_t = <i>unsigned integer type</i>;
using uintptr_t = <i>unsigned integer type</i>; <i>// optional</i>

<ins>#define INT<i>N</i>_MIN  <i>see below</i>
#define INT<i>N</i>_MAX  <i>see below</i>
#define UINT<i>N</i>_MAX  <i>see below</i>

#define INT_FAST<i>N</i>_MIN  <i>see below</i>
#define INT_FAST<i>N</i>_MAX  <i>see below</i>
#define UINT_FAST<i>N</i>_MAX  <i>see below</i>

#define INT_LEAST<i>N</i>_MIN  <i>see below</i>
#define INT_LEAST<i>N</i>_MAX  <i>see below</i>
#define UINT_LEAST<i>N</i>_MAX  <i>see below</i>

#define INTMAX_MIN  <i>see below</i>
#define INTMAX_MAX  <i>see below</i>
#define UINTMAX_MAX  <i>see below</i>

#define INTPTR_MIN  <i>optional, see below</i>
#define INTPTR_MAX  <i>optional, see below</i>
#define UINTPTR_MAX  <i>optional, see below</i>

#define PTRDIFF_MIN  <i>see below</i>
#define PTRDIFF_MAX  <i>see below</i>
#define SIZE_MAX  <i>see below</i>

#define SIG_ATOMIC_MIN  <i>see below</i>
#define SIG_ATOMIC_MAX  <i>see below</i>

#define WCHAR_MIN  <i>see below</i>
#define WCHAR_MAX  <i>see below</i>

#define WINT_MIN  <i>see below</i>
#define WINT_MAX  <i>see below</i>

#define INT<i>N</i>_C(value)  <i>see below</i>
#define UINT<i>N</i>_C(value)  <i>see below</i>
#define INTMAX_C(value)  <i>see below</i>
#define UINTMAX_C(value)  <i>see below</i></ins>
</pre>
<p>
<del>-1- The header also defines numerous macros of the form:</del>
</p>
<blockquote><pre>
<del>INT_[FAST LEAST]{8 16 32 64}_MIN
[U]INT_[FAST LEAST]{8 16 32 64}_MAX
INT{MAX PTR}_MIN
[U]INT{MAX PTR}_MAX
{PTRDIFF SIG_ATOMIC WCHAR WINT}{_MAX _MIN}
SIZE_MAX</del>
</pre></blockquote>
<p>
<del>plus function macros of the form:</del>
</p>
<blockquote><pre>
<del>[U]INT{8 16 32 64 MAX}_C</del>
</pre></blockquote>
<p>
-2- The header defines all types and macros the same as the C standard library header <tt>&lt;stdint.h&gt;</tt>.
<span style="font-variant: small-caps;">See also</span>: ISO C 7.20
<p/>
<ins>-?- All types that use the placeholder <tt><i>N</i></tt> are optional when <tt><i>N</i></tt> is not 8, 
16, 32 or 64. The exact-width types <tt>int<i>N</i>_t</tt> and <tt>uint<i>N</i>_t</tt> for <tt><i>N</i></tt> = 8, 16, 32, 64 
are also optional; however, if an implementation defines integer types with the corresponding width and no padding bits, 
it defines the corresponding typedef names. Each of the macros listed in this subclause is defined if and only if 
the implementation defines the corresponding typedef name. [<i>Note:</i> The macros <tt>INT<i>N</i>_C</tt> and 
<tt>UINT<i>N</i>_C</tt> correspond to the typedef names <tt>int_least<i>N</i>_t</tt> and <tt>uint_least<i>N</i>_t</tt>, 
respectively. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</li>

<li><p>Change 29.12.2 <a href="https://wg21.link/cinttypes.syn">[cinttypes.syn]</a> as indicated:</p>

<blockquote><pre>
#define PRId<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIi<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIo<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIu<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIx<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIX<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNd<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNi<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNo<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNu<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNx<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIdLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIiLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIoLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIuLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIxLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIXLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNdLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNiLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNoLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNuLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNxLEAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIdFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIiFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIoFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIuFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIxFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define PRIXFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNdFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNiFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNoFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNuFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
#define SCNxFAST<del>N</del><ins><i>N</i></ins> <i>see below</i>
[&hellip;]
</pre>
<p>
-1- The contents and meaning of the header <tt>&lt;cinttypes&gt;</tt> [&hellip;]
<p/>
<ins>-?- Each of the <tt>PRI</tt> macros listed in this subclause is defined if and only if the implementation defines the 
corresponding typedef name in 17.4.2 <a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a>. Each of the <tt>SCN</tt> macros listed in this subclause is 
defined if and only if the implementation defines the corresponding typedef name in 17.4.2 <a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a> and
has a suitable <tt>fscanf</tt> length modifier for the type.</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3036" href="https://cplusplus.github.io/LWG/lwg-active.html#3036">3036</a>. <tt>polymorphic_allocator::destroy</tt> is extraneous</h3>
<p><b>Section:</b> 20.12.3 <a href="https://wg21.link/mem.poly.allocator.class">[mem.poly.allocator.class]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2017-11-15 <b>Last modified:</b> 2020-10-11</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#mem.poly.allocator.class">issues</a> in [mem.poly.allocator.class].</p>
<p><b>Discussion:</b></p>
<p>
<tt>polymorphic_allocator</tt>'s member function <tt>destroy</tt> is exactly
equivalent to the default implementation of <tt>destroy</tt> in
<tt>allocator_traits</tt> (20.10.9.3 <a href="https://wg21.link/allocator.traits.members">[allocator.traits.members]</a> para 6). It
should be struck from <tt>polymorphic_allocator</tt> as it provides no value.
</p>

<p><i>[28-Nov-2017 Mailing list discussion - set priority to P3]</i></p>

<p>PJ says that Dinkumware is shipping an implementation of <tt>polymorphic_allocator</tt> with <tt>destroy</tt>, so removing it would be a breaking change for him.</p>

<p><i>[2019-02; Kona Wednesday night issue processing]</i></p>

<p>Status to Open; revisit once <a href="https://wg21.link/P0339">P0339</a> lands. Poll taken was 5-3-2 in favor of removal.</p>

<p><i>[2020-10-05; Jonathan provides new wording]</i></p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
Wording relative to <a href="https://wg21.link/n4700">N4700</a>.
</p>

<ol>
<li>
<p>
Strike the declaration of <tt>destroy</tt> from the synopsis of class
<tt>polymorphic_allocator</tt> in 20.12.3 <a href="https://wg21.link/mem.poly.allocator.class">[mem.poly.allocator.class]</a>:
</p>
<blockquote>
<pre>
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);

<del>template &lt;class T&gt;</del>
  <del>void destroy(T* p);</del>

polymorphic_allocator select_on_container_copy_construction() const;
</pre>
</blockquote>
</li>

<li>
<p>
Strike the specification of <tt>destroy</tt> in 20.12.3.3 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a>:
</p>
<blockquote>
[&hellip;]

<pre>
<del>template &lt;class T&gt;</del>
  <del>void destroy(T* p);</del>
</pre>

<p><del>14 Effects: As if by <tt>p->~T()</tt>.</del></p>

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

<p><i>[2020-10-11; Reflector poll]</i></p>

<p>
Moved to Tentatively Ready after seven votes in favour.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Wording relative to <a href="https://wg21.link/n4861">N4861</a>.
</p>

<ol>
<li>
<p>
Strike the declaration of <tt>destroy</tt> from the synopsis of class
<tt>polymorphic_allocator</tt> in 20.12.3 <a href="https://wg21.link/mem.poly.allocator.class">[mem.poly.allocator.class]</a>:
</p>
<blockquote>
<pre>
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);

<del>template &lt;class T&gt;</del>
  <del>void destroy(T* p);</del>

polymorphic_allocator select_on_container_copy_construction() const;
</pre>
</blockquote>
</li>

<li>
<p>
Adjust the specification of <tt>delete_object</tt> in 20.12.3.3 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a>:
</p>
<blockquote>
<pre>
template &lt;class T&gt;
  void delete_object(T* p);
</pre>

<p>-13- Effects: Equivalent to:</p>
<blockquote><pre>
  <ins>allocator_traits&lt;polymorphic_allocator&gt;::</ins>destroy(<ins>*this, </ins>p);
  deallocate_object(p);
</pre></blockquote>
</blockquote>
</li>

<li>
<p>
Strike the specification of <tt>destroy</tt> in 20.12.3.3 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a>:
</p>
<blockquote>
[&hellip;]

<pre>
<del>template &lt;class T&gt;</del>
  <del>void destroy(T* p);</del>
</pre>

<p><del>-17- Effects: As if by <tt>p->~T()</tt>.</del></p>

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

<li>
<p>Add a new subclause to Annex D:</p>
<blockquote>
<p>
<ins>
<strong>D.?? Deprecated <tt>polymorphic_allocator</tt> member function</strong>
</ins>
</p>
<p>
<ins>
-1- The following member is declared in addition to those members specified in
20.12.3.3 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a>:
</ins>
</p>
<blockquote><pre><ins>
namespace std::pmr {
  template&lt;class Tp = byte&gt;
  class polymorphic_allocator {
  public:
    template &lt;class T&gt;
      void destroy(T* p);
  };
}
</ins></pre></blockquote>
<pre><ins>
template &lt;class T&gt;
  void destroy(T* p);
</ins></pre>
<p><ins>-1- Effects: As if by <tt>p->~T()</tt>.</ins></p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3120" href="https://cplusplus.github.io/LWG/lwg-active.html#3120">3120</a>. Unclear behavior of <tt>monotonic_buffer_resource::release()</tt></h3>
<p><b>Section:</b> 20.12.6.3 <a href="https://wg21.link/mem.res.monotonic.buffer.mem">[mem.res.monotonic.buffer.mem]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Arthur O'Dwyer <b>Opened:</b> 2018-06-10 <b>Last modified:</b> 2020-10-06</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#mem.res.monotonic.buffer.mem">issues</a> in [mem.res.monotonic.buffer.mem].</p>
<p><b>Discussion:</b></p>
<p>
The effects of <tt>monotonic_buffer_resource::release()</tt> are defined as:
</p>
<blockquote>
<p>
Calls <tt>upstream_rsrc-&gt;deallocate()</tt> as necessary to release all allocated memory.
</p>
</blockquote>
<p>
This doesn't give any instruction on what to do with the memory controlled by the <tt>monotonic_buffer_resource</tt> which 
was not allocated, i.e., what to do with the initial buffer provided to its constructor.
<p/>
Boost.Container's pmr implementation expels its initial buffer after a <tt>release()</tt>.
Arthur O'Dwyer's proposed pmr implementation for libc++ reuses the initial buffer after a <tt>release()</tt>, on the 
assumption that this is what the average library user will be expecting.
</p>
<blockquote>
<pre>
#include &lt;memory_resource&gt;

int main() 
{
  char buffer[100];
  {
    std::pmr::monotonic_buffer_resource mr(buffer, 100, std::pmr::null_memory_resource());
    mr.release();
    mr.allocate(60);  // A
  }
  {
    std::pmr::monotonic_buffer_resource mr(buffer, 100, std::pmr::null_memory_resource());
    mr.allocate(60);  // B
    mr.release();
    mr.allocate(60);  // C
  }
}
</pre>
</blockquote>
<p>
Assume that allocation "B" always succeeds.<br/>
With the proposed libc++ implementation, allocations "A" and "C" both succeed.<br/>
With Boost.Container's implementation, allocations "A" and "C" both fail.<br/>
Using another plausible implementation strategy, allocation "A" could succeed but allocation "C" 
could fail. I have been informed that MSVC's implementation does this.
<p/>
Which of these strategies should be permitted by the Standard?
<p/>
Arthur considers "A and C both succeed" to be the obviously most user-friendly strategy, and really 
really hopes it's going to be permitted. Requiring "C" to succeed is unnecessary (and would render MSVC's 
current implementation non-conforming) but could help programmers concerned with portability between 
different implementations.
<p/>
Another side-effect of <tt>release()</tt> which goes underspecified by the Standard is the effect of 
<tt>release()</tt> on <tt>next_buffer_size</tt>. As currently written, my interpretation is that 
<tt>release()</tt> is not permitted to decrease <tt>current_buffer_size</tt>; I'm not sure if this 
is a feature or a bug.
<p/>
Consider this test case (taken from <a href="https://reviews.llvm.org/D47111#inline-421469">here</a>):
</p>
<blockquote>
<pre>
std::pmr::monotonic_buffer_resource mr(std::pmr::new_delete_resource());
for (int i=0; i &lt; 100; ++i) {
  mr.allocate(1);  // D
  mr.release();
}
</pre>
</blockquote>
<p>
Arthur believes it is important that the 100<sup>th</sup> invocation of line "D" does not attempt to allocate 
2<sup>100</sup> bytes from the upstream resource.
</p>

<p><i>[2018-06-23 after reflector discussion]</i></p>

<p>Priority set to 2</p>

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> The resolution depicted below would make MSVC's and my-proposed-libc++'s implementations 
both conforming.]</p>
</blockquote>

<ol>
<li><p>Modify 20.12.6.3 <a href="https://wg21.link/mem.res.monotonic.buffer.mem">[mem.res.monotonic.buffer.mem]</a> as indicated:</p>
<blockquote>
<pre>
void release();
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Calls <tt>upstream_rsrc-&gt;deallocate()</tt> as necessary to release all allocated memory. 
<ins>Resets the state of the initial buffer.</ins>
<p/>
-2- [<i>Note:</i> The memory is released back to <tt>upstream_rsrc</tt> even if some blocks that were allocated from
this have not been deallocated from this. <ins>This function has an unspecified effect on <tt>next_buffer_size</tt>.</ins> 
&mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2018-08-23 Batavia Issues processing]</i></p>

<p>We liked Pablo's wording from the reflector discussion. Status to Open.</p>

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

<ol>
<li><p>Modify 20.12.6.3 <a href="https://wg21.link/mem.res.monotonic.buffer.mem">[mem.res.monotonic.buffer.mem]</a> as indicated:</p>
<blockquote>
<pre>
void release();
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Calls <tt>upstream_rsrc-&gt;deallocate()</tt> as necessary to release all allocated memory. 
<ins>Resets <tt>*this</tt> to its initial state at construction.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-10-03; Daniel comments and provides improved wording]</i></p>

<p>
The recent wording introduces the very generic term "state" without giving a concrete
definition of that term. During reflector discussions different interpretations of that term
were expressed. The revised wording below gets rid of that word and replaces it by the
actually involved exposition-only members.
</p>

<p><i>[2020-10-06; moved to Tentatively Ready after seven votes in favour in reflector poll]</i></p>



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

<ol>
<li><p>Modify 20.12.6.3 <a href="https://wg21.link/mem.res.monotonic.buffer.mem">[mem.res.monotonic.buffer.mem]</a> as indicated:</p>
<blockquote>
<pre>
void release();
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Calls <tt>upstream_rsrc-&gt;deallocate()</tt> as necessary to release all allocated memory. 
<ins>Resets <tt>current_buffer</tt> and <tt>next_buffer_size</tt> to their initial values at construction.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3170" href="https://cplusplus.github.io/LWG/lwg-active.html#3170">3170</a>. <tt>is_always_equal</tt> added to <tt>std::allocator</tt> makes the standard library treat 
derived types as always equal</h3>
<p><b>Section:</b> 20.10.10 <a href="https://wg21.link/default.allocator">[default.allocator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2018-11-29 <b>Last modified:</b> 2020-10-02</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#default.allocator">issues</a> in [default.allocator].</p>
<p><b>Discussion:</b></p>
<p>
I (Billy O'Neal) attempted to change MSVC++'s standard library to avoid instantiating allocators' <tt>operator==</tt> 
for allocators that are declared <tt>is_always_equal</tt> to reduce the number of template instantiations emitted into .objs.
<p/>
In so doing I introduced an unrelated bug related to POCMA handling, but it brought my attention to 
<a href="https://github.com/boostorg/poly_collection/blob/5ed5d5e99336130783bdb33126d8629890235aed/test/test_utilities.hpp#L324">this 
allocator</a>. This allocator doesn't meet the allocator requirements because it is getting <tt>std::allocator</tt>'s 
<tt>operator==</tt> and <tt>operator!=</tt> which don't compare the root member. However, if this had been a conforming C++14 
allocator with its own <tt>==</tt> and <tt>!=</tt> we would still be treating it as <tt>is_always_equal</tt>, as it picks that 
up by deriving from <tt>std::allocator</tt>.
<p/>
<tt>std::allocator</tt> doesn't actually need <tt>is_always_equal</tt> because the defaults provided by <tt>allocator_traits</tt> 
will say <tt>true_type</tt> for it, since implementers don't make <tt>std::allocator</tt> stateful.
<p/>
Billy O'Neal thinks this is NAD on the grounds that we need to be able to add things or change the behavior of standard library types.
<p/>
Stephan T Lavavej thinks we should resolve this anyway because we don't know of an implementation for which this would change 
the default answer provided by <tt>allocator_traits</tt>.
</p>

<p><i>[2019-02 Priority set to 2 after reflector discussion]</i></p>


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

<ol>
<li><p>Modify 20.10.10 <a href="https://wg21.link/default.allocator">[default.allocator]</a> as follows:</p>

<blockquote>
<p>
-1- All specializations of the default allocator satisfy the allocator completeness requirements (16.4.4.6.2 <a href="https://wg21.link/allocator.requirements.completeness">[allocator.requirements.completeness]</a>).
</p>
<pre>
namespace std {
  template&lt;class T&gt; class allocator {
  public:
    using value_type = T;
    using size_type = size_t;
    using difference_type = ptrdiff_t;
    using propagate_on_container_move_assignment = true_type;
    <del>using is_always_equal = true_type;</del>
    constexpr allocator() noexcept;
    constexpr allocator(const allocator&amp;) noexcept;
    template&lt;class U&gt; constexpr allocator(const allocator&lt;U&gt;&amp;) noexcept;
    ~allocator();
    allocator&amp; operator=(const allocator&amp;) = default;
    [[nodiscard]] T* allocate(size_t n);
    void deallocate(T* p, size_t n);
  };
}
</pre>
<p>
<ins>-?- <tt>allocator_traits&lt;allocator&lt;T&gt;&gt;::is_always_equal::value</tt> is <tt>true</tt> for any <tt>T</tt>.</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2019-07 Cologne]</i></p>

<p>
Jonathan provides updated wording.
</p>

<p><i>[2020-10-02; Issue processing telecon: Moved to Tentatively Ready.]</i></p>




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

<ol>
<li><p>Modify 20.10.10 <a href="https://wg21.link/default.allocator">[default.allocator]</a> as follows:</p>

<blockquote>
<p>
-1- All specializations of the default allocator satisfy the allocator completeness requirements (16.4.4.6.2 <a href="https://wg21.link/allocator.requirements.completeness">[allocator.requirements.completeness]</a>).
</p>
<pre>
namespace std {
  template&lt;class T&gt; class allocator {
  public:
    using value_type = T;
    using size_type = size_t;
    using difference_type = ptrdiff_t;
    using propagate_on_container_move_assignment = true_type;
    <del>using is_always_equal = true_type;</del>
    constexpr allocator() noexcept;
    constexpr allocator(const allocator&amp;) noexcept;
    template&lt;class U&gt; constexpr allocator(const allocator&lt;U&gt;&amp;) noexcept;
    ~allocator();
    allocator&amp; operator=(const allocator&amp;) = default;
    [[nodiscard]] T* allocate(size_t n);
    void deallocate(T* p, size_t n);
  };
}
</pre>
<p>
<ins>-?- <tt>allocator_traits&lt;allocator&lt;T&gt;&gt;::is_always_equal::value</tt> is <tt>true</tt> for any <tt>T</tt>.</ins>
</p>
</blockquote>
</li>

<li><p>Add a new subclause in Annex D after D.13 <a href="https://wg21.link/depr.str.strstreams">[depr.str.strstreams]</a>:</p>

<blockquote>
<p>
<b><ins>D.? The default allocator  [depr.default.allocator]</ins></b>
<p/>
<ins>-?- The following member is defined in addition to those specified in 20.10.10 <a href="https://wg21.link/default.allocator">[default.allocator]</a>:</ins>
</p>
<pre>
<ins>namespace std {
  template &lt;class T&gt; class allocator {
  public:
    using is_always_equal = true_type;
  };
}</ins>
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3171" href="https://cplusplus.github.io/LWG/lwg-active.html#3171">3171</a>. LWG 2989 breaks <tt>directory_entry</tt> stream insertion</h3>
<p><b>Section:</b> 29.11.10 <a href="https://wg21.link/fs.class.directory.entry">[fs.class.directory.entry]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2018-12-03 <b>Last modified:</b> 2020-08-21</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#fs.class.directory.entry">active issues</a> in [fs.class.directory.entry].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#fs.class.directory.entry">issues</a> in [fs.class.directory.entry].</p>
<p><b>Discussion:</b></p>
<p>
<tt>directory_entry</tt> has a conversion function to <tt>const path&amp;</tt> and depends on <tt>path</tt>'s stream insertion 
operator for stream insertion support, which is now broken after LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2989">2989</a> made it a hidden friend.
<p/>
This does not appear to be intended.
</p>

<p><i>[2018-12-21 Reflector prioritization]</i></p>

<p>Set Priority to 2</p>
<p><i>[2019-02; Kona Wednesday night issue processing]</i></p>

<p>Status to Open; Marshall to move definition inline and re-vote on reflector.</p>
<p>Jonathan to write a paper about how to specify "hidden friends".</p>

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

<ol>
<li><p>Modify  [fs.class.directory_entry], class <tt>directory_entry</tt> synopsis, as follows:</p>

<blockquote>
<pre>
namespace std::filesystem {
  class directory_entry {
  public:
    [&hellip;]
  private:
    filesystem::path pathobject;     // exposition only
    friend class directory_iterator; // exposition only

<ins>    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 directory_entry&amp; d);</ins>
  };
}
</pre>
</blockquote>
</li>
<li>
<p>Add a new subclause at the end of  [fs.class.directory_entry], as follows:</p>
<blockquote>
<p><strong>28.11.11.4 Inserter [fs.dir.entry.io]</strong></p>
<blockquote>
<pre>
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 directory_entry&amp; d);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to: <tt> return os &lt;&lt; d.path(); </tt>
</p>
</blockquote>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-05-02; Daniel resyncs wording with recent working draft and comments]</i></p>

<p>
We have now the paper <a href="https://wg21.link/p1965r0">P1965R0</a>, which introduced
a specification of what friend functions in the library specification (see 
16.4.6.6 <a href="https://wg21.link/hidden.friends">[hidden.friends]</a>) are supposed to mean, there is no longer an inline
definition needed to clarify the meaning. In addition to updating the change of section
names the provided wording has moved the friend declaration into the public part of the
class definition as have done in all other cases where we take advantage of "hidden friends"
declarations.
</p>
<p><i>[2020-08-21 Issue processing telecon: moved to Tentatively Ready]</i></p>



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

<ol>
<li><p>Modify 29.11.10 <a href="https://wg21.link/fs.class.directory.entry">[fs.class.directory.entry]</a>, class <tt>directory_entry</tt> synopsis, as follows:</p>

<blockquote>
<pre>
namespace std::filesystem {
  class directory_entry {
  public:
    [&hellip;]
    bool operator==(const directory_entry&amp; rhs) const noexcept;
    strong_ordering operator&lt;=&gt;(const directory_entry&amp; rhs) const noexcept;
    
    <ins><i>// 29.11.11.? [fs.dir.entry.io], inserter</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 directory_entry&amp; d);</ins>
  private:
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

<li>
<p>Add a new subclause at the end of 29.11.10 <a href="https://wg21.link/fs.class.directory.entry">[fs.class.directory.entry]</a>, as indicated:</p>

<blockquote>
<p><strong><ins>29.11.11.? Inserter [fs.dir.entry.io]</ins></strong></p>
<blockquote>
<pre>
<ins>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 directory_entry&amp; d);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> Equivalent to: <tt>return os &lt;&lt; d.path();</tt></ins>
</p>
</blockquote>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3306" href="https://cplusplus.github.io/LWG/lwg-active.html#3306">3306</a>. <tt>ranges::advance</tt> violates its preconditions</h3>
<p><b>Section:</b> 23.4.4.2 <a href="https://wg21.link/range.iter.op.advance">[range.iter.op.advance]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-10-27 <b>Last modified:</b> 2020-08-21</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.iter.op.advance">active issues</a> in [range.iter.op.advance].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.iter.op.advance">issues</a> in [range.iter.op.advance].</p>
<p><b>Discussion:</b></p>
<p>Recall that "<tt>[i, s)</tt> denotes a range" for an iterator <tt>i</tt> and sentinel <tt>s</tt>
means that either <tt>i == s</tt> holds, or <tt>i</tt> is dereferenceable and <tt>[++i, s)</tt>
denotes a range ( [iterator.requirements.genera]).
</p><p>
The three-argument overload <tt>ranges::advance(i, n, bound)</tt> is specified in
23.4.4.2 <a href="https://wg21.link/range.iter.op.advance">[range.iter.op.advance]</a> paragraphs 5 through 7. Para 5 establishes a precondition that
<tt>[bound, i)</tt> denotes a range when <tt>n &lt; 0</tt> (both <tt>bound</tt> and <tt>i</tt> must
have the same type in this case). When <tt>sized_sentinel_for&lt;S, I&gt;</tt> holds and
<tt>n &lt; bound - i</tt>, para 6.1.1 says that <tt>ranges::advance(i, n, bound)</tt> is equivalent
to <tt>ranges::advance(i, bound)</tt>. Para 3, however, establishes a precondition for
<tt>ranges::advance(i, bound)</tt> that <tt>[i, bound)</tt> denotes a range. <tt>[bound, i)</tt> and
<tt>[i, bound)</tt> cannot both denote ranges unless <tt>i == bound</tt>, which is not the case for
all calls that reach 6.1.1.
</p><p>
The call in para 6.1.1 wants the effects of either 4.1 - which really has no preconditions - or 4.2,
which is well-defined if either <tt>[i, bound)</tt> or <tt>[bound, i)</tt> denotes a range. Para 3's
stronger precondition is actually only required by Para 4.3, which increments <tt>i</tt> blindly
looking for <tt>bound</tt>. The straight-forward fix here seems to be to relax para 3's precondition
to only apply when 4.3 will be reached.
</p>

<p><i>[2019-11 Priority to 2 during Monday issue prioritization in Belfast]</i></p>


<p><i>[2020-08-21 Issue processing telecon: moved to Tentatively Ready]</i></p>



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

<ol>
<li><p>Modify 23.4.4.2 <a href="https://wg21.link/range.iter.op.advance">[range.iter.op.advance]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
  constexpr void ranges::advance(I&amp; i, S bound);
</pre>
<p>
-3- <i>Expects:</i> <ins>Either <tt>assignable_from&lt;I&amp;, S&gt; ||
sized_sentinel_for&lt;S, I&gt;</tt> is modeled, or</ins> <tt>[i, bound)</tt> denotes a range.
</p><p>
-4- <i>Effects:</i>
</p><p>
(4.1) &mdash; If <tt>I</tt> and <tt>S</tt> model <tt>assignable_from&lt;I&amp;, S&gt;</tt>,
equivalent to <tt>i = std::move(bound)</tt>.
</p><p>
(4.2) &mdash; Otherwise, if <tt>S</tt> and <tt>I</tt> model <tt>sized_sentinel_for&lt;S, I&gt;</tt>,
equivalent to <tt>ranges::advance(i, bound - i)</tt>.
</p><p>
(4.3) &mdash; Otherwise, while <tt>bool(i != bound)</tt> is <tt>true</tt>, increments <tt>i</tt>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3368" href="https://cplusplus.github.io/LWG/lwg-active.html#3368">3368</a>. Exactly when does <tt>size</tt> return <tt>end - begin</tt>?</h3>
<p><b>Section:</b> 24.3.10 <a href="https://wg21.link/range.prim.size">[range.prim.size]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-01-07 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p>
The specification of <tt>ranges::size</tt> in 24.3.10 <a href="https://wg21.link/range.prim.size">[range.prim.size]</a> suggests that bullet 1.3 
("Otherwise, <tt><i>make-unsigned-like</i>(ranges::end(E) - ranges::begin(E)) ...")</tt> only applies 
when <tt>disable_sized_range&lt;remove_cv_t&lt;T&gt;&gt;</tt> is <tt>true</tt>. This is not the 
design intent, but the result of an erroneous attempt to factor out the common 
"<tt>disable_sized_range</tt> is <tt>false</tt>" requirement from the member and non-member <tt>size</tt> 
cases in bullets 1.2.1 and 1.2.2 that occurred between <a href="https://wg21.link/p0896r3">P0896R3</a> and 
<a href="https://wg21.link/p0896r4">P0896R4</a>. The intended design has always been that a range with 
member or non-member <tt>size</tt> with the same syntax but different semantics may opt-out of being 
sized by specializing <tt>disable_sized_range</tt>. It has never been intended that arrays or ranges 
whose iterator and sentinel model <tt>sized_sentinel_for</tt> be able to opt out of being sized via 
<tt>disable_sized_range</tt>. <tt>disable_sized_sentinel_for</tt> can/must be used to opt out in the 
latter case so that library functions oblivious to the range type that operate on the iterator and 
sentinel of such a range will avoid subtraction.
</p>

<p><i>[2020-01-25 Status set to Tentatively Ready after six positive votes on the reflector.]</i></p>



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

<ol>
<li><p>Modify 24.3.10 <a href="https://wg21.link/range.prim.size">[range.prim.size]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> There are drive-by changes here to (1) avoid introducing unused type placeholders, 
(2) avoid reusing "<tt>T</tt>" as both the type of the subexpression and the template parameter of the 
poison pill, and (3) fix the cross-reference for <tt><i>make-unsigned-like</i></tt> which is defined in 
[ranges.syn]/1, not in [range.subrange].]
</p>
</blockquote>

<blockquote>
<p>
-1- The name <tt>size</tt> denotes a customization point object (16.3.3.3.6 <a href="https://wg21.link/customization.point.object">[customization.point.object]</a>). 
The expression <tt>ranges::size(E)</tt> for some subexpression <tt>E</tt> with type <tt>T</tt> is 
expression-equivalent to:
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <tt><i>decay-copy</i>(extent_v&lt;T&gt;)</tt> if <tt>T</tt> is an array type 
(6.8.3 <a href="https://wg21.link/basic.compound">[basic.compound]</a>).</p></li>
<li><p><del>(1.2) &mdash; Otherwise, if <tt>disable_sized_range&lt;remove_cv_t&lt;T&gt;&gt;</tt> 
(24.4.3 <a href="https://wg21.link/range.sized">[range.sized]</a>) is <tt>false</tt>:</del></p>
<li><p>(1.<ins>?</ins><del>2.1</del>) &mdash; <ins>Otherwise, if 
<tt>disable_sized_range&lt;remove_cv_t&lt;T&gt;&gt;</tt> (24.4.3 <a href="https://wg21.link/range.sized">[range.sized]</a>) is <tt>false</tt> 
and</ins> <tt><i>decay-copy</i>(E.size())</tt> <del>if it</del> is a valid expression <del>and its 
type <tt>I</tt> is</del><ins>of</ins> integer-like <ins>type</ins> 
(23.3.4.4 <a href="https://wg21.link/iterator.concept.winc">[iterator.concept.winc]</a>)<ins>, <tt><i>decay-copy</i>(E.size())</tt></ins>.</p></li>
<li><p>(1.<ins>?</ins><del>2.2</del>) &mdash; Otherwise, <ins>if 
<tt>disable_sized_range&lt;remove_cv_t&lt;T&gt;&gt;</tt> is <tt>false</tt> and</ins>
<tt><i>decay-copy</i>(size(E))</tt> <del>if it</del> is a valid expression <del>and its type 
<tt>I</tt> is</del><ins>of</ins> integer-like <ins>type</ins> with overload resolution performed in a 
context that includes the declaration:
<blockquote><pre>
<del>template&lt;class T&gt;</del> void size(<del>T</del><ins>auto</ins>&amp;&amp;) = delete;
</pre></blockquote>
and does not include a declaration of <tt>ranges::size</tt><ins>, <tt><i>decay-copy</i>(size(E))</tt></ins>.</p></li>
</li>
<li><p>(1.3) &mdash; Otherwise, <tt><i>make-unsigned-like</i>(ranges::end(E) - ranges::begin(E))</tt> 
(<del>24.5.4 <a href="https://wg21.link/range.subrange">[range.subrange]</a></del><ins>24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a></ins>) if it is a valid 
expression and the types <tt>I</tt> and <tt>S</tt> of 
<tt>ranges::begin(E)</tt> and <tt>ranges::end(E)</tt> (respectively) model both
<tt>sized_sentinel_for&lt;S, I&gt;</tt> (23.3.4.8 <a href="https://wg21.link/iterator.concept.sizedsentinel">[iterator.concept.sizedsentinel]</a>) and 
<tt>forward_iterator&lt;I&gt;</tt>. However, <tt>E</tt> is evaluated only once.
</p></li>
<li><p>(1.4) &mdash; [&hellip;]</p></li>
</ol>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3403" href="https://cplusplus.github.io/LWG/lwg-active.html#3403">3403</a>. Domain of <tt>ranges::ssize(E)</tt> doesn't match <tt>ranges::size(E)</tt></h3>
<p><b>Section:</b> 24.3.11 <a href="https://wg21.link/range.prim.ssize">[range.prim.ssize]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-02-19 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
<tt>ranges::size(E)</tt> works with a non-range for which <tt>E.size()</tt> or <tt>size(E)</tt> is valid.
But <tt>ranges::ssize(E)</tt> requires the type <tt>range_difference_t</tt> which requires
<tt>ranges::begin(E)</tt> to be valid. This means there are types for which <tt>ranges::size(E)</tt>
is valid but <tt>ranges::ssize(E)</tt> is not.
<p/>
Casey's reaction to this is:
<p/>
I believe we want <tt>ranges::ssize</tt> to work with any argument that <tt>ranges::size</tt> accepts.
That suggest to me that we're going to need <tt><i>make-signed-like-t</i>&lt;T&gt;</tt> after all,
so we can "Let <tt>E</tt> be an expression, and let <tt>D</tt> be the wider of <tt>ptrdiff_t</tt>
or <tt>decltype(ranges::size(E))</tt>. Then <tt>ranges::ssize(E)</tt> is expression-equivalent to
<tt>static_cast&lt;<i>make-signed-like-t</i>&lt;D&gt;&gt;(ranges::size(E))</tt>." Although this wording
is still slightly icky since <tt>D</tt> isn't a valid type when <tt>ranges::size(E)</tt> isn't a valid
expression, I think it's an improvement?
</p>

<p><i>[2020-03-11 Issue Prioritization]</i></p>

<p>Priority to 2 after reflector discussion.</p>

<p><i>[2020-07-22 Casey provides wording]</i></p>


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

<ol>
<li><p>Add a new paragraph after paragraph 1 in 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>:</p>
<blockquote>
<ins>
-?- Also within this clause,
<tt><i>make-signed-like-t</i>&lt;X&gt;</tt>
for an integer-like type <tt>X</tt>
denotes <tt>make_signed_t&lt;X&gt;</tt>
if <tt>X</tt> is an integer type;
otherwise, it denotes a corresponding
unspecified signed-integer-like type
of the same width as <tt>X</tt>.
</ins>
</blockquote>
</li>

<li><p>Modify 24.3.11 <a href="https://wg21.link/range.prim.ssize">[range.prim.ssize]</a> as indicated:</p>

<blockquote>
<p>-1- The name <tt>ranges::ssize</tt> denotes
a customization point object (16.3.3.3.6 <a href="https://wg21.link/customization.point.object">[customization.point.object]</a>).
<del>The expression <tt>ranges::ssize(E)</tt>
for a subexpression <tt>E</tt> of type <tt>T</tt>
is expression-equivalent to:</del>
</p><p>
<del>(1.1) &mdash; If <tt>range_difference_t&lt;T&gt;</tt> has
width less than <tt>ptrdiff_t</tt>,
<tt>static_cast&lt;ptrdiff_t&gt;(ranges::size(E))</tt>.</del>
</p><p>
<del>(1.2) &mdash; Otherwise,
<tt>static_cast&lt;range_difference_t&lt;T&gt;&gt;(ranges::size(E))</tt>.</del>
</p><p>
<ins>
-?- Given a subexpression <tt>E</tt> with type <tt>T</tt>,
let <tt>t</tt> be an lvalue that denotes the reified object for <tt>E</tt>.
If <tt>ranges::size(t)</tt> is ill-formed,
<tt>ranges::ssize(E)</tt> is ill-formed.
Otherwise, let <tt>D</tt> be the wider of
<tt>ptrdiff_t</tt> or <tt>decltype(ranges::size(t))</tt>;
<tt>ranges::ssize(E)</tt> is expression-equivalent to
<tt>static_cast&lt;<i>make-signed-like-t</i>&lt;D&gt;&gt;(ranges::size(t))</tt>.
</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-07-31 Casey provides updated wording]</i></p>

Per discussion on the reflector.

<p><i>[2020-08-21; Issue processing telecon: Tentatively Ready]</i></p>



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

<ol>
<li><p>Add a new paragraph after paragraph 1 in 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>:</p>
<blockquote class="note">
<p>
[<i>Drafting note:</i> The following does not define
an analog <tt><i>to-signed-like</i></tt> for <tt><i>to-unsigned-like</i></tt>
since we don't need it at this time.]
</p>
</blockquote>
<blockquote>
<ins>
-?- Also within this Clause,
<tt><i>make-signed-like-t</i>&lt;X&gt;</tt>
for an integer-like type <tt>X</tt>
denotes <tt>make_signed_t&lt;X&gt;</tt>
if <tt>X</tt> is an integer type;
otherwise, it denotes a corresponding
unspecified signed-integer-like type
of the same width as <tt>X</tt>.
</ins>
</blockquote>
</li>

<li><p>Modify 24.3.11 <a href="https://wg21.link/range.prim.ssize">[range.prim.ssize]</a> as indicated:</p>

<blockquote>
<p>-1- The name <tt>ranges::ssize</tt> denotes
a customization point object (16.3.3.3.6 <a href="https://wg21.link/customization.point.object">[customization.point.object]</a>).
<del>The expression <tt>ranges::ssize(E)</tt>
for a subexpression <tt>E</tt> of type <tt>T</tt>
is expression-equivalent to:</del>
</p><p>
<del>(1.1) &mdash; If <tt>range_difference_t&lt;T&gt;</tt> has
width less than <tt>ptrdiff_t</tt>,
<tt>static_cast&lt;ptrdiff_t&gt;(ranges::size(E))</tt>.</del>
</p><p>
<del>(1.2) &mdash; Otherwise,
<tt>static_cast&lt;range_difference_t&lt;T&gt;&gt;(ranges::size(E))</tt>.</del>
</p><p>
<ins>
-?- Given a subexpression <tt>E</tt> with type <tt>T</tt>,
let <tt>t</tt> be an lvalue that denotes the reified object for <tt>E</tt>.
If <tt>ranges::size(t)</tt> is ill-formed,
<tt>ranges::ssize(E)</tt> is ill-formed.
Otherwise let <tt>D</tt> be
<tt><i>make-signed-like-t</i>&lt;decltype(ranges::size(t))&gt;</tt>,
or <tt>ptrdiff_t</tt> if it is wider than that type;
<tt>ranges::ssize(E)</tt> is expression-equivalent to
<tt>static_cast&lt;D&gt;(ranges::size(t))</tt>.
</ins>
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3404" href="https://cplusplus.github.io/LWG/lwg-active.html#3404">3404</a>. Finish removing <tt>subrange</tt>'s conversions from <tt><i>pair-like</i></tt></h3>
<p><b>Section:</b> 24.5.4 <a href="https://wg21.link/range.subrange">[range.subrange]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-02-20 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.subrange">active issues</a> in [range.subrange].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.subrange">issues</a> in [range.subrange].</p>
<p><b>Discussion:</b></p>
<p>
Both LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3281">3281</a> "Conversion from <tt><i>pair-like</i></tt> types to <tt>subrange</tt> is a 
silent semantic promotion" and LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3282">3282</a> "<tt>subrange</tt> converting constructor should 
disallow derived to base conversions" removed <tt>subrange</tt>'s hated implicit conversions from 
<tt><i>pair-like</i></tt> types. Notably, neither issue removed the two "<tt><i>iterator-sentinel-pair</i></tt>" 
deduction guides which target the removed constructors nor the exposition-only <tt><i>iterator-sentinel-pair</i></tt> 
concept itself, all of which are now useless.
</p>

<p><i>[2020-03-11 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after seven positive votes on the reflector.
</p>


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

<ol>
<li><p>Modify 24.5.4 <a href="https://wg21.link/range.subrange">[range.subrange]</a> as indicated:</p>

<blockquote><pre>
[&hellip;]
template&lt;class T, class U, class V&gt;
  concept <i>pair-like-convertible-from</i> = <i>// exposition only</i>
    !range&lt;T&gt; &amp;&amp; <i>pair-like</i>&lt;T&gt; &amp;&amp; constructible_from&lt;T, U, V&gt;;

<del>template&lt;class T&gt;
  concept <i>iterator-sentinel-pair</i> = <i>// exposition only</i>
    !range&lt;T&gt; &amp;&amp; <i>pair-like</i>&lt;T&gt; &amp;&amp;
    sentinel_for&lt;tuple_element_t&lt;1, T&gt;, tuple_element_t&lt;0, T&gt;&gt;;</del>
    
[&hellip;]

<del>template&lt;<i>iterator-sentinel-pair</i> P&gt;
  subrange(P) -&gt; subrange&lt;tuple_element_t&lt;0, P&gt;, tuple_element_t&lt;1, P&gt;&gt;;</del>

<del>template&lt;<i>iterator-sentinel-pair</i> P&gt;
  subrange(P, <i>make-unsigned-like-t</i>(iter_difference_t&lt;tuple_element_t&lt;0, P&gt;&gt;)) -&gt;
    subrange&lt;uple_element_t&lt;0, P&gt;, tuple_element_t&lt;1, P&gt;, subrange_kind::sized&gt;;</del>
[&hellip;]
</pre></blockquote>
</li>
</ol>




<hr>
<h3><a name="3405" href="https://cplusplus.github.io/LWG/lwg-active.html#3405">3405</a>. <tt>common_view</tt>'s converting constructor is bad, too</h3>
<p><b>Section:</b> 24.7.14.2 <a href="https://wg21.link/range.common.view">[range.common.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-02-20 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3280">3280</a> struck the problematic/extraneous converting constructor templates from the 
<tt><i>meow</i>_view</tt> range adaptor types in the standard library with the exception of <tt>common_view</tt>. 
The omission of <tt>common_view</tt> seems to have been simply an oversight: its converting constructor 
template is no less problematic or extraneous. We should remove <tt>common_view</tt>'s converting 
constructor template as well to finish the task. Both <tt>cmcstl2</tt> and <tt>range-v3</tt> removed 
the converting constructor template from <tt>common_view</tt> when removing the other converting 
constructor templates, so we have implementation experience that this change is good as well as 
consistent with the general thrust of LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3280">3280</a>.
</p>

<p><i>[2020-03-11 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after seven positive votes on the reflector.
</p>


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

<ol>
<li><p>Modify 24.7.14.2 <a href="https://wg21.link/range.common.view">[range.common.view]</a>, class template <tt>common_view</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
  
  [&hellip;]
  constexpr explicit common_view(V r);
  
  <del>template&lt;viewable_range R&gt;
    requires (!common_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;)
  constexpr explicit common_view(R&amp;&amp; r);</del>
  
  constexpr V base() const&amp; requires copy_constructible&lt;V&gt; { return base_; }
  [&hellip;]
  
</pre>
[&hellip;]
<pre>
<del>template&lt;viewable_range R&gt;
  requires (!common_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;)
constexpr explicit common_view(R&amp;&amp; r);</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Effects:</i> Initializes <tt>base_</tt> with <tt>views::all(std::forward&lt;R&gt;(r))</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3406" href="https://cplusplus.github.io/LWG/lwg-active.html#3406">3406</a>. <tt>elements_view::begin()</tt> and <tt>elements_view::end()</tt> have incompatible
constraints</h3>
<p><b>Section:</b> 24.7.16.2 <a href="https://wg21.link/range.elements.view">[range.elements.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Patrick Palka <b>Opened:</b> 2020-02-21 <b>Last modified:</b> 2020-10-02</p>
<p><b>Priority: </b>1
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.elements.view">issues</a> in [range.elements.view].</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/p1994r1">P1994R1</a> (<tt>elements_view</tt> needs its own
<tt>sentinel</tt>) introduces a distinct <tt><i>sentinel</i></tt> type for <tt>elements_view</tt>.
In doing so, it replaces the two existing overloads of <tt>elements_view::end()</tt> with four new ones:
</p>
<blockquote><pre>
<del>-    constexpr auto end() requires (!<i>simple-view</i>&lt;V&gt;)
-    { return ranges::end(<i>base_</i>); }
-
-    constexpr auto end() const requires <i>simple-view</i>&lt;V&gt;
-    { return ranges::end(<i>base_</i>); }</del>

<ins>+    constexpr auto end()
+    { return <i>sentinel</i>&lt;false&gt;{ranges::end(<i>base_</i>)}; }
+
+    constexpr auto end() requires common_range&lt;V&gt;
+    { return <i>iterator</i>&lt;false&gt;{ranges::end(<i>base_</i>)}; }
+
+    constexpr auto end() const
+      requires range&lt;const V&gt;
+    { return <i>sentinel</i>&lt;true&gt;{ranges::end(<i>base_</i>)}; }
+
+    constexpr auto end() const
+      requires common_range&lt;const V&gt;
+    { return <i>iterator</i>&lt;true&gt;{ranges::end(<i>base_</i>)}; }</ins>
</pre></blockquote>
<p>
But now these new overloads of <tt>elements_view::end()</tt> have constraints
that are no longer consistent with the constraints of <tt>elements_view::begin()</tt>:
</p>
<blockquote><pre>
     constexpr auto begin() requires (!<i>simple-view</i>&lt;V&gt;)
     { return <i>iterator</i>&lt;false&gt;(ranges::begin(<i>base_</i>)); }

     constexpr auto begin() const requires <i>simple-view</i>&lt;V&gt;
     { return <i>iterator</i>&lt;true&gt;(ranges::begin(<i>base_</i>)); }
</pre></blockquote>
<p>
This inconsistency means that we can easily come up with a view <tt>V</tt> for
which <tt>elements_view&lt;V&gt;::begin()</tt> returns an <tt><i>iterator</i>&lt;true&gt;</tt>
and <tt>elements_view&lt;V&gt;::end()</tt> returns an <tt><i>sentinel</i>&lt;false&gt;</tt>,
i.e. incomparable things of opposite constness. For example:
</p>
<blockquote><pre>
tuple&lt;int, int&gt; x[] = {{0,0}};
ranges::subrange r = {counted_iterator(x, 1), default_sentinel};
auto v = r | views::elements&lt;0&gt;;
v.begin() == v.end(); <i>// ill-formed</i>
</pre></blockquote>
<p>
Here, overload resolution for <tt>begin()</tt> selects the <tt>const</tt> overload because
the subrange <tt>r</tt> models <tt><i>simple-view</i></tt>. But overload resolution for
<tt>end()</tt> selects the non-<tt>const</tt> non-<tt>common_range</tt> overload. Hence
the last line of this snippet is ill-formed because it is comparing an iterator and
sentinel of opposite constness, for which we have no matching <tt>operator==</tt>
overload. So in this example <tt>v</tt> does not even model range because its <tt>begin()</tt>
and <tt>end()</tt> are incomparable.
<p/>
This issue can be resolved by making sure the constraints on <tt>elements_view::begin()</tt>
and on <tt>elements_view::end()</tt> are consistent and compatible. The following proposed
resolution seems to be one way to achieve that and takes inspiration from the design of
<tt>transform_view</tt>.
</p>

<p><i>[2020-04-04 Issue Prioritization]</i></p>

<p>Priority to 1 after reflector discussion.</p>

<p><i>[2020-07-17; telecon]</i></p>

<p>
Should be considered together with <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a> and <a href="https://cplusplus.github.io/LWG/lwg-active.html#3449">3449</a>.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
This wording is relative to <a href="https://wg21.link/n4849">N4849</a> after application of
<a href="https://wg21.link/p1994r1">P1994R1</a>.
</p>

<ol>
<li><p>Modify 24.7.16.2 <a href="https://wg21.link/range.elements.view">[range.elements.view]</a>, class template <tt>elements_view</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]
  template&lt;input_range V, size_t N&gt;
    requires view&lt;V&gt; &amp;&amp; <i>has-tuple-element</i>&lt;range_value_t&lt;V&gt;, N&gt; &amp;&amp;
      <i>has-tuple-element</i>&lt;remove_reference_t&lt;range_reference_t&lt;V&gt;&gt;, N&gt;
  class elements_view : public view_interface&lt;elements_view&lt;V, N&gt;&gt; {
  public:
    [&hellip;]
    constexpr V base() &amp;&amp; { return std::move(<i>base_</i>); }

    constexpr auto begin() <del>requires (!<i>simple-view</i>&lt;V&gt;)</del>
    { return <i>iterator</i>&lt;false&gt;(ranges::begin(<i>base_</i>)); }
    constexpr auto begin() const requires <del><i>simple-view</i>&lt;V&gt;</del><ins>range&lt;const V&gt;</ins>
    { return <i>iterator</i>&lt;true&gt;(ranges::begin(<i>base_</i>)); }
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-06-05 Tim updates P/R in light of reflector discussions and LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a> and comments]</i></p>

<p>
The fact that, as currently specified, <tt>sentinel&lt;false&gt;</tt> is not
comparable with <tt>iterator&lt;true&gt;</tt> is a problem with the specification
of this comparison, as noted in LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a>. The P/R below repairs
this problem along the lines suggested in that issue. The constraint mismatch does
make this problem easier to observe for <tt>elements_view</tt>, but the mismatch
is not independently a problem: since <tt>begin</tt> can only add constness on
<tt><i>simple-view</i></tt>s for which constness is immaterial, whether
<tt>end</tt> also adds constness or not ought not to matter.
<p/>
However, there is a problem with the <tt>begin</tt> overload set: if <tt>const V</tt> is a range,
but <tt>V</tt> is not a <tt><i>simple-view</i></tt>, then a <tt>const elements_view&lt;V, N&gt;</tt>
has no viable <tt>begin</tt> at all (the simplest example of such non-simple-views
is probably <tt>single_view</tt>). That's simply broken; the fix is to constrain
the <tt>const</tt> overload of <tt>begin</tt> with just <tt>range&lt;const V&gt;</tt>
instead of <tt><i>simple-view</i>&lt;V&gt;</tt>. Notably, this is how many other
uses of <i><tt>simple-view</tt></i> work already (see, e.g., <tt>take_view</tt> in
24.7.7.2 <a href="https://wg21.link/range.take.view">[range.take.view]</a>).
<p/>
The previous <i><tt>simple-view</tt></i> constraint on <tt>end</tt> served a
useful purpose (when done correctly): it reduces template instantiations if
the underlying view is const-agnostic. This was lost in P1994 because that paper
modeled the overload set on <tt>transform_view</tt>; however, discussion with
Eric Niebler confirmed that the reason <tt>transform_view</tt> doesn't have the
<i><tt>simple-view</tt></i> optimization is because it would add constness to
the callable object as well, which can make a material difference in the result.
Such concerns are not present in <tt>elements_view</tt> where the "callable
object" is effectively hard-coded into the type and unaffected by
const-qualification. The revised P/R below therefore restores the
<i><tt>simple-view</tt></i> optimization.
<p/>
I have implemented this P/R together with P1994 on top of libstdc++ trunk and
can confirm that no existing test cases were broken by these changes, and that
it fixes the issue reported here as well as in LWG 3448 (as it relates to
<tt>elements_view</tt>).
</p>

<p><i>[2020-10-02; Status to Tentatively Ready after five positive votes on the reflector]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4861">N4861</a>. It assumes
the <tt><i>maybe-const</i></tt> helper introduced by the P/R of LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a>.
</p>

<ol>
<li><p>Modify 24.7.16.2 <a href="https://wg21.link/range.elements.view">[range.elements.view]</a>, class template <tt>elements_view</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]
  template&lt;input_range V, size_t N&gt;
    requires view&lt;V&gt; &amp;&amp; <i>has-tuple-element</i>&lt;range_value_t&lt;V&gt;, N&gt; &amp;&amp;
      <i>has-tuple-element</i>&lt;remove_reference_t&lt;range_reference_t&lt;V&gt;&gt;, N&gt;
  class elements_view : public view_interface&lt;elements_view&lt;V, N&gt;&gt; {
  public:
    [&hellip;]
    constexpr V base() &amp;&amp; { return std::move(<i>base_</i>); }

    constexpr auto begin() requires (!<i>simple-view</i>&lt;V&gt;)
    { return <i>iterator</i>&lt;false&gt;(ranges::begin(<i>base_</i>)); }

    constexpr auto begin() const requires <del><i>simple-view</i>&lt;V&gt;</del><ins>range&lt;const V&gt;</ins>
    { return <i>iterator</i>&lt;true&gt;(ranges::begin(<i>base_</i>)); }

    constexpr auto end() <ins>requires (!<i>simple-view</i>&lt;V&gt; &amp;&amp; !common_range&lt;V&gt;)</ins>
    { return sentinel&lt;false&gt;{ranges::end(<i>base_</i>)}; }

    constexpr auto end() requires <ins>(!<i>simple-view</i>&lt;V&gt; &amp;&amp;</ins> common_range&lt;V&gt;<ins>)</ins>
    { return iterator&lt;false&gt;{ranges::end(<i>base_</i>)}; }

    constexpr auto end() const requires range&lt;const V&gt;
    { return sentinel&lt;true&gt;{ranges::end(<i>base_</i>)}; }

    constexpr auto end() const requires common_range&lt;const V&gt;
    { return iterator&lt;true&gt;{ranges::end(<i>base_</i>)}; }
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

<li><p>Modify 24.7.16.4 <a href="https://wg21.link/range.elements.sentinel">[range.elements.sentinel]</a> as indicated:</p>
<blockquote class="note">
<p>
[<i>Drafting note</i>: Unlike the current P/R of LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a>, this P/R also changes
the return type of <tt>operator-</tt> to depend on the constness of iterator
rather than that of the sentinel. This is consistent with
<tt>sized_sentinel_for&lt;S, I&gt;</tt> (23.3.4.8 <a href="https://wg21.link/iterator.concept.sizedsentinel">[iterator.concept.sizedsentinel]</a>),
which requires <tt>decltype(i - s)</tt> to be <tt>iter_difference_t&lt;I&gt;</tt>.]
</p>
</blockquote>
<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, size_t N&gt;
    requires view&lt;V&gt; &amp;&amp; <i>has-tuple-element</i>&lt;range_value_t&lt;V&gt;, N&gt; &amp;&amp;
      <i>has-tuple-element</i>&lt;remove_reference_t&lt;range_reference_t&lt;V&gt;&gt;, N&gt;
  template&lt;bool Const&gt;
  class elements_view&lt;V, F&gt;::<i>sentinel</i> {
    [&hellip;]
    constexpr sentinel_t&lt;<i>Base</i>&gt; base() const;

    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
    friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);

    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
    friend constexpr range_difference_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;
      operator-(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y)
        <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;

    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
    friend constexpr range_difference_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;
      operator-(const <i>sentinel</i>&amp; x, const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; y)
        <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> == y.<i>end_</i>;</tt>
</p>
</blockquote>
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
friend constexpr range_difference_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;
  operator-(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y)
    <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> - y.<i>end_</i>;</tt>
</p>
</blockquote>
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
friend constexpr range_difference_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;
  operator-(const <i>sentinel</i>&amp; x, const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; y)
    <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> Equivalent to: <tt>return x.<i>end_</i> - y.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3413" href="https://cplusplus.github.io/LWG/lwg-active.html#3413">3413</a>. [fund.ts.v3] <tt>propagate_const</tt>'s <tt>swap</tt>'s <tt>noexcept</tt> specification needs to 
be constrained and use a trait</h3>
<p><b>Section:</b> 3.2.2.7 [fund.ts.v3::propagate_const.modifiers], 3.2.2.9 [fund.ts.v3::propagate_const.algorithms] <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas K&ouml;ppe <b>Opened:</b> 2020-02-29 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v3</b></p>
<p>
In the Fundamentals TS, the <tt>noexcept</tt> specifications of both the member and non-member <tt>swap</tt> 
functions for <tt>propagate_const</tt> are using the old, ill-formed pattern of attempting to use 
"<tt>noexcept(swap(...))</tt>" as the boolean predicate. According to LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2456">2456</a>, this is 
ill-formed, and a resolution such as in <a href="https://wg21.link/p0185r1">P0185R1</a> is required.
</p>

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

<ol>
<li><p>Modify  [fund.ts.v3::propagate_const.syn], header <tt>&lt;experimental/propagate_const&gt;</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<i>// 3.2.2.9 [fund.ts.v3::propagate_const.algorithms], propagate_const specialized algorithms</i>
template &lt;class T&gt;
  constexpr void swap(propagate_const&lt;T&gt;&amp; pt, propagate_const&lt;T&gt;&amp; pt2) noexcept(<del><i>see below</i></del><ins>is_nothrow_swappable_v&lt;T&gt;</ins>);
</pre>
</blockquote>
</li>

<li><p>Modify 3.2.2.1 [fund.ts.v3::propagate_const.overview], class template <tt>propagate_const</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<i>// 3.2.2.7 [fund.ts.v3::propagate_const.modifiers], propagate_const modifiers</i>
constexpr void swap(propagate_const&amp; pt) noexcept(<del><i>see below</i></del><ins>is_nothrow_swappable_v&lt;T&gt;</ins>);
</pre>
</blockquote>
</li>

<li><p>Modify 3.2.2.7 [fund.ts.v3::propagate_const.modifiers] as indicated:</p>

<blockquote>
<pre>
constexpr void swap(propagate_const&amp; pt) noexcept(<del><i>see below</i></del><ins>is_nothrow_swappable_v&lt;T&gt;</ins>);
</pre>
<blockquote>
<p>
<del>-2- The constant-expression in the exception-specification is <tt>noexcept(swap(t_, pt.t_))</tt>.</del>
<p/>
-3- <i>Effects:</i> <tt>swap(t_, pt.t_)</tt>. 
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 3.2.2.9 [fund.ts.v3::propagate_const.algorithms] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt;
  constexpr void swap(propagate_const&lt;T&gt;&amp; pt1, propagate_const&lt;T&gt;&amp; pt2) noexcept(<del><i>see below</i></del><ins>is_nothrow_swappable_v&lt;T&gt;</ins>);
</pre>
<blockquote>
<p>
<del>-2- The constant-expression in the exception-specification is <tt>noexcept(pt1.swap(pt2))</tt>.</del>
<p/>
-3- <i>Effects:</i> <tt>pt1.swap(pt2)</tt>. 
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-03-30; Reflector discussion]</i></p>

<p>
This issue has very much overlap with LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#2561">2561</a>, especially now that the library fundamentals has been rebased
to C++20 the there reported problem for the corresponding <tt>swap</tt> problem for <tt>optional</tt> is now moot. During the
reflector discussion of this issue here it was also observed that the free <tt>swap</tt> template for <tt>propagate_const</tt>
needs to be constrained. This has been done below in the revised wording which also attempts to use a similar style as
the IS.
</p>

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

<ol>

<li><p>Modify 3.2.2.1 [fund.ts.v3::propagate_const.overview], class template <tt>propagate_const</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<i>// 3.2.2.7 [fund.ts.v3::propagate_const.modifiers], propagate_const modifiers</i>
constexpr void swap(propagate_const&amp; pt) noexcept(<del><i>see below</i></del><ins>is_nothrow_swappable_v&lt;T&gt;</ins>);
</pre>
</blockquote>
</li>

<li><p>Modify 3.2.2.7 [fund.ts.v3::propagate_const.modifiers] as indicated:</p>

<blockquote>
<pre>
constexpr void swap(propagate_const&amp; pt) noexcept(<del><i>see below</i></del><ins>is_nothrow_swappable_v&lt;T&gt;</ins>);
</pre>
<blockquote>
<p>
<del>-2- The constant-expression in the exception-specification is <tt>noexcept(swap(t_, pt.t_))</tt>.</del>
<p/>
-3- <i>Effects:</i> <tt>swap(t_, pt.t_)</tt>. 
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 3.2.2.9 [fund.ts.v3::propagate_const.algorithms] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt;
  constexpr void swap(propagate_const&lt;T&gt;&amp; pt1, propagate_const&lt;T&gt;&amp; pt2) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>is_swappable_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
<p/>
<del>-2- The constant-expression in the exception-specification is <tt>noexcept(pt1.swap(pt2))</tt>.</del>
<p/>
-3- <i>Effects:</i> <tt>pt1.swap(pt2)</tt>. 
<p/>
<ins>-?- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to:</ins>
<blockquote><pre>
<ins>noexcept(pt1.swap(pt2))</ins>
</pre></blockquote>
</p>
</blockquote>
</blockquote>
</li>
</ol></blockquote>

<p><i>[2020-04-06; Wording update upon reflector discussions]</i></p>


<p><i>[2020-05-03 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after five positive votes on the reflector.
</p>


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

<ol>

<li><p>Modify 3.2.2.1 [fund.ts.v3::propagate_const.overview], class template <tt>propagate_const</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
<i>// 3.2.2.7 [fund.ts.v3::propagate_const.modifiers], propagate_const modifiers</i>
constexpr void swap(propagate_const&amp; pt) noexcept(<del><i>see below</i></del><ins>is_nothrow_swappable_v&lt;T&gt;</ins>);
</pre>
</blockquote>
</li>

<li><p>Modify 3.2.2.7 [fund.ts.v3::propagate_const.modifiers] as indicated:</p>

<blockquote>
<pre>
constexpr void swap(propagate_const&amp; pt) noexcept(<del><i>see below</i></del><ins>is_nothrow_swappable_v&lt;T&gt;</ins>);
</pre>
<blockquote>
<p>
<ins>-?- <i>Preconditions:</i> Lvalues of type <tt>T</tt> are swappable (C++17 &sect;20.5.3.2).</ins>
<p/>
<del>-2- The constant-expression in the exception-specification is <tt>noexcept(swap(t_, pt.t_))</tt>.</del>
<p/>
-3- <i>Effects:</i> <tt>swap(t_, pt.t_)</tt>. 
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 3.2.2.9 [fund.ts.v3::propagate_const.algorithms] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt;
  constexpr void swap(propagate_const&lt;T&gt;&amp; pt1, propagate_const&lt;T&gt;&amp; pt2) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>is_swappable_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
<p/>
<del>-2- The constant-expression in the exception-specification is <tt>noexcept(pt1.swap(pt2))</tt>.</del>
<p/>
-3- <i>Effects:</i> <ins>Equivalent to:</ins> <tt>pt1.swap(pt2)</tt>. 
<p/>
<ins>-?- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to:</ins>
<blockquote><pre>
<ins>noexcept(pt1.swap(pt2))</ins>
</pre></blockquote>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3414" href="https://cplusplus.github.io/LWG/lwg-active.html#3414">3414</a>. [networking.ts] <tt>service_already_exists</tt> has no usable constructors</h3>
<p><b>Section:</b> 13.7 [networking.ts::async.exec.ctx] <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-03-17 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: networking.ts</b></p>
<p>
In the Networking TS, the <tt>service_already_exists</tt> exception type
has no constructors declared. The <tt>logic_error</tt> base class is not
default constructible, so <tt>service_already_exists</tt>'s implicit default
constructor is defined as deleted.
</p>
<p>
Implementations can add one or more private constructors that can be used
by <tt>make_service</tt>, but there seems to be little benefit to that.
The Boost.Asio type of the same name has a public default constructor.
</p>

<p><i>[2020-04-18 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after six positive votes on the reflector.
</p>


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

<ol>
<li><p>Modify 13.7 [networking.ts::async.exec.ctx] p1, as indicated:</p>

<blockquote>
<pre>
<i>// service access</i>
template&lt;class Service> typename Service::key_type&amp;
use_service(execution_context&amp; ctx);
template&lt;class Service, class... Args&gt; Service&amp;
make_service(execution_context&amp; ctx, Args&amp;&amp;... args);
template&lt;class Service&gt; bool has_service(const execution_context&amp; ctx) noexcept;
class service_already_exists : public logic_error <del>{ };</del>
<ins>{
public:
  service_already_exists();
};</ins>
</pre>
</blockquote>
</li>

<li>
<p>Add a new subclause after [async.exec.ctx.globals]:</p>

<blockquote>
<p>
<b>13.7.6 Class <tt>service_already_exists</tt> [async.exec.ctx.except]</b>
</p>

<p>
-1- The class <tt>service_already_exists</tt> defines the type of objects
thrown as exceptions to report an attempt to add an existing service
to an <tt>execution_context</tt>.
</p>
<pre>
service_already_exists();
</pre>
<blockquote>
<p>-2- <i>Postconditions:</i> <tt>what()</tt> returns an implementation-defined NTBS.</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3419" href="https://cplusplus.github.io/LWG/lwg-active.html#3419">3419</a>. &sect;[algorithms.requirements]/15 doesn't reserve as many rights as it intends to</h3>
<p><b>Section:</b> 25.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2020-03-24 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#algorithms.requirements">active issues</a> in [algorithms.requirements].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#algorithms.requirements">issues</a> in [algorithms.requirements].</p>
<p><b>Discussion:</b></p>
<p>
25.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a>/15 says:
</p>
<blockquote><p>
"The number and order of deducible template parameters for algorithm declarations are unspecified, except 
where explicitly stated otherwise. [<i>Note:</i> Consequently, the algorithms may not be called with 
explicitly-specified template argument lists. &mdash; <i>end note</i>]"
</p></blockquote>
<p>
But the note doesn't follow from the normative rule. For example, we felt the need to explicitly allow 
deduction for <tt>min</tt>'s template parameter:
</p>
<blockquote><pre>
template&lt;typename T&gt; const T&amp; min(const T&amp;, const T&amp;);
</pre></blockquote>
<p>
&hellip; but if only the order and number of <em>deducible</em> template parameters is permitted to vary, 
then because of the required deduction behavior of this function template, there are only three possible 
valid declarations:
</p>
<blockquote><pre>
template&lt;typename T&gt; ??? min(const T&amp;, const T&amp;);
template&lt;typename T, typename U&gt; ??? min(const T&amp;, const U&amp;);
template&lt;typename T, typename U&gt; ??? min(const U&amp;, const T&amp;);
</pre></blockquote>
<p>
(up to minor differences in the parameter type). This doesn't prohibit calls with an explicitly-specified 
template argument list, contrary to the claim in the note. (Indeed, because a call such as <tt>min(1, {})</tt> 
is valid, either the first of the above three overloads must be present or there must be a default template 
argument <tt>typename U = T</tt>, which further adds to the fact that there may be valid calls with an 
explicitly-specified template argument list.)
<p/>
Also, the "explicitly stated otherwise" cases use phrasing such as: "An invocation may explicitly specify 
an argument for the template parameter <tt>T</tt> of the overloads in namespace <tt>std</tt>." which 
doesn't "specify otherwise" the normative rule, but does "specify otherwise" the claim in the note.
<p/>
All this leads me to believe that [algorithms.requirements]/15 is backwards: the normative rule should be a 
note and the note should be the normative rule.
</p>

<p><i>[2020-04-04 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after six positive votes on the reflector.
</p>


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

<ol>
<li><p>Modify 25.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a> as indicated:</p>

<blockquote>
<p>
-15- The <ins>well-formedness and behavior of a call to an algorithm with an explicitly-specified template 
argument list is</ins><del>number and order of deducible template parameters for algorithm declarations are</del> 
unspecified, except where explicitly stated otherwise. [<i>Note:</i> Consequently, <ins>an implementation can 
declare an algorithm with different template parameters than those presented</ins><del>the algorithms may not be 
called with explicitly-specified template argument lists</del>. &mdash; <i>end note</i>]
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3420" href="https://cplusplus.github.io/LWG/lwg-active.html#3420">3420</a>. <tt><i>cpp17-iterator</i></tt> should check that the type looks like an iterator first</h3>
<p><b>Section:</b> 23.3.2.3 <a href="https://wg21.link/iterator.traits">[iterator.traits]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-02-29 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#iterator.traits">active issues</a> in [iterator.traits].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</p>
<p><b>Discussion:</b></p>
<p>
It is common in pre-C++20 code to rely on SFINAE-friendly <tt>iterator_traits</tt> 
to rule out non-iterators in template constraints (<tt>std::filesystem::path</tt> 
is one example in the standard library).
<p/>
C++20 changed <tt>iterator_traits</tt> to automatically detect its members in
some cases, and this detection can cause constraint recursion. LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3244">3244</a> 
tries to fix this for <tt>path</tt> by short-circuiting the check when the source type is 
<tt>path</tt> itself, but this isn't sufficient:
</p>
<blockquote><pre>
struct Foo 
{
  Foo(const std::filesystem::path&amp;);
};

static_assert(std::copyable&lt;Foo&gt;);
</pre></blockquote>
<p>
Here the copyability determination will ask whether a <tt>path</tt> can be
constructed from a <tt>Foo</tt>, which asks whether <tt>Foo</tt> is an iterator, which
checks whether <tt>Foo</tt> is <tt>copyable</tt> [&hellip;].
<p/>
To reduce the risk of constraint recursion, we should change <tt><i>cpp17-iterator</i></tt> 
so that it does not ask about copyability until the type is known to resemble an iterator.
</p>

<p><i>[2020-04-04 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after six positive votes on the reflector.
</p>


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

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

<blockquote>
<p>
-2- The definitions in this subclause make use of the following exposition-only concepts:
</p>
<blockquote>
<pre>
template&lt;class I&gt;
concept <i>cpp17-iterator</i> =
  <del>copyable&lt;I&gt; &amp;&amp;</del> requires(I i) {
    { *i } -&gt; <i>can-reference</i>;
    { ++i } -&gt; same_as&lt;I&amp;&gt;;
    { *i++ } -&gt; <i>can-reference</i>;
  } <ins>&amp;&amp; copyable&lt;I&gt;</ins>;
  
[&hellip;]
</pre>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3421" href="https://cplusplus.github.io/LWG/lwg-active.html#3421">3421</a>. Imperfect ADL emulation for <tt><i>boolean-testable</i></tt></h3>
<p><b>Section:</b> 18.5.2 <a href="https://wg21.link/concept.booleantestable">[concept.booleantestable]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Davis Herring <b>Opened:</b> 2020-03-24 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p>
18.5.2 <a href="https://wg21.link/concept.booleantestable">[concept.booleantestable]</a>/4 checks for "a specialization of a class template that is a member of 
the same namespace as <tt>D</tt>", which ignores the possibility of inline namespaces.
</p>

<p><i>[2020-04-18 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after six positive votes on the reflector.
</p>


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

<ol>
<li><p>Modify 18.5.2 <a href="https://wg21.link/concept.booleantestable">[concept.booleantestable]</a> as indicated:</p>

<blockquote>
<p>
-4- A <i>key parameter</i> of a function template <tt>D</tt> is a function parameter of type <i>cv</i> <tt>X</tt> 
or reference thereto, where <tt>X</tt> names a specialization of a class template that <ins>has the same innermost 
enclosing non-inline</ins><del>is a member of the same</del> namespace as <tt>D</tt>, and <tt>X</tt> contains at 
least one template parameter that participates in template argument deduction. [&hellip;]
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3425" href="https://cplusplus.github.io/LWG/lwg-active.html#3425">3425</a>. <tt>condition_variable_any</tt> fails to constrain its <tt>Lock</tt> parameters</h3>
<p><b>Section:</b> 32.6.5 <a href="https://wg21.link/thread.condition.condvarany">[thread.condition.condvarany]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-04-04 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
<p><b>Discussion:</b></p>
<p>
32.6.5 <a href="https://wg21.link/thread.condition.condvarany">[thread.condition.condvarany]</a>/1 says "A <tt>Lock</tt> type shall meet the <i>Cpp17BasicLockable</i> 
requirements (32.2.5.2 <a href="https://wg21.link/thread.req.lockable.basic">[thread.req.lockable.basic]</a>).", which is fine, but it notably doesn't require anything 
to be a <tt>Lock</tt> type or meet the requirements of a <tt>Lock</tt> type. Given that every member template of 
<tt>condition_variable_any</tt> has a template parameter named <tt>Lock</tt>, the intent is clearly to impose a 
requirement on the template arguments supplied for those parameters but the use of code font for "<tt>Lock</tt>" 
in the definition of "<tt>Lock</tt> type" is a bit subtle to establish that connection. We should specify this 
more clearly.
</p>

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

<ol>
<li><p>Modify 32.6.5 <a href="https://wg21.link/thread.condition.condvarany">[thread.condition.condvarany]</a> as indicated:</p>

<blockquote>
<p>
-1- <del>A <tt>Lock</tt> type</del><ins>Template arguments for template parameters of member templates of 
<tt>conditional_variable_any</tt> named <tt>Lock</tt></ins> shall meet the <i>Cpp17BasicLockable</i> 
requirements (32.2.5.2 <a href="https://wg21.link/thread.req.lockable.basic">[thread.req.lockable.basic]</a>). 
[<i>Note:</i> All of the standard mutex types meet this requirement. If a <del><tt>Lock</tt></del> type other 
than one of the standard mutex types or a <tt>unique_lock</tt> wrapper for a standard mutex type is used with 
<tt>condition_variable_any</tt>, the user should ensure that any necessary synchronization is in place with 
respect to the predicate associated with the <tt>condition_variable_any</tt> instance. &mdash; <i>end note</i>]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-04-06; Tim improves wording]</i></p>


<p><i>[2020-04-11 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after seven positive votes on the reflector.
</p>


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

<ol>
<li><p>Modify 32.6.5 <a href="https://wg21.link/thread.condition.condvarany">[thread.condition.condvarany]</a> as indicated:</p>

<blockquote>
<p>
-1- <del>A <tt>Lock</tt> type</del><ins>In this subclause 32.6.5 <a href="https://wg21.link/thread.condition.condvarany">[thread.condition.condvarany]</a>, template 
arguments for template parameters named <tt>Lock</tt></ins> shall meet the <i>Cpp17BasicLockable</i> 
requirements (32.2.5.2 <a href="https://wg21.link/thread.req.lockable.basic">[thread.req.lockable.basic]</a>). 
[<i>Note:</i> All of the standard mutex types meet this requirement. If a <del><tt>Lock</tt></del> type other 
than one of the standard mutex types or a <tt>unique_lock</tt> wrapper for a standard mutex type is used with 
<tt>condition_variable_any</tt>, the user should ensure that any necessary synchronization is in place with 
respect to the predicate associated with the <tt>condition_variable_any</tt> instance. &mdash; <i>end note</i>]
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3426" href="https://cplusplus.github.io/LWG/lwg-active.html#3426">3426</a>. <tt>operator&lt;=&gt;(const unique_ptr&lt;T, D&gt;&amp;, nullptr_t)</tt> can't get no satisfaction</h3>
<p><b>Section:</b> 20.11.1.6 <a href="https://wg21.link/unique.ptr.special">[unique.ptr.special]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-04-09 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#unique.ptr.special">issues</a> in [unique.ptr.special].</p>
<p><b>Discussion:</b></p>
<p>
The constraint for <tt>operator&lt;=&gt;(const unique_ptr&lt;T, D&gt;&amp;, nullptr_t)</tt>
cannot be satisfied, because <tt>std::three_way_comparable&lt;nullptr_t&gt;</tt> is <tt>false</tt>,
because <tt>nullptr &lt;=&gt; nullptr</tt> is ill-formed.
<p/>
We can make it work as intended by comparing <tt>x.get()</tt> to <tt>pointer(nullptr)</tt>
instead of to <tt>nullptr</tt> directly.
</p>

<p><i>[2020-04-14; Replacing the functional cast by a <tt>static_cast</tt> as result of reflector discussion]</i></p>


<p><i>[2020-04-18 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after seven positive votes on the reflector.
</p>


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

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

<blockquote>
<pre>
[&hellip;]
template&lt;class T, class D&gt;
  bool operator&gt;=(nullptr_t, const unique_ptr&lt;T, D&gt;&amp; y);
template&lt;class T, class D&gt;
  requires three_way_comparable<del>_with</del>&lt;typename unique_ptr&lt;T, D&gt;::pointer<del>, nullptr_t</del>&gt;
  compare_three_way_result_t&lt;typename unique_ptr&lt;T, D&gt;::pointer<del>, nullptr_t</del>&gt;
    operator&lt;=&gt;(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 20.11.1.6 <a href="https://wg21.link/unique.ptr.special">[unique.ptr.special]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T, class D&gt;
  requires three_way_comparable<del>_with</del>&lt;typename unique_ptr&lt;T, D&gt;::pointer<del>, nullptr_t</del>&gt;
  compare_three_way_result_t&lt;typename unique_ptr&lt;T, D&gt;::pointer<del>, nullptr_t</del>&gt;
    operator&lt;=&gt;(const unique_ptr&lt;T, D&gt;&amp; x, nullptr_t);
</pre>

<blockquote>
<p>
-18- <i>Returns:</i> <tt>compare_three_way()(x.get(), <ins>static_cast&lt;typename unique_ptr&lt;T, D&gt;::pointer&gt;(</ins>nullptr<ins>)</ins>)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3427" href="https://cplusplus.github.io/LWG/lwg-active.html#3427">3427</a>. <tt>operator&lt;=&gt;(const shared_ptr&lt;T&gt;&amp;, nullptr_t)</tt> definition ill-formed</h3>
<p><b>Section:</b> 20.11.3.8 <a href="https://wg21.link/util.smartptr.shared.cmp">[util.smartptr.shared.cmp]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2020-04-11 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#util.smartptr.shared.cmp">issues</a> in [util.smartptr.shared.cmp].</p>
<p><b>Discussion:</b></p>
<p>
This is similar to LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3426">3426</a>: This time the definition of 
<tt>operator&lt;=&gt;(const shared_ptr&lt;T&gt;&amp;, nullptr_t)</tt> is ill-formed, whose effects are essentially 
specified as calling:
</p>
<blockquote><pre>
compare_three_way()(a.get(), nullptr)
</pre></blockquote>
<p>
This call will be ill-formed by constraint-violation, because both <tt>nullptr &lt;=&gt; nullptr</tt> as well as 
<tt>((T*) 0) &lt;=&gt; nullptr</tt> are ill-formed.
<p/>
As a short-term solution we can make it work as intended &mdash; equivalent to LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3426">3426</a> &mdash; by 
comparing <tt>a.get()</tt> to <tt>(element_type*) nullptr</tt> instead of to <tt>nullptr</tt> directly.
<p/>
As a long-term solution we should at least consider to deprecate the mixed relational operators as well as the 
mixed three-way comparison operator of all our smart-pointers with <tt>std::nullptr_t</tt> since the core language 
has eliminated relational comparisons of pointers with <tt>std::nullptr_t</tt> with 
<a href="https://wg21.link/n3624">N3624</a> four years after they had been originally accepted by 
<a href="https://wg21.link/cwg879">CWG 879</a>. Consequently, for C++20, the mixed three-way comparison between 
pointers and <tt>nullptr</tt> is not supported either. For this long-term solution I'm suggesting to handle this
via a proposal.
</p>

<p><i>[2020-05-16 Reflector discussions]</i></p>

<p>Status to Tentatively Ready and priority to 0 after five positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 20.11.3.8 <a href="https://wg21.link/util.smartptr.shared.cmp">[util.smartptr.shared.cmp]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt;
  strong_ordering operator&lt;=&gt;(const shared_ptr&lt;T&gt;&amp; a, nullptr_t) noexcept;
</pre>

<blockquote>
<p>
-5- <i>Returns:</i> <tt>compare_three_way()(a.get(), <ins>static_cast&lt;typename shared_ptr&lt;T&gt;::element_type*&gt;(</ins>nullptr<ins>)</ins>)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3428" href="https://cplusplus.github.io/LWG/lwg-active.html#3428">3428</a>. <tt>single_view</tt>'s in place constructor should be explicit</h3>
<p><b>Section:</b> 24.6.3.2 <a href="https://wg21.link/range.single.view">[range.single.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-04-07 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p>
The <tt>in_place_t</tt> constructor template of <tt>single_view</tt> is not explicit:
</p>
<blockquote><pre>
template&lt;class... Args&gt;
  requires constructible_from&lt;T, Args...&gt;
constexpr single_view(in_place_t, Args&amp;&amp;... args);
</pre></blockquote>
<p>
so it defines an implicit conversion from <tt>std::in_place_t</tt> to
<tt>single_view&lt;T&gt;</tt> whenever <tt>constructible_from&lt;T&gt;</tt> is modeled, 
which seems unlikely to be the intent.
</p>

<p><i>[2020-04-18 Issue Prioritization]</i></p>
 
<p>
Status set to Tentatively Ready after six positive votes on the reflector.
</p>


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

<ol>
<li><p>Modify 24.6.3.2 <a href="https://wg21.link/range.single.view">[range.single.view]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;copy_constructible T&gt;
    requires is_object_v&lt;T&gt;
  class single_view : public view_interface&lt;single_view&lt;T&gt;&gt; {
    [&hellip;]
  public:
    [&hellip;]
    template&lt;class... Args&gt;
      requires constructible_from&lt;T, Args...&gt;
    constexpr <ins>explicit</ins> single_view(in_place_t, Args&amp;&amp;... args);

    [&hellip;]
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
template&lt;class... Args&gt;
constexpr <ins>explicit</ins> single_view(in_place_t, Args&amp;&amp;... args);
</pre>

<blockquote>
<p>
-3- <i>Effects:</i> Initializes <tt>value_</tt> as if by <tt>value_{in_place, std::forward&lt;Args&gt;(args)...}</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3434" href="https://cplusplus.github.io/LWG/lwg-active.html#3434">3434</a>. <tt>ios_base</tt> never reclaims memory for <tt>iarray</tt> and <tt>parray</tt></h3>
<p><b>Section:</b> 29.5.3.8 <a href="https://wg21.link/ios.base.cons">[ios.base.cons]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2020-04-26 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#ios.base.cons">issues</a> in [ios.base.cons].</p>
<p><b>Discussion:</b></p>
<p>
According to 29.5.3.6 <a href="https://wg21.link/ios.base.storage">[ios.base.storage]</a> the class <tt>ios_base</tt> allocates memory,
represented by two exposition-only pointers, <tt>iarray</tt> and <tt>parray</tt> in response
to calls to <tt>iword</tt> and <tt>pword</tt>. However, the specification for the destructor
in 29.5.3.8 <a href="https://wg21.link/ios.base.cons">[ios.base.cons]</a> says nothing about reclaiming any allocated memory.
</p>

<p><i>[2020-07-17; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after six votes in favour during reflector discussions.
</p>


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

<ol>
<li><p>Modify 29.5.3.8 <a href="https://wg21.link/ios.base.cons">[ios.base.cons]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> Wording modeled on container requirements]
</p>
</blockquote>

<blockquote>
<pre>
~ios_base();
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> Calls each registered callback pair <tt>(fn, idx)</tt> 
(29.5.3.7 <a href="https://wg21.link/ios.base.callback">[ios.base.callback]</a>) as <tt>(*fn)(erase_event, *this, idx)</tt> 
at such time that any <tt>ios_base</tt> member function called from within 
<tt>fn</tt> has well-defined results. <ins>Then, any memory obtained is deallocated.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3435" href="https://cplusplus.github.io/LWG/lwg-active.html#3435">3435</a>. <tt>three_way_comparable_with&lt;reverse_iterator&lt;int*&gt;, reverse_iterator&lt;const int*&gt;&gt;</tt></h3>
<p><b>Section:</b> 23.5.3.4 <a href="https://wg21.link/move.iter.cons">[move.iter.cons]</a>, 23.5.1.4 <a href="https://wg21.link/reverse.iter.cons">[reverse.iter.cons]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-04-26 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#move.iter.cons">active issues</a> in [move.iter.cons].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#move.iter.cons">issues</a> in [move.iter.cons].</p>
<p><b>Discussion:</b></p>
<p>
Despite that <tt>reverse_iterator&lt;int*&gt;</tt> and <tt>reverse_iterator&lt;const int*&gt;</tt> are comparable with 
<tt>&lt;=&gt;</tt>, <tt>three_way_comparable_with&lt;reverse_iterator&lt;int*&gt;, reverse_iterator&lt;const int*&gt;&gt;</tt> 
is <tt>false</tt>. This unfortunate state of affairs results from the absence of constraints on <tt>reverse_iterator</tt>'s 
converting constructor: both <tt>convertible_to&lt;reverse_iterator&lt;int*&gt;, reverse_iterator&lt;const int*&gt;&gt;</tt>
and <tt>convertible_to&lt;reverse_iterator&lt;const int*&gt;, reverse_iterator&lt;int*&gt;&gt;</tt> evaluate to <tt>true</tt>, 
despite that <tt>reverse_iterator&lt;int*&gt;</tt>'s converting constructor template is ill-formed when instantiated 
for <tt>reverse_iterator&lt;const int*&gt;</tt>. This apparent bi-convertibility results in ambiguity when trying to 
determine <tt>common_reference_t&lt;const reverse_iterator&lt;int*&gt;&amp;, const reverse_iterator&lt;const int*&gt;&amp;&gt;</tt>, 
causing the <tt>common_reference</tt> requirement in <tt>three_way_comparable_with</tt> to fail.
<p/>
I think we should correct this by constraining <tt>reverse_iterator</tt>'s conversion constructor (and converting 
assignment operator, while we're here) correctly so we can use the concept to determine when it's ok to compare 
specializations of <tt>reverse_iterator</tt> with <tt>&lt;=&gt;</tt>.
<p/>
<tt>move_iterator</tt> has similar issues due to its similarly unconstrained conversions. We should fix both similarly.
</p>

<p><i>[2020-07-17; Priority set to 2 in telecon]</i></p>


<p><i>[2020-07-26; Reflector poll]</i></p>

<p>
Set status to Tentatively Ready after five votes in favour during reflector discussions.
</p>


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

<ol>
<li><p>Modify 23.5.3.4 <a href="https://wg21.link/move.iter.cons">[move.iter.cons]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> this incorporates and supercedes the P/R of LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3265">3265</a>.]
</p>
</blockquote>

<blockquote>
<pre>
constexpr move_iterator();
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> <del>Constructs a <tt>move_iterator</tt>, v</del><ins>V</ins>alue-initializ<ins>es</ins><del>ing</del> 
<tt>current</tt>. <del>Iterator operations applied to the resulting iterator have defined behavior if and only if 
the corresponding operations are defined on a value-initialized iterator of type <tt>Iterator</tt>.</del>
</p>
</blockquote>
<pre>
constexpr explicit move_iterator(Iterator i);
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> <del>Constructs a <tt>move_iterator</tt>, i</del><ins>I</ins>nitializ<ins>es</ins><del>ing</del> 
<tt>current</tt> with <tt>std::move(i)</tt>.
</p>
</blockquote>
<pre>
template&lt;class U&gt; constexpr move_iterator(const move_iterator&lt;U&gt;&amp; u);
</pre>
<blockquote>
<p>
-3- <del><i>Mandates:</i> <tt>U</tt> is convertible to <tt>Iterator</tt></del><ins><i>Constraints:</i> 
<tt>is_same_v&lt;U, Iterator&gt;</tt> is <tt>false</tt> and <tt>const U&amp;</tt> models 
<tt>convertible_to&lt;Iterator&gt;</tt></ins>.
<p/>
-4- <i>Effects:</i> <del>Constructs a <tt>move_iterator</tt>, i</del><ins>I</ins>nitializ<ins>es</ins><del>ing</del> 
<tt>current</tt> with <tt>u.<ins>current</ins><del>base()</del></tt>.
</p>
</blockquote>
<pre>
template&lt;class U&gt; constexpr move_iterator&amp; operator=(const move_iterator&lt;U&gt;&amp; u);
</pre>
<blockquote>
<p>
-5- <del><i>Mandates:</i> <tt>U</tt> is convertible to <tt>Iterator</tt></del><ins><i>Constraints:</i> 
<tt>is_same_v&lt;U, Iterator&gt;</tt> is <tt>false</tt>, <tt>const U&amp;</tt> models 
<tt>convertible_to&lt;Iterator&gt;</tt>, and <tt>assignable_from&lt;Iterator&amp;, const U&amp;&gt;</tt> 
is modeled</ins>.
<p/>
-6- <i>Effects:</i> Assigns <tt>u.<ins>current</ins><del>base()</del></tt> to <tt>current</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 23.5.1.4 <a href="https://wg21.link/reverse.iter.cons">[reverse.iter.cons]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class U&gt; constexpr reverse_iterator(const reverse_iterator&lt;U&gt;&amp; u);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>is_same_v&lt;U, Iterator&gt;</tt> is <tt>false</tt> and 
<tt>const U&amp;</tt> models <tt>convertible_to&lt;Iterator&gt;</tt>.</ins>
<p/>
-3- <i>Effects:</i> Initializes <tt>current</tt> with <tt>u.current</tt>.
</p>
</blockquote>
<pre>
template&lt;class U&gt;
  constexpr reverse_iterator&amp;
    operator=(const reverse_iterator&lt;U&gt;&amp; u);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>is_same_v&lt;U, Iterator&gt;</tt> is <tt>false</tt>, 
<tt>const U&amp;</tt> models <tt>convertible_to&lt;Iterator&gt;</tt>, and 
<tt>assignable_from&lt;Iterator&amp;, const U&amp;&gt;</tt> is modeled.</ins>
<p/>
-4- <i>Effects:</i> Assigns <tt>u.<ins>current</ins><del>base()</del></tt> to <tt>current</tt>.
<p/>
-5- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3437" href="https://cplusplus.github.io/LWG/lwg-active.html#3437">3437</a>. <tt>__cpp_lib_polymorphic_allocator</tt> is in the wrong header</h3>
<p><b>Section:</b> 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-04-29 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#version.syn">issues</a> in [version.syn].</p>
<p><b>Discussion:</b></p>
<p>
17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> says that <tt>__cpp_lib_polymorphic_allocator</tt> is also defined in <tt>&lt;memory&gt;</tt>, 
but <tt>std::polymorphic_allocator</tt> is defined in <tt>&lt;memory_resource&gt;</tt>. This seems like an error in 
<a href="https://wg21.link/p1902r1">P1902R1</a>. The macro should be in the same header as the feature it relates to.
</p>

<p><i>[2020-05-09; Reflector prioritization]</i></p>

<p>
Set status to Tentatively Ready after six votes in favour during reflector discussions.
</p>


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

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

<blockquote>
<pre>
[&hellip;]
#define __cpp_lib_parallel_algorithm    201603L <i>// also in &lt;algorithm&gt;, &lt;numeric&gt;</i>
#define __cpp_lib_polymorphic_allocator 201902L <i>// also in &lt;<del>memory</del><ins>memory_resource</ins>&gt;</i>
#define __cpp_lib_quoted_string_io      201304L <i>// also in &lt;iomanip&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3446" href="https://cplusplus.github.io/LWG/lwg-active.html#3446">3446</a>. <tt>indirectly_readable_traits</tt> ambiguity for types with both <tt>value_type</tt> and <tt>element_type</tt></h3>
<p><b>Section:</b> 23.3.2.2 <a href="https://wg21.link/readable.traits">[readable.traits]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-05-15 <b>Last modified:</b> 2020-08-21</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
Per 23.3.2.2 <a href="https://wg21.link/readable.traits">[readable.traits]</a>, <tt>indirectly_readable_traits&lt;T&gt;::value_type</tt> is the same type as
<tt>remove_cv_t&lt;T::value_type&gt;</tt> if it denotes an object type, or <tt>remove_cv_t&lt;T::element_type&gt;</tt>
if it denotes an object type. If both <tt>T::value_type</tt> and <tt>T::element_type</tt> denote types,
<tt>indirectly_readable_traits&lt;T&gt;::value_type</tt> is ill-formed. This was perhaps not the best design,
given that there are iterators in the wild (Boost's unordered containers) that define both nested types.
<tt>indirectly_readable_traits</tt> should tolerate iterators that define both nested types consistently.
</p>

<p><i>[2020-07-17; Priority set to 2 in telecon]</i></p>


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

<ol>
<li><p>Modify 23.3.2.2 <a href="https://wg21.link/readable.traits">[readable.traits]</a> as indicated:</p>

<blockquote>
<pre>
[&hellip;]
template&lt;class&gt; struct <i>cond-value-type</i> { }; <i>// exposition only</i>

template&lt;class T&gt;
  requires is_object_v&lt;T&gt;
struct <i>cond-value-type</i>&lt;T&gt; {
  using value_type = remove_cv_t&lt;T&gt;;
};

template&lt;class&gt; struct indirectly_readable_traits { };

[&hellip;]

template&lt;class T&gt;
  requires requires { typename T::value_type; }
struct indirectly_readable_traits&lt;T&gt;
  : <i>cond-value-type</i>&lt;typename T::value_type&gt; { };

template&lt;class T&gt;
  requires requires { typename T::element_type; }
struct indirectly_readable_traits&lt;T&gt;
  : <i>cond-value-type</i>&lt;typename T::element_type&gt; { };

<ins>template&lt;class T&gt;</ins>
  <ins>requires requires {</ins>
    <ins>typename T::element_type;</ins>
    <ins>typename T::value_type;</ins>
    <ins>requires same_as&lt;</ins>
      <ins>remove_cv_t&lt;typename T::element_type&gt;,</ins>
      <ins>remove_cv_t&lt;typename T::value_type&gt;&gt;;</ins>
  <ins>}</ins>
<ins>struct indirectly_readable_traits&lt;T&gt;</ins>
  <ins>: <i>cond-value-type</i>&lt;typename T::value_type&gt; { };</ins>

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

</ol>
</blockquote>

<p><i>[2020-07-23; Casey improves wording per reflector discussion]</i></p>


<p><i>[2020-08-21; moved to Tentatively Ready after five votes in favour in reflector poll]</i></p>




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

<ol>
<li><p>Modify 23.3.2.2 <a href="https://wg21.link/readable.traits">[readable.traits]</a> as indicated:</p>

<blockquote>
<pre>
[&hellip;]
template&lt;class&gt; struct <i>cond-value-type</i> { }; <i>// exposition only</i>

template&lt;class T&gt;
  requires is_object_v&lt;T&gt;
struct <i>cond-value-type</i>&lt;T&gt; {
  using value_type = remove_cv_t&lt;T&gt;;
};

<ins>template&lt;class T&gt;</ins>
<ins>concept <i>has-member-value-type</i> = requires { typename T::value_type; }; <i>// exposition only</i></ins>

<ins>template&lt;class T&gt;</ins>
<ins>concept <i>has-member-element-type</i> = requires { typename T::element_type; }; <i>// exposition only</i></ins>

template&lt;class&gt; struct indirectly_readable_traits { };

[&hellip;]

template&lt;<del>class</del><ins><i>has-member-value-type</i></ins> T&gt;
  <del>requires requires { typename T::value_type; }</del>
struct indirectly_readable_traits&lt;T&gt;
  : <i>cond-value-type</i>&lt;typename T::value_type&gt; { };

template&lt;<del>class</del><ins><i>has-member-element-type</i></ins> T&gt;
  <del>requires requires { typename T::element_type; }</del>
struct indirectly_readable_traits&lt;T&gt;
  : <i>cond-value-type</i>&lt;typename T::element_type&gt; { };

<ins>template&lt;<del>class</del><ins><i>has-member-value-type</i></ins> T&gt;</ins>
  <ins>requires <i>has-member-element-type</i>&lt;T&gt; &amp;&amp;</ins>
           <ins>same_as&lt;remove_cv_t&lt;typename T::element_type&gt;, remove_cv_t&lt;typename T::value_type&gt;&gt;</ins>
<ins>struct indirectly_readable_traits&lt;T&gt;</ins>
  <ins>: <i>cond-value-type</i>&lt;typename T::value_type&gt; { };</ins>

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

</ol>




<hr>
<h3><a name="3448" href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a>. <tt>transform_view</tt>'s <tt><i>sentinel</i>&lt;false&gt;</tt> not comparable with <tt><i>iterator</i>&lt;true&gt;</tt></h3>
<p><b>Section:</b> 24.7.6.4 <a href="https://wg21.link/range.transform.sentinel">[range.transform.sentinel]</a>, 24.7.11.4 <a href="https://wg21.link/range.join.sentinel">[range.join.sentinel]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-05-26 <b>Last modified:</b> 2020-10-02</p>
<p><b>Priority: </b>1
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.transform.sentinel">issues</a> in [range.transform.sentinel].</p>
<p><b>Discussion:</b></p>
<p>
A user reported that this doesn't compile:
</p>
<blockquote><pre>
#include &lt;list&gt;
#include &lt;ranges&gt;

std::list v{1, 2}; // works if std::vector
auto view1 = v | std::views::take(2);
auto view2 = view1 | std::views::transform([] (int i) { return i; });
bool b = std::ranges::cbegin(view2) == std::ranges::end(view2);
</pre></blockquote>
<p>
The comparison is supposed to use <tt>operator==(<i>iterator</i>&lt;Const&gt;, <i>sentinel</i>&lt;Const&gt;)</tt> 
after converting <tt><i>sentinel</i>&lt;false&gt;</tt> to <tt><i>sentinel</i>&lt;true&gt;</tt>. However, the 
<tt>operator==</tt> is a hidden friend so is not a candidate when comparing <tt><i>iterator</i>&lt;true&gt;</tt> 
with <tt><i>sentinel</i>&lt;false&gt;</tt>. The required conversion would only happen if we'd found the operator, 
but we can't find the operator until after the conversion happens.
<p/>
As Patrick noted, the <tt>join_view</tt> sentinel has a similar problem.
<p/>
The proposed wording shown below has been suggested by Casey and has been implemented and tested in GCC's libstdc++.
</p>

<p><i>[2020-07-17; Priority set to 1 in telecon]</i></p>

<p>
Should be considered together with <a href="https://cplusplus.github.io/LWG/lwg-active.html#3406">3406</a> and <a href="https://cplusplus.github.io/LWG/lwg-active.html#3449">3449</a>.
</p>

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

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> The project editor is kindly asked to consider replacing editorially all of the
<p/>
"<tt>using <i>Base</i> = conditional_t&lt;Const, const V, V&gt;;</tt>"
<p/> 
occurrences by
<p/>
"<tt>using <i>Base</i> = <i>maybe-const</i>&lt;Const, V&gt;;</tt>"
<p/>
]
</p>
</blockquote>

<blockquote>
<pre>
[&hellip;]
namespace std::ranges {
[&hellip;]
  namespace views { inline constexpr <i>unspecified</i> filter = <i>unspecified</i>; }
  
  <ins>template&lt;bool Const, class T&gt;</ins>
    <ins>using <i>maybe-const</i> = conditional_t&lt;Const, const T, T&gt;; <i>// exposition-only</i></ins>
  
  <i>// 24.7.6 <a href="https://wg21.link/range.transform">[range.transform]</a>, transform view</i>
  template&lt;input_range V, copy_constructible F&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
             regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt;
  class transform_view;
[&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 24.7.6.4 <a href="https://wg21.link/range.transform.sentinel">[range.transform.sentinel]</a>, class template <tt>transform_view::<i>sentinel</i></tt> 
synopsis, as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, copy_constructible F&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
             regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt; &amp;&amp;
             <i>can-reference</i>&lt;invoke_result_t&lt;F&amp;, range_reference_t&lt;V&gt;&gt;&gt;
  template&lt;bool Const&gt;
  class transform_view&lt;V, F&gt;::<i>sentinel</i> {
    [&hellip;]
    constexpr sentinel_t&lt;<i>Base</i>&gt; base() const;
    
    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
    friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);
    
    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
    friend constexpr range_difference_t&lt;<i>Base</i>&gt;
      operator-(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y)
        <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;

    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
    friend constexpr range_difference_t&lt;<i>Base</i>&gt;
      operator-(const <i>sentinel</i>&amp; y, const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x)
        <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> == y.<i>end_</i>;</tt>
</p>
</blockquote>
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
friend constexpr range_difference_t&lt;<i>Base</i>&gt;
  operator-(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y)
    <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> - y.<i>end_</i>;</tt>
</p>
</blockquote>
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
friend constexpr range_difference_t&lt;<i>Base</i>&gt;
  operator-(const <i>sentinel</i>&amp; y, const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x)
    <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> Equivalent to: <tt>return y.<i>end_</i> - x.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>


<li><p>Modify 24.7.11.4 <a href="https://wg21.link/range.join.sentinel">[range.join.sentinel]</a>, class template <tt>join_view::<i>sentinel</i></tt> 
synopsis, as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V&gt;
    requires view&lt;V&gt; &amp;&amp; input_range&lt;range_reference_t&lt;V&gt;&gt; &amp;&amp;
             (is_reference_v&lt;range_reference_t&lt;V&gt;&gt; ||
             view&lt;range_value_t&lt;V&gt;&gt;)
  template&lt;bool Const&gt;
  class join_view&lt;V&gt;::<i>sentinel</i> {
    [&hellip;]

    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
    friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);  
};
}
</pre>
</blockquote>
[&hellip;]
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);  
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Equivalent to: <tt>return x.<i>outer_</i> == y.<i>end_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2020-08-21 Tim updates PR per telecon discussion]</i></p>

<p>As noted in the PR of LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3406">3406</a>, the return type of <tt>operator-</tt>
should be based on the constness of the iterator rather than that of the sentinel, as
<tt>sized_sentinel_for&lt;S, I&gt;</tt> (23.3.4.8 <a href="https://wg21.link/iterator.concept.sizedsentinel">[iterator.concept.sizedsentinel]</a>)
requires <tt>decltype(i - s)</tt> to be <tt>iter_difference_t&lt;I&gt;</tt>.</p>

<p><i>[2020-10-02; Status to Tentatively Ready after five positive votes on the reflector]</i></p>




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

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> The project editor is kindly asked to consider replacing editorially all of the
<p/>
"<tt>using <i>Base</i> = conditional_t&lt;Const, const V, V&gt;;</tt>"
<p/> 
occurrences by
<p/>
"<tt>using <i>Base</i> = <i>maybe-const</i>&lt;Const, V&gt;;</tt>"
<p/>
]
</p>
</blockquote>

<blockquote>
<pre>
[&hellip;]
namespace std::ranges {
[&hellip;]
  namespace views { inline constexpr <i>unspecified</i> filter = <i>unspecified</i>; }
  
  <ins>template&lt;bool Const, class T&gt;</ins>
    <ins>using <i>maybe-const</i> = conditional_t&lt;Const, const T, T&gt;; <i>// exposition-only</i></ins>
  
  <i>// 24.7.6 <a href="https://wg21.link/range.transform">[range.transform]</a>, transform view</i>
  template&lt;input_range V, copy_constructible F&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
             regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt;
  class transform_view;
[&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 24.7.6.4 <a href="https://wg21.link/range.transform.sentinel">[range.transform.sentinel]</a>, class template <tt>transform_view::<i>sentinel</i></tt> 
synopsis, as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, copy_constructible F&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
             regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt; &amp;&amp;
             <i>can-reference</i>&lt;invoke_result_t&lt;F&amp;, range_reference_t&lt;V&gt;&gt;&gt;
  template&lt;bool Const&gt;
  class transform_view&lt;V, F&gt;::<i>sentinel</i> {
    [&hellip;]
    constexpr sentinel_t&lt;<i>Base</i>&gt; base() const;
    
    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
    friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);
    
    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
    friend constexpr range_difference_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;
      operator-(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y)
        <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;

    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
    friend constexpr range_difference_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;
      operator-(const <i>sentinel</i>&amp; y, const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x)
        <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> == y.<i>end_</i>;</tt>
</p>
</blockquote>
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
friend constexpr range_difference_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;
  operator-(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y)
    <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> - y.<i>end_</i>;</tt>
</p>
</blockquote>
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins> 
friend constexpr range_difference_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;
  operator-(const <i>sentinel</i>&amp; y, const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x)
    <del>requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> Equivalent to: <tt>return y.<i>end_</i> - x.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>


<li><p>Modify 24.7.11.4 <a href="https://wg21.link/range.join.sentinel">[range.join.sentinel]</a>, class template <tt>join_view::<i>sentinel</i></tt> 
synopsis, as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V&gt;
    requires view&lt;V&gt; &amp;&amp; input_range&lt;range_reference_t&lt;V&gt;&gt; &amp;&amp;
             (is_reference_v&lt;range_reference_t&lt;V&gt;&gt; ||
             view&lt;range_value_t&lt;V&gt;&gt;)
  template&lt;bool Const&gt;
  class join_view&lt;V&gt;::<i>sentinel</i> {
    [&hellip;]

    <ins>template&lt;bool OtherConst&gt;</ins>
      <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
    friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);  
};
}
</pre>
</blockquote>
[&hellip;]
<pre>
<ins>template&lt;bool OtherConst&gt;</ins>
  <ins>requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;</ins>
friend constexpr bool operator==(const <i>iterator</i>&lt;<ins>Other</ins>Const&gt;&amp; x, const <i>sentinel</i>&amp; y);  
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Equivalent to: <tt>return x.<i>outer_</i> == y.<i>end_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3449" href="https://cplusplus.github.io/LWG/lwg-active.html#3449">3449</a>. <tt>take_view</tt> and <tt>take_while_view</tt>'s <tt><i>sentinel</i>&lt;false&gt;</tt> not comparable with their const iterator</h3>
<p><b>Section:</b> 24.7.7.3 <a href="https://wg21.link/range.take.sentinel">[range.take.sentinel]</a>, 24.7.8.3 <a href="https://wg21.link/range.take.while.sentinel">[range.take.while.sentinel]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-06-06 <b>Last modified:</b> 2020-10-02</p>
<p><b>Priority: </b>1
</p>
<p><b>Discussion:</b></p>
<p>
During reflector discussion it was noted that the issue observed in
LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a> applies to <tt>take_view::<i>sentinel</i></tt>
and <tt>take_while_view::<i>sentinel</i></tt> as well.
</p>

<p><i>[2020-06-15 Tim corrects a typo in the PR]</i></p>


<p><i>[2020-10-02; Priority set to 1 in telecon]</i></p>

<p>
Should be considered together with <a href="https://cplusplus.github.io/LWG/lwg-active.html#3406">3406</a> and <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a>.
</p>

<p><i>[2020-10-02; Status to Tentatively Ready after five positive votes on the reflector]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4861">N4861</a>. It assumes
the <tt><i>maybe-const</i></tt> helper introduced by the P/R of LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a>.</p>

<ol>
<li><p>Modify 24.7.7.3 <a href="https://wg21.link/range.take.sentinel">[range.take.sentinel]</a> as indicated:</p>

<blockquote class="note"> 
<p>
[<i>Drafting note</i>: Unlike LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3448">3448</a>, these operators can't be easily templatized,
so the approach taken here is to add an overload for the opposite constness instead.
However, because <tt>const V</tt> may not even be a range (and therefore
<tt>iterator_t&lt;const V&gt;</tt> may not be well-formed), we need to defer
instantiating the signature of the new overload until the point of use. ]
</p>
</blockquote>
<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;view V&gt;
  template&lt;bool Const&gt;
  class take_view&lt;V&gt;::<i>sentinel</i> {
  private:
    using <i>Base</i> = conditional_t&lt;Const, const V, V&gt;;  // exposition only
    <ins>template&lt;bool OtherConst&gt;</ins>
    using <i>CI</i> = counted_iterator&lt;iterator_t&lt;<del><i>Base</i></del><ins><i>maybe-const</i>&lt;OtherConst, V&gt;</ins>&gt;&gt;;  // exposition only

    [&hellip;]

    constexpr sentinel_t&lt;<i>Base</i>&gt; base() const;

    friend constexpr bool operator==(const <i>CI</i><ins>&lt;Const&gt;</ins>&amp; y, const <i>sentinel</i>&amp; x);
    <ins>
    template&lt;bool OtherConst = !Const&gt;
        requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;
    friend constexpr bool operator==(const <i>CI</i>&lt;OtherConst&gt;&amp; y, const <i>sentinel</i>&amp; x);
    </ins>
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
friend constexpr bool operator==(const <i>CI</i><ins>&lt;Const&gt;</ins>&amp; y, const <i>sentinel</i>&amp; x);
<ins>
template&lt;bool OtherConst = !Const&gt;
    requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;
friend constexpr bool operator==(const <i>CI</i>&lt;OtherConst&gt;&amp; y, const <i>sentinel</i>&amp; x);
</ins>
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Equivalent to: <tt>return y.count() == 0 || y.base() == x.<i>end_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>
<li><p>Modify 24.7.8.3 <a href="https://wg21.link/range.take.while.sentinel">[range.take.while.sentinel]</a> as indicated:</p>
<blockquote>
<blockquote>
<pre>
namespace std::ranges {
    template&lt;view V, class Pred&gt;
    requires input_range&lt;V&gt; &amp;&amp; is_object_v&lt;Pred&gt; &amp;&amp;
                indirect_unary_predicate&lt;const Pred, iterator_t&lt;V&gt;&gt;
    template&lt;bool Const&gt;
    class take_while_view&lt;V&gt;::<i>sentinel</i> {
      [&hellip;]

      constexpr sentinel_t&lt;<i>Base</i>&gt; base() const { return <i>end_</i>; }

      friend constexpr bool operator==(const iterator_t&lt;<i>Base</i>&gt;&amp; x, const <i>sentinel</i>&amp; y);
      <ins>
      template&lt;bool OtherConst = !Const&gt;
          requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;
      friend constexpr bool operator==(const iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&amp; x, const <i>sentinel</i>&amp; y);
      </ins>
    };
}
</pre>
</blockquote>
[&hellip;]
<pre>
friend constexpr bool operator==(const iterator_t&lt;<i>Base</i>&gt;&amp; x, const <i>sentinel</i>&amp; y);
<ins>
template&lt;bool OtherConst = !Const&gt;
    requires sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&gt;
friend constexpr bool operator==(const iterator_t&lt;<i>maybe-const</i>&lt;OtherConst, V&gt;&gt;&amp; x, const <i>sentinel</i>&amp; y);
</ins>
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Equivalent to: <tt>return y.<i>end_</i> == x || !invoke(*y.<i>pred_</i>, *x);</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3453" href="https://cplusplus.github.io/LWG/lwg-active.html#3453">3453</a>. Generic code cannot call <tt>ranges::advance(i, s)</tt></h3>
<p><b>Section:</b> 23.4.4.2 <a href="https://wg21.link/range.iter.op.advance">[range.iter.op.advance]</a>, 23.3.4.7 <a href="https://wg21.link/iterator.concept.sentinel">[iterator.concept.sentinel]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-06-18 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.iter.op.advance">active issues</a> in [range.iter.op.advance].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.iter.op.advance">issues</a> in [range.iter.op.advance].</p>
<p><b>Discussion:</b></p>
<p>
The specification of the iterator &amp; sentinel overload of <tt>ranges::advance</tt> in 23.4.4.2 <a href="https://wg21.link/range.iter.op.advance">[range.iter.op.advance]</a> reads:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<pre>
template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
  constexpr void ranges::advance(I&amp; i, S bound);
</pre>
<p>
-3- <i>Preconditions:</i> <tt>[i, bound)</tt> denotes a range.
<p/>
-4- <i>Effects:</i>
</p>
<ol style="list-style-type: none">
<li><p>(4.1) &mdash; If <tt>I</tt> and <tt>S</tt> model <tt>assignable_from&lt;I&amp;, S&gt;</tt>, equivalent to 
<tt>i = std::move(bound)</tt>.</p></li>
<li><p>(4.2) &mdash; [&hellip;]</p></li>
</ol>
</blockquote>

<p>
The assignment optimization in bullet 4.1 is just fine for callers with concrete types who can decide whether 
or not to call <tt>advance</tt> depending on the semantics of the assignment performed. However, since this assignment 
operation isn't part of the <tt>input_or_output_iterator</tt> or <tt>sentinel_for</tt> requirements its semantics 
are unknown for arbitrary types. Effectively, generic code is forbidden to call this overload of <tt>advance</tt> when 
<tt>assignable_from&lt;I&amp;, S&gt;</tt> is satisfied and non-generic code must tread lightly. This seems to 
make the library dangerously unusable.

We can correct this problem by either:
</p>
<ol style="list-style-type: upper-alpha">
<li><p>Making the assignment operation in question an optional part of the <tt>sentinel_for</tt> concept with well-defined 
semantics. This concept change should be relatively safe given that <tt>assignable_from&lt;I&amp;, S&gt;</tt> 
requires <tt>common_reference_with&lt;const I&amp;, const S&amp;&gt;</tt>, which is very rarely satisfied 
inadvertently.</p></li>
<li><p>Requiring instead <tt>same_as&lt;I, S&gt;</tt> to trigger the assignment optimization in bullet 4.1 above. 
<tt>S</tt> is <tt>semiregular</tt>, so <tt>i = std::move(s)</tt> is certainly well-formed (and has well-defined 
semantics thanks to <tt>semiregular</tt>) when <tt>I</tt> and <tt>S</tt> are the same type. The optimization will 
not apply in as many cases, but we don't need to make a scary concept change, either.</p></li>
</ol>

<p><i>[2020-06-26; Reflector prioritization]</i></p>

<p>
Set priority to 2 after reflector discussions.
</p>
<p><i>[2020-08-21; Issue processing telecon: Option A is Tentatively Ready]</i></p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
This wording is relative to <a href="https://wg21.link/n4861">N4861</a>. 
</p>
<p>
Wording for both <b>Option A</b> and <b>Option B</b> are provided.
</p>

<p><b>Option A</b>:</p>

<ol>
<li><p>Modify 23.3.4.7 <a href="https://wg21.link/iterator.concept.sentinel">[iterator.concept.sentinel]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class S, class I&gt;
  concept sentinel_for =
    semiregular&lt;S&gt; &amp;&amp;
    input_or_output_iterator&lt;I&gt; &amp;&amp;
    <i>weakly-equality-comparable-with</i>&lt;S, I&gt;; <i>// See 18.5.3 <a href="https://wg21.link/concept.equalitycomparable">[concept.equalitycomparable]</a></i>
</pre>
<blockquote>
<p>
-2- Let <tt>s</tt> and <tt>i</tt> be values of type <tt>S</tt> and <tt>I</tt> such that <tt>[i, s)</tt> denotes a range. 
Types <tt>S</tt> and <tt>I</tt> model <tt>sentinel_for&lt;S, I&gt;</tt> only if
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; <tt>i == s</tt> is well-defined.</p></li>
<li><p>(2.2) &mdash; If <tt>bool(i != s)</tt> then <tt>i</tt> is dereferenceable and <tt>[++i, s)</tt> denotes a range.</p></li>
<li><p><ins>(2.?) &mdash; <tt>assignable_from&lt;I&amp;, S&gt;</tt> is either modeled or not satisfied.</ins></p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>

<p><b>Option B</b>:</p>

<ol>
<li><p>Modify 23.4.4.2 <a href="https://wg21.link/range.iter.op.advance">[range.iter.op.advance]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
  constexpr void ranges::advance(I&amp; i, S bound);
</pre>
<blockquote>
<p>
-3- <i>Preconditions:</i> <tt>[i, bound)</tt> denotes a range.
<p/>
-4- <i>Effects:</i>
</p>
<ol style="list-style-type: none">
<li><p>(4.1) &mdash; If <tt>I</tt> and <tt>S</tt> model <tt><del>assignable_from&lt;I&amp;, 
S&gt;</del><ins>same_as&lt;I, S&gt;</ins></tt>, equivalent to <tt>i = std::move(bound)</tt>.</p></li>
<li><p>(4.2) &mdash; [&hellip;]</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>


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

<ol>
<li><p>Modify 23.3.4.7 <a href="https://wg21.link/iterator.concept.sentinel">[iterator.concept.sentinel]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class S, class I&gt;
  concept sentinel_for =
    semiregular&lt;S&gt; &amp;&amp;
    input_or_output_iterator&lt;I&gt; &amp;&amp;
    <i>weakly-equality-comparable-with</i>&lt;S, I&gt;; <i>// See 18.5.3 <a href="https://wg21.link/concept.equalitycomparable">[concept.equalitycomparable]</a></i>
</pre>
<blockquote>
<p>
-2- Let <tt>s</tt> and <tt>i</tt> be values of type <tt>S</tt> and <tt>I</tt> such that <tt>[i, s)</tt> denotes a range. 
Types <tt>S</tt> and <tt>I</tt> model <tt>sentinel_for&lt;S, I&gt;</tt> only if
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; <tt>i == s</tt> is well-defined.</p></li>
<li><p>(2.2) &mdash; If <tt>bool(i != s)</tt> then <tt>i</tt> is dereferenceable and <tt>[++i, s)</tt> denotes a range.</p></li>
<li><p><ins>(2.?) &mdash; <tt>assignable_from&lt;I&amp;, S&gt;</tt> is either modeled or not satisfied.</ins></p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3455" href="https://cplusplus.github.io/LWG/lwg-active.html#3455">3455</a>. Incorrect <i>Postconditions</i> on <tt>unique_ptr</tt> move assignment</h3>
<p><b>Section:</b> 20.11.1.3.4 <a href="https://wg21.link/unique.ptr.single.asgn">[unique.ptr.single.asgn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2020-06-22 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#unique.ptr.single.asgn">issues</a> in [unique.ptr.single.asgn].</p>
<p><b>Discussion:</b></p>
<p>
20.11.1.3.4 <a href="https://wg21.link/unique.ptr.single.asgn">[unique.ptr.single.asgn]</a>/p5 says this about the <tt>unique_ptr</tt> move assignment operator:
</p>
<blockquote>
<p>
<i>Postconditions:</i> <tt>u.get() == nullptr</tt>.
</p>
</blockquote>
<p>
But this is only true if <tt>this != &amp;u</tt>. For example:
</p>
<blockquote>
<pre>
#include &lt;iostream&gt;
#include &lt;memory&gt;

int main()
{
  auto x = std::unique_ptr&lt;int&gt;(new int{3});
  x = std::move(x);
  if (x)
    std::cout &lt;&lt; *x &lt;&lt; '\n';
  else
    std::cout &lt;&lt; "nullptr\n";
}
</pre>
</blockquote>
<p>
Output:
</p>
<blockquote>
<pre>
3
</pre>
</blockquote>
<p>
An alternative resolution to that proposed below is to just delete the <i>Postcondition</i> altogether as 
the <i>Effects</i> element completely specifies everything. If we do that, then we should also remove p10, 
the <i>Postconditions</i> element for the converting move assignment operator. I have a slight preference 
for the proposed change below as it is more informative, at the expense of being a little more repetitive.
</p>

<p><i>[2020-06-26; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after seven votes in favor during reflector discussions.
</p>


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

<ol>
<li><p>Modify 20.11.1.3.4 <a href="https://wg21.link/unique.ptr.single.asgn">[unique.ptr.single.asgn]</a> as indicated:</p>

<blockquote>
<pre>
unique_ptr&amp; operator=(unique_ptr&amp;&amp; u) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Constraints:</i> <tt>is_move_assignable_v&lt;D&gt;</tt> is <tt>true</tt>.
<p/>
-2- <i>Preconditions:</i> If <tt>D</tt> is not a reference type, <tt>D</tt> meets the 
<i>Cpp17MoveAssignable</i> requirements (Table [tab:cpp17.moveassignable]) and assignment of the 
deleter from an rvalue of type <tt>D</tt> does not throw an exception. Otherwise, <tt>D</tt> is a
reference type; <tt>remove_reference_t&lt;D&gt;</tt> meets the <i>Cpp17CopyAssignable</i> 
requirements and assignment of the deleter from an lvalue of type <tt>D</tt> does not throw an exception.
<p/>
-3- <i>Effects:</i> Calls <tt>reset(u.release())</tt> followed by <tt>get_deleter() = std::forward&lt;D&gt;(u.get_deleter())</tt>.
<p/>
-4- <i>Returns:</i> <tt>*this</tt>.
<p/>
-5- <i>Postconditions:</i> <ins>If <tt>this != addressof(u)</tt>,</ins> <tt>u.get() == nullptr</tt><ins>, 
otherwise <tt>u.get()</tt> is unchanged</ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3460" href="https://cplusplus.github.io/LWG/lwg-active.html#3460">3460</a>. Unimplementable <tt>noop_coroutine_handle</tt> guarantees</h3>
<p><b>Section:</b> 17.12.5.2.2 <a href="https://wg21.link/coroutine.handle.noop.resumption">[coroutine.handle.noop.resumption]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-07-01 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
17.12.5.2.2 <a href="https://wg21.link/coroutine.handle.noop.resumption">[coroutine.handle.noop.resumption]</a>/2 states "<i>Remarks:</i> If <tt>noop_coroutine_handle</tt> 
is converted to <tt>coroutine_handle&lt;&gt;</tt>, calls to <tt>operator()</tt>, <tt>resume</tt> and 
<tt>destroy</tt> on that handle will also have no observable effects." This suggests that e.g. in this function:
</p>
<blockquote><pre>
void f(coroutine_handle&lt;&gt; meow) 
{
  auto woof = noop_coroutine();
  static_cast&lt;coroutine_handle&lt;&gt;&amp;&gt;(woof) = meow;
  static_cast&lt;coroutine_handle&lt;&gt;&amp;&gt;(woof).resume();
}
</pre></blockquote>
<p>
the final call to <tt>coroutine_handle&lt;&gt;::resume</tt> must have no effect regardless of what 
coroutine (if any) <tt>meow</tt> refers to, contradicting the specification of 
<tt>coroutine_handle&lt;&gt;::resume</tt>. Even absent this contradiction, implementing the specification 
requires <tt>coroutine_handle&lt;&gt;::resume</tt> to determine if <tt>*this</tt> is a base subobject of a 
<tt>noop_coroutine_handle</tt>, which seems pointlessly expensive to implement.
<p/>
17.12.5.2.4 <a href="https://wg21.link/coroutine.handle.noop.address">[coroutine.handle.noop.address]</a>/2 states "<i>Remarks:</i> A <tt>noop_coroutine_handle</tt>'s 
<tt>ptr</tt> is always a non-null pointer value." Similar to the above case, a slicing assignment of a 
default-initialized <tt>coroutine_handle&lt;&gt;</tt> to a <tt>noop_coroutine_handle</tt> must result in 
<tt>ptr</tt> having a null pointer value &mdash; another contradiction between the requirements of 
<tt>noop_coroutine_handle</tt> and <tt>coroutine_handle&lt;&gt;</tt>.
</p>

<p><i>[2020-07-12; Reflector prioritization]</i></p>

<p>
Set priority to 2 after reflector discussions.
</p>

<p><i>[2020-07-29 Tim adds PR and comments]</i></p>

<p>
The root cause for this issue as well as issue <a href="https://cplusplus.github.io/LWG/lwg-active.html#3469">3469</a> is the unnecessary 
public derivation from <tt>coroutine_handle&lt;void&gt;</tt>. The proposed resolution below
replaces the derivation with a conversion function and adds explicit declarations for
members that were previously inherited. It also modifies the preconditions
on <tt>from_address</tt> with goal of making it impossible to obtain a <tt>coroutine_handle&lt;P&gt;</tt>
to a coroutine whose promise type is not <tt>P</tt> in well-defined code.
</p>

<p><i>[2020-08-21; Issue processing telecon: moved to Tentatively Ready]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/n4861">N4861</a> and also resolves
LWG issue <a href="https://cplusplus.github.io/LWG/lwg-active.html#3469">3469</a>. 
</p>

<ol>
<li><p> Edit 17.12.4 <a href="https://wg21.link/coroutine.handle">[coroutine.handle]</a> as indicated:</p>
<blockquote>
<pre>
namespace std {

  [&hellip;]

  template&lt;class Promise&gt;
  struct coroutine_handle <del>: coroutine_handle&lt;&gt;</del>
  {
    // [coroutine.handle.con], construct/reset
<del>    using coroutine_handle&lt;&gt;::coroutine_handle;</del>
<ins>    constexpr coroutine_handle() noexcept;
    constexpr coroutine_handle(nullptr_t) noexcept;</ins>
    static coroutine_handle from_promise(Promise&amp;);
    coroutine_handle&amp; operator=(nullptr_t) noexcept;
  
    // [coroutine.handle.export.import], export/import
<ins>    constexpr void* address() const noexcept;</ins>
    static constexpr coroutine_handle from_address(void* addr);
  
<ins>    // [coroutine.handle.conv], conversion
    constexpr operator coroutine_handle&lt;&gt;() const noexcept;
  
    // [coroutine.handle.observers], observers
    constexpr explicit operator bool() const noexcept;
    bool done() const;
  
    // [coroutine.handle.resumption], resumption
    void operator()() const;
    void resume() const;
    void destroy() const;</ins>
  
    // [coroutine.handle.promise], promise access
    Promise&amp; promise() const;
  
<ins>  private:
    void* ptr;  // <i>exposition only</i> </ins>
  };
}
</pre>

<p> -1- An object of type <tt>coroutine_­handle&lt;T&gt;</tt> is called a <i>coroutine handle</i>
and can be used to refer to a suspended or executing coroutine.
A <del>default-constructed</del> <tt>coroutine_­handle</tt> object <ins>whose member <tt>address()</tt>
returns a null pointer value</ins> does not refer to any coroutine.
<ins>Two <tt>coroutine_handle</tt> objects refer to the same coroutine if and only if their
member <tt>address()</tt> returns the same value.</ins>
</p>
</blockquote>
</li>
<li>
<p>Add the following subclause under 17.12.4 <a href="https://wg21.link/coroutine.handle">[coroutine.handle]</a>, immediately after 17.12.4.2 <a href="https://wg21.link/coroutine.handle.con">[coroutine.handle.con]</a>:</p>
<blockquote>
<p>
<ins><b>?.?.?.? Conversion [coroutine.handle.conv]</b></ins>
</p>
<pre>
    <ins>constexpr operator coroutine_handle&lt;&gt;() const noexcept;</ins>
</pre>
<blockquote>
<p><ins>-1- <i>Effects:</i> Equivalent to: <tt>return coroutine_handle&lt;&gt;::from_address(address());</tt>.</ins></p>
</blockquote>
</blockquote>
</li>
<li>
<p> Edit 17.12.4.3 <a href="https://wg21.link/coroutine.handle.export.import">[coroutine.handle.export.import]</a> as indicated, splitting the two versions:</p>
<blockquote>
<pre>
static constexpr coroutine_handle&lt;&gt; coroutine_handle&lt;&gt;::from_address(void* addr);
</pre>
<blockquote>
<p><ins>-?- <i>Preconditions:</i> <tt>addr</tt> was obtained via a prior call to <tt>address</tt> on
an object whose type is a specialization of <tt>coroutine_handle</tt>.</ins>
<p/>
<ins>-?- <i>Postconditions:</i> <tt>from_­address(address()) == *this</tt>.</ins>
</p>
</blockquote>
<pre>
static constexpr coroutine_handle&lt;Promise&gt; coroutine_handle&lt;Promise&gt;::from_address(void* addr);
</pre>
<blockquote>
<p>
-2- <i>Preconditions:</i> <tt>addr</tt> was obtained via a prior call to <tt>address</tt>
<ins>on an object of type <i>cv</i> <tt>coroutine_handle&lt;Promise&gt;</tt></ins>.
<p/>
-3- <i>Postconditions:</i> <tt>from_­address(address()) == *this</tt>.
</p>
</blockquote>
</blockquote>
</li>
<li>
<p>Edit 17.12.5.2 <a href="https://wg21.link/coroutine.handle.noop">[coroutine.handle.noop]</a> as indicated:</p>
<blockquote>
<pre>
namespace std {
  template&lt;&gt;
  struct coroutine_handle&lt;noop_coroutine_promise&gt; <del>: coroutine_handle&lt;&gt;</del>
  {
<ins>    // [coroutine.handle.noop.conv], conversion
    constexpr operator coroutine_handle&lt;&gt;() const noexcept;</ins>

    // [coroutine.handle.noop.observers], observers
    constexpr explicit operator bool() const noexcept;
    constexpr bool done() const noexcept;

    // [coroutine.handle.noop.resumption], resumption
    constexpr void operator()() const noexcept;
    constexpr void resume() const noexcept;
    constexpr void destroy() const noexcept;

    // [coroutine.handle.noop.promise], promise access
    noop_coroutine_promise&amp; promise() const noexcept;

    // [coroutine.handle.noop.address], address
    constexpr void* address() const noexcept;
  
  private:
    coroutine_handle(unspecified);
<ins>    void* ptr; // <i>exposition only</i> </ins>
  };
}
</pre>
</blockquote>
</li>
<li>
<p>Add the following subclause under 17.12.5.2 <a href="https://wg21.link/coroutine.handle.noop">[coroutine.handle.noop]</a>, immediately before 17.12.5.2.1 <a href="https://wg21.link/coroutine.handle.noop.observers">[coroutine.handle.noop.observers]</a>:</p>
<blockquote>
<p>
<ins><b>?.?.?.?.? Conversion [coroutine.handle.noop.conv]</b></ins>
</p>
<pre>
    <ins>constexpr operator coroutine_handle&lt;&gt;() const noexcept;</ins>
</pre>
<blockquote>
<p><ins>-1- <i>Effects:</i> Equivalent to: <tt>return coroutine_handle&lt;&gt;::from_address(address());</tt>.</ins></p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3461" href="https://cplusplus.github.io/LWG/lwg-active.html#3461">3461</a>. <tt>convertible_to</tt>'s description mishandles <i>cv</i>-qualified <tt>void</tt></h3>
<p><b>Section:</b> 18.4.4 <a href="https://wg21.link/concept.convertible">[concept.convertible]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-07-03 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#concept.convertible">active issues</a> in [concept.convertible].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#concept.convertible">issues</a> in [concept.convertible].</p>
<p><b>Discussion:</b></p>
<p>
There are no expressions of type <i>cv</i>-qualified <tt>void</tt> because any such
expression must be prvalues and 7.2.2 <a href="https://wg21.link/expr.type">[expr.type]</a>/2 states:
</p>
<blockquote><p>
If a prvalue initially has the type "<i>cv</i> <tt>T</tt>", where <tt>T</tt> is a
<i>cv</i>-unqualified non-class, non-array type, the type of the expression is adjusted 
to <tt>T</tt> prior to any further analysis.
</p></blockquote>
<p>
However, 18.4.4 <a href="https://wg21.link/concept.convertible">[concept.convertible]</a> p1 states:
</p>
<blockquote><p>
Given types <tt>From</tt> and <tt>To</tt> and an expression <tt>E</tt> such that 
<tt>decltype((E))</tt> is <tt>add_rvalue_reference_t&lt;From&gt;</tt>, 
<tt>convertible_to&lt;From, To&gt;</tt> requires <tt>E</tt> to be both implicitly and 
explicitly convertible to type <tt>To</tt>.
</p></blockquote>
<p>
When <tt>From</tt> is <i>cv</i>-qualified <tt>void</tt>, <tt>E</tt> does not exist, yet we do want
<tt>convertible_to&lt;const void, void&gt;</tt> to be modeled.
</p>

<p><i>[2020-07-12; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after five votes in favour during reflector discussions.
</p>


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

<ol>
<li><p>Modify 18.4.4 <a href="https://wg21.link/concept.convertible">[concept.convertible]</a> as indicated:</p>

<blockquote>
<p>
-1- Given types <tt>From</tt> and <tt>To</tt> and an expression <tt>E</tt> <del>such that <tt>decltype((E))</tt> 
is <tt>add_rvalue_reference_t&lt;From&gt;</tt></del><ins>whose type and value category are the same as those of 
<tt>declval&lt;From&gt;()</tt></ins>, <tt>convertible_to&lt;From, To&gt;</tt> requires <tt>E</tt> 
to be both implicitly and explicitly convertible to type <tt>To</tt>. The implicit and explicit conversions 
are required to produce equal results.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3465" href="https://cplusplus.github.io/LWG/lwg-active.html#3465">3465</a>. <tt>compare_partial_order_fallback</tt> requires <tt>F &lt; E</tt></h3>
<p><b>Section:</b> 17.11.6 <a href="https://wg21.link/cmp.alg">[cmp.alg]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2020-07-18 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#cmp.alg">issues</a> in [cmp.alg].</p>
<p><b>Discussion:</b></p>
<p>
<tt>compare_partial_order_fallback</tt> uses three expressions, but requires only two. The decayed types 
of <tt>E</tt> and <tt>F</tt> are required to be identical, but variations in constness might make a difference.
</p>

<p><i>[2020-07-26; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after seven votes in favour during reflector discussions.
</p>


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

<ol>
<li><p>Modify 17.11.6 <a href="https://wg21.link/cmp.alg">[cmp.alg]</a> as indicated:</p>

<blockquote>
<p>
-6- The name <tt>compare_partial_order_fallback</tt> denotes a customization point object 
(16.3.3.3.6 <a href="https://wg21.link/customization.point.object">[customization.point.object]</a>). Given subexpressions <tt>E</tt> and <tt>F</tt>, 
the expression <tt>compare_partial_order_fallback(E, F)</tt> is expression-equivalent
(3.21 <a href="https://wg21.link/defns.expression-equivalent">[defns.expression-equivalent]</a>) to:
</p>
<ol style="list-style-type: none">
<li><p>(6.1) &mdash; If the decayed types of <tt>E</tt> and <tt>F</tt> differ, 
<tt>compare_partial_order_fallback(E, F)</tt> is ill-formed.</p></li>
<li><p>(6.2) &mdash; Otherwise, <tt>partial_order(E, F)</tt> if it is a well-formed expression.</p></li>
<li><p>(6.3) &mdash; Otherwise, if the expressions <tt>E == F</tt><ins>,</ins> <del>and</del> 
<tt>E &lt; F</tt><ins>, and <tt>F &lt; E</tt></ins> are <ins>all</ins><del>both</del> well-formed 
and convertible to <tt>bool</tt>,</p>
<blockquote>
<pre>
E == F ? partial_ordering::equivalent :
E &lt; F  ? partial_ordering::less :
F &lt; E  ? partial_ordering::greater :
         partial_ordering::unordered
</pre>
</blockquote>
<p>
except that <tt>E</tt> and <tt>F</tt> are evaluated only once.
</p>
</li>
<li><p>(6.4) &mdash; Otherwise, <tt>compare_partial_order_fallback(E, F)</tt> is ill-formed.</p></li></ol>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3466" href="https://cplusplus.github.io/LWG/lwg-active.html#3466">3466</a>. Specify the requirements for <tt>promise</tt>/<tt>future</tt>/<tt>shared_future</tt> consistently</h3>
<p><b>Section:</b> 32.9.6 <a href="https://wg21.link/futures.promise">[futures.promise]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2020-07-18 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
<p><b>Discussion:</b></p>
<p>
The resolution of the LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3458">3458</a> clearly specified the requirement that
<tt>future</tt>/<tt>shared_future</tt> are ill-formed in situations when <tt>T</tt> is native array
or function type. This requirement was not strictly necessary for <tt>future&lt;T&gt;</tt> 
as it was already ill-formed due the signature of the <tt>get</tt> function (that would be 
ill-formed in such case), however it was still added for consistency of specification.
Similar, requirement should be introduced for the <tt>promise&lt;T&gt;</tt>, for which
any call to <tt>get_future()</tt> would be ill-formed, if <tt>T</tt> is of array or function type.
<p/>
[Note: <tt>promise&lt;int[10]&gt;</tt> is ill-formed for libstdc++ and libc++, see
<a href="https://godbolt.org/z/ffTW99">this code</a>]
</p>

<p><i>[2020-07-26; Reflector prioritization]</i></p>

<p>
Set priority to 3 after reflector discussions. Tim Song made the suggestion to replace the P/R wording
by the following alternative wording:
</p>
<blockquote><p>
<ins>For the primary template, <tt>R</tt> shall be an object type that meets the <i>Cpp17Destructible</i> requirements.</ins>
</p></blockquote>

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

<blockquote class="note">
<p>
Ideally the wording below would use a <i>Mandates:</i> element, but due to the still open
issue LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3193">3193</a> the wording below uses instead the more general "ill-formed"
vocabulary.
</p>
</blockquote>

<ol>
<li><p>Modify 32.9.6 <a href="https://wg21.link/futures.promise">[futures.promise]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;class R&gt;
  class promise {
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
<p>
<ins>-?- If <tt>is_array_v&lt;R&gt;</tt> is <tt>true</tt> or <tt>is_function_v&lt;R&gt;</tt> is <tt>true</tt>, 
the program is ill-formed.</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-08-02; Daniel comments and provides alternative wording]</i></p>

<p>
Following the suggestion of Tim Song a revised wording is provided which is intended to replace the currently agreed on wording
for LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3458">3458</a>.
</p>

<p><i>[2020-08-21; Issue processing telecon: Tentatively Ready]</i></p>

<p>
Discussed a note clarifying that <em>Cpp17Destructible</em> disallows
arrays (as well as types without accessible destructors).
Can be added editorially.
</p>



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

<ol>
<li><p>Modify 32.9.6 <a href="https://wg21.link/futures.promise">[futures.promise]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;class R&gt;
  class promise {
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
<p>
<ins>-?- For the primary template, <tt>R</tt> shall be an object type that meets the
<i>Cpp17Destructible</i> requirements.</ins>
<p/>
-1- The implementation provides the template <tt>promise</tt> and two specializations, <tt>promise&lt;R&amp;&gt;</tt> 
and <tt>promise&lt;void&gt;</tt>. These differ only in the argument type of the member functions 
<tt>set_value</tt> and <tt>set_value_at_thread_exit</tt>, as set out in their descriptions, below.
</p>
</blockquote>
</li>

<li><p>Modify 32.9.7 <a href="https://wg21.link/futures.unique.future">[futures.unique.future]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;class R&gt;
  class future {
    [&hellip;]
  };
}
</pre>
</blockquote>
<p>
<ins>-?- For the primary template, <tt>R</tt> shall be an object type that meets the
<i>Cpp17Destructible</i> requirements.</ins>
<p/>
-4- The implementation provides the template <tt>future</tt> and two specializations, <tt>future&lt;R&amp;&gt;</tt> and 
<tt>future&lt;void&gt;</tt>. These differ only in the return type and return value of the member function <tt>get</tt>, 
as set out in its description, below.
</p>
</blockquote>
</li>

<li><p>Modify 32.9.8 <a href="https://wg21.link/futures.shared.future">[futures.shared.future]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;class R&gt;
  class shared_future {
    [&hellip;]
  };
}
</pre>
</blockquote>
<p>
<ins>-?- For the primary template, <tt>R</tt> shall be an object type that meets the
<i>Cpp17Destructible</i> requirements.</ins>
<p/>
-4- The implementation provides the template <tt>shared_future</tt> and two specializations, 
<tt>shared_future&lt;R&amp;&gt;</tt> and <tt>shared_future&lt;void&gt;</tt>. These differ only in the return type 
and return value of the member function <tt>get</tt>, as set out in its description, below.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3467" href="https://cplusplus.github.io/LWG/lwg-active.html#3467">3467</a>. <tt>bool</tt> can't be an integer-like type</h3>
<p><b>Section:</b> 23.3.4.4 <a href="https://wg21.link/iterator.concept.winc">[iterator.concept.winc]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-07-23 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#iterator.concept.winc">active issues</a> in [iterator.concept.winc].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#iterator.concept.winc">issues</a> in [iterator.concept.winc].</p>
<p><b>Discussion:</b></p>
<p>
Per 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>/1, the Standard Library believes it can convert an integer-like type <tt>X</tt>
to an unsigned integer-like type with the exposition-only type alias <tt><i>make-unsigned-like-t</i></tt>.
<tt><i>make-unsigned-like-t</i>&lt;X&gt;</tt> is specified as being equivalent to
<tt>make_unsigned_t&lt;X&gt;</tt> when <tt>X</tt> is an integral type. However, despite being an integral type,
<tt>bool</tt> is not a valid template type argument for <tt>make_unsigned_t</tt> per [tab:meta.trans.sign].
<p/>
This problem with <tt>bool</tt> was an oversight when we added support for integer-like types: it was certainly
not the design intent to allow <tt>ranges::size(r)</tt> to return <tt>false</tt>! While we could devise some
more-complicated metaprogramming to allow use of <tt>bool</tt>, it seems easier &mdash; and consistent with the
design intent &mdash; to simply exclude <tt>bool</tt> from the set of integer-like types.
</p>

<p><i>[2020-08-02; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after six votes in favour during reflector discussions.
</p>


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

<ol>
<li><p>Modify 23.3.4.4 <a href="https://wg21.link/iterator.concept.winc">[iterator.concept.winc]</a> as indicated:</p>

<blockquote>
<p>
-11- A type <tt>I</tt> <ins>other than <tt><i>cv</i> bool</tt></ins> is <i>integer-like</i> if it models <tt>integral&lt;I&gt;</tt>
or if it is an integer-class type. A<ins>n integer-like</ins> type <tt>I</tt> is <i>signed-integer-like</i> if it
models <tt>signed_integral&lt;I&gt;</tt> or if it is a signed-integer-class type. A<ins>n integer-like</ins>
type <tt>I</tt> is <i>unsigned-integer-like</i> if it models <tt>unsigned_integral&lt;I&gt;</tt> or if it is an
unsigned-integer-class type.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3472" href="https://cplusplus.github.io/LWG/lwg-active.html#3472">3472</a>. <tt>counted_iterator</tt> is missing preconditions</h3>
<p><b>Section:</b> 23.5.6 <a href="https://wg21.link/iterators.counted">[iterators.counted]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Michael Schellenberger Costa <b>Opened:</b> 2020-07-29 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
C++20 introduces a new iterator <tt>counted_iterator</tt> that keeps track of the end of its range via an 
additional exposition only member <tt>length</tt>.  
<p/>
Consequently, there are several preconditions for many member functions of <tt>counted_iterator</tt>, but 
it seems some are missing:
</p>
<ol>
<li><p><b><tt>operator*</tt></b>
<p/>
Here we have no precondition regarding <tt>length</tt>. However, given that <tt>length</tt> denotes the 
distance to the end of the range it should be invalid to dereference a <tt>counted_iterator</tt> with 
<tt>length 0</tt>.
<p/>
Moreover, <tt>operator[]</tt> has a precondition of "<tt>n &lt; length</tt>". Consider the following code snippet:
</p>
<blockquote><pre>
int some_ints[] = {0,1,2};
counted_iterator&lt;int*&gt; i{some_ints, 0};
</pre></blockquote>
<p>
Here "<tt>i[0]</tt>" would be invalid due to the precondition "<tt>n &lt; length</tt>". However, "<tt>*i</tt>" 
would be a valid expression. This violates the definition of <tt>operator[]</tt> which states according to 
7.6.1.2 <a href="https://wg21.link/expr.sub">[expr.sub]</a> p1:
</p>
<blockquote><p>
[&hellip;] The expression <tt>E1[E2]</tt> is identical (by definition) to <tt>*((E1)+(E2))</tt> [&hellip;]
</p></blockquote>
<p>
Substituting <tt>E2-&gt;0</tt> we get  
</p>
<blockquote><p>
[&hellip;] The expression <tt>E1[0]</tt> is identical (by definition) to <tt>*(E1)</tt> [&hellip;]
</p></blockquote>
<p>
With the current wording <tt>counted_iterator</tt> violates that definition and we should add to <tt>operator*</tt>:
</p>
<blockquote><p>
<i>Preconditions:</i> <tt>length &gt; 0</tt>.
</p></blockquote></li>
<li><p><b><tt>iter_move</tt></b>
<p/>
This is a similar case. We have only the <i>Effects</i> element:
</p>
<blockquote><p>
<i>Effects:</i> Equivalent to: <tt>return ranges::iter_move(i.current);</tt>
</p></blockquote>
<p>
However, looking at the requirements of <tt>ranges::iter_move</tt> we have in 23.3.3.1 <a href="https://wg21.link/iterator.cust.move">[iterator.cust.move]</a> p2:
</p>
<blockquote><p>
If <tt>ranges::iter_move(E)</tt> is not equal to <tt>*E</tt>, the program is ill-formed, no diagnostic required.
</p></blockquote>
<p>
This clearly requires that for <tt>counted_iterator::iter_move</tt> to be well-formed,  we need 
<tt>counted_iterator::operator*</tt> to be well formed. Consequently we should also add the same precondition to 
<tt>counted_iterator::iter_move</tt>:
</p>
<blockquote><p>
<i>Preconditions:</i> <tt>length &gt; 0</tt>.
</p></blockquote></li>
<li><p><b><tt>iter_swap</tt></b>
<p/>
This is essentially the same arguing as for <tt>counted_iterator::iter_move</tt>. The essential observation is that 
<tt>ranges::iter_swap</tt> is defined in terms of <tt>ranges::iter_move</tt> (see 23.3.3.2 <a href="https://wg21.link/iterator.cust.swap">[iterator.cust.swap]</a>) 
so it must have the same preconditions and we should add:
</p>
<blockquote><p>
<i>Preconditions:</i> <tt>length &gt; 0</tt>.
</p></blockquote></li>
</ol>
<p><i>[2020-08-21 Issue processing telecon: moved to Tentatively Ready.]</i></p>



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

<ol>
<li><p>Modify 23.5.6.4 <a href="https://wg21.link/counted.iter.elem">[counted.iter.elem]</a> as indicated:</p>

<blockquote>
<pre>
constexpr decltype(auto) operator*();
constexpr decltype(auto) operator*() const
  requires <i>dereferenceable</i>&lt;const I&gt;;
</pre>
<blockquote>
<p>
<ins>-?- <i>Preconditions:</i> <tt>length &gt; 0</tt>.</ins>
<p/>
-1- <i>Effects:</i> Equivalent to: <tt>return *current;</tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 23.5.6.7 <a href="https://wg21.link/counted.iter.cust">[counted.iter.cust]</a> as indicated:</p>

<blockquote>
<pre>
friend constexpr iter_rvalue_reference_t&lt;I&gt;
  iter_move(const counted_iterator&amp; i)
    noexcept(noexcept(ranges::iter_move(i.current)))
    requires input_iterator&lt;I&gt;;
</pre>
<blockquote>
<p>
<ins>-?- <i>Preconditions:</i> <tt>i.length &gt; 0</tt>.</ins>
<p/>
-1- <i>Effects:</i> Equivalent to: <tt>return ranges::iter_move(i.current);</tt>
</p>
</blockquote>
<pre>
template&lt;indirectly_swappable&lt;I&gt; I2&gt;
  friend constexpr void
    iter_swap(const counted_iterator&amp; x, const counted_iterator&lt;I2&gt;&amp; y)
      noexcept(noexcept(ranges::iter_swap(x.current, y.current)));
</pre>
<blockquote>
<p>
<ins>-?- <i>Preconditions:</i> <tt>x.length &gt; 0</tt> and <tt>y.length &gt; 0</tt>.</ins>
<p/>
-1- <i>Effects:</i> Equivalent to: <tt>return ranges::iter_swap(x.current, y.current);</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3473" href="https://cplusplus.github.io/LWG/lwg-active.html#3473">3473</a>. Normative encouragement in non-normative note</h3>
<p><b>Section:</b> 20.20.6.3 <a href="https://wg21.link/format.args">[format.args]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-07-31 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p>
The note in the final paragraph of 20.20.6.3 <a href="https://wg21.link/format.args">[format.args]</a> gives encouragement to implementations, which is not allowed in a note.
<p/>
It needs to be normative text, possibly using "should", or if left as a note could be phrased as "Implementations can optimize 
the representation [&hellip;]". 
</p>

<p><i>[2020-08-09; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after six votes in favour during reflector discussions.
</p>


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

<ol>
<li><p>Modify 20.20.6.3 <a href="https://wg21.link/format.args">[format.args]</a> as indicated:</p>

<blockquote>
<p>
-1- An instance of <tt>basic_format_args</tt> provides access to formatting arguments. <ins>Implementations 
should optimize the representation of <tt>basic_format_args</tt> for a small number of formatting arguments. 
[<i>Note:</i> For example, by storing indices of type alternatives separately from values and packing the 
former. &mdash; <i>end note</i>]</ins>
</p>
<pre>
basic_format_args() noexcept;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> Initializes <tt>size_</tt> with <tt>0</tt>.
</p>
</blockquote>
[&hellip;]
<pre>
basic_format_arg&lt;Context&gt; get(size_t i) const noexcept;
</pre>
<blockquote>
<p>
-4- <i>Returns:</i> <tt>i &lt; size_ ? data_[i] : basic_format_arg&lt;Context&gt;()</tt>.
</p>
</blockquote>
<p>
<del>[<i>Note:</i> Implementations are encouraged to optimize the representation of 
<tt>basic_format_args</tt> for small number of formatting arguments by storing indices of type 
alternatives separately from values and packing the former. &mdash; <i>end note</i>]</del>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3474" href="https://cplusplus.github.io/LWG/lwg-active.html#3474">3474</a>. Nesting <tt>join_view</tt>s is broken because of CTAD</h3>
<p><b>Section:</b> 24.7.11 <a href="https://wg21.link/range.join">[range.join]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2020-08-04 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
Let's say I had a range of range of ranges and I wanted to recursively flatten it. That would involve 
repeated invocations of <tt>join</tt>. But this doesn't work:
</p>
<blockquote><pre>
std::vector&lt;std::vector&lt;std::vector&lt;int&gt;&gt;&gt; nested_vectors = {
  {{1, 2, 3}, {4, 5}, {6}},
  {{7},       {8, 9}, {10, 11, 12}},
  {{13}}
};
auto joined = nested_vectors | std::views::join | std::views::join;
</pre></blockquote>
<p>
The expectation here is that the <tt>value_type</tt> of joined is <tt>int</tt>, but it's actually 
<tt>vector&lt;int&gt;</tt> &mdash; because the 2nd invocation of <tt>join</tt> ends up just copying 
the first. This is because <tt>join</tt> is specified to do:
</p>
<blockquote><p>
The name <tt>views::join</tt> denotes a range adaptor object (24.7.2 <a href="https://wg21.link/range.adaptor.object">[range.adaptor.object]</a>). 
Given a subexpression <tt>E</tt>, the expression <tt>views::join(E)</tt> is expression-equivalent to 
<tt>join_view{E}</tt>.
</p></blockquote>
<p>
And <tt>join_view{E}</tt> for an <tt>E</tt> that's already a specialization of a <tt>join_view</tt> 
just gives you the same <tt>join_view</tt> back. Yay CTAD. We need to do the same thing with <tt>join</tt> 
that we did with <tt>reverse</tt> in <a href="https://wg21.link/p1252">P1252</a>. We can do that either in 
exposition (<b>Option A</b>) my modifying 24.7.11.1 <a href="https://wg21.link/range.join.overview">[range.join.overview]</a> p2
</p>
<blockquote><p>
The name <tt>views::join</tt> denotes a range adaptor object (24.7.2 <a href="https://wg21.link/range.adaptor.object">[range.adaptor.object]</a>). Given 
a subexpression <tt>E</tt>, the expression <tt>views::join(E)</tt> is expression-equivalent to 
<tt>join_view<ins>&lt;views::all_t&lt;decltype((E))&gt;&gt;</ins>{E}</tt>.
</p>
</blockquote>
<p>
Or in code (<b>Option B</b>) add a deduction guide to 24.7.11.2 <a href="https://wg21.link/range.join.view">[range.join.view]</a>:
</p>
<blockquote><pre>
  template&lt;class R&gt;
    explicit join_view(R&amp;&amp;) -&gt; join_view&lt;views::all_t&lt;R&gt;&gt;;

  <ins>template&lt;class V&gt;
    explicit join_view(join_view&lt;V&gt;) -&gt; join_view&lt;join_view&lt;V&gt;&gt;;</ins>

</pre></blockquote>

<p><i>[2020-08-21; Issue processing telecon: Option A is Tentatively Ready]</i></p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
This wording is relative to <a href="https://wg21.link/n4861">N4861</a>.
</p>
<blockquote class="note">
<p>
[<i>Drafting Note:</i> Two mutually exclusive options are prepared, depicted below by <b>Option A</b> and 
<b>Option B</b>, respectively.] 
</p>
</blockquote>

<p>
<b>Option A:</b>
</p>
<ol>
<li><p>Modify 24.7.11.1 <a href="https://wg21.link/range.join.overview">[range.join.overview]</a> as indicated:</p>

<blockquote>
<p>
-2- <tt>The name views::join</tt> denotes a range adaptor object (24.7.2 <a href="https://wg21.link/range.adaptor.object">[range.adaptor.object]</a>). 
Given a subexpression <tt>E</tt>, the expression <tt>views::join(E)</tt> is expression-equivalent to 
<tt>join_view<ins>&lt;views::all_t&lt;decltype((E))&gt;&gt;</ins>{E}</tt>.
</p>
</blockquote>
</li>

</ol>

<p>
<b>Option B:</b>
</p>
<ol>
<li><p>Modify 24.7.11.2 <a href="https://wg21.link/range.join.view">[range.join.view]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]
  
  template&lt;class R&gt;
    explicit join_view(R&amp;&amp;) -&gt; join_view&lt;views::all_t&lt;R&gt;&gt;;
  
  <ins>template&lt;class V&gt;
    explicit join_view(join_view&lt;V&gt;) -&gt; join_view&lt;join_view&lt;V&gt;&gt;;</ins>
}
</pre>
</blockquote>
</li>

</ol>
</blockquote>


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

<ol>
<li><p>Modify 24.7.11.1 <a href="https://wg21.link/range.join.overview">[range.join.overview]</a> as indicated:</p>

<blockquote>
<p>
-2- <tt>The name views::join</tt> denotes a range adaptor object (24.7.2 <a href="https://wg21.link/range.adaptor.object">[range.adaptor.object]</a>). 
Given a subexpression <tt>E</tt>, the expression <tt>views::join(E)</tt> is expression-equivalent to 
<tt>join_view<ins>&lt;views::all_t&lt;decltype((E))&gt;&gt;</ins>{E}</tt>.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3476" href="https://cplusplus.github.io/LWG/lwg-active.html#3476">3476</a>. <tt>thread</tt> and <tt>jthread</tt> constructors require that the parameters be move-constructible 
but never move construct the parameters</h3>
<p><b>Section:</b> 32.4.3.3 <a href="https://wg21.link/thread.thread.constr">[thread.thread.constr]</a>, 32.4.4.2 <a href="https://wg21.link/thread.jthread.cons">[thread.jthread.cons]</a>, 32.9.9 <a href="https://wg21.link/futures.async">[futures.async]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2020-08-18 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
<p><b>Discussion:</b></p>
<p>
I think this was upgraded to <i>Mandates</i> because C++17 and earlier had "<tt>F</tt> and each <tt>T<sub><i>i</i></sub></tt> 
in <tt>Args</tt> shall satisfy the <i>Cpp17MoveConstructible</i> requirements." And for those, I think the requirement 
was attempting to make the subsequent <tt><i>decay-copy</i></tt> valid. However, the 'Mandating the standard library' 
papers added <tt>is_constructible</tt> requirements which already serve that purpose; <tt>std::(j)thread</tt> has no 
reason to move the elements after they have been <tt><i>decay-copy</i></tt>'d to transfer to the launched thread.
</p>

<p><i>[2020-08-26; Reflector discussion]</i></p>

<p>
Jonathan noticed that the wording for <tt>std::async</tt> is affected by exactly the same unnecessary move-constructible 
requirements. The proposed wording has been updated to cope for that as well.
</p>

<p><i>[2020-09-02; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after five votes in favour during reflector discussions.
</p>


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

<ol>
<li><p>Modify 32.4.3.3 <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>Constraints:</i> <tt>remove_cvref_t&lt;F&gt;</tt> is not the same type as <tt>thread</tt>.
<p/>
-4- <i>Mandates:</i> The following are all <tt>true</tt>:
</p>
<ol style="list-style-type: none">
<li><p>(4.1) &mdash; <tt>is_constructible_v&lt;decay_t&lt;F&gt;, F&gt;</tt>,</p></li>
<li><p>(4.2) &mdash; <tt>(is_constructible_v&lt;decay_t&lt;Args&gt;, Args&gt; &amp;&amp; ...)</tt>, <ins>and</ins></p></li>
<li><p><del>(4.3) &mdash; <tt>is_move_constructible_v&lt;decay_t&lt;F&gt;&gt;</tt>,</del></p></li>
<li><p><del>(4.4) &mdash; <tt>(is_move_constructible_v&lt;decay_t&lt;Args&gt;&gt; &amp;&amp; ...)</tt>, and</del></p></li>
<li><p>(4.5) &mdash; <tt>is_invocable_v&lt;decay_t&lt;F&gt;, decay_t&lt;Args&gt;...&gt;</tt>.</p></li>
</ol>
<p>
<del>-5- <i>Preconditions:</i> <tt>decay_t&lt;F&gt;</tt> and each type in <tt>decay_t&lt;Args&gt;</tt> meet the 
<i>Cpp17MoveConstructible</i> requirements.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 32.4.4.2 <a href="https://wg21.link/thread.jthread.cons">[thread.jthread.cons]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class F, class... Args&gt; explicit jthread(F&amp;&amp; f, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-3- <i>Constraints:</i> <tt>remove_cvref_t&lt;F&gt;</tt> is not the same type as <tt>jthread</tt>.
<p/>
-4- <i>Mandates:</i> The following are all <tt>true</tt>:
</p>
<ol style="list-style-type: none">
<li><p>(4.1) &mdash; <tt>is_constructible_v&lt;decay_t&lt;F&gt;, F&gt;</tt>,</p></li>
<li><p>(4.2) &mdash; <tt>(is_constructible_v&lt;decay_t&lt;Args&gt;, Args&gt; &amp;&amp; ...)</tt>, <ins>and</ins></p></li>
<li><p><del>(4.3) &mdash; <tt>is_move_constructible_v&lt;decay_t&lt;F&gt;&gt;</tt>,</del></p></li>
<li><p><del>(4.4) &mdash; <tt>(is_move_constructible_v&lt;decay_t&lt;Args&gt;&gt; &amp;&amp; ...)</tt>, and</del></p></li>
<li><p>(4.5) &mdash; <tt>is_invocable_v&lt;decay_t&lt;F&gt;, decay_t&lt;Args&gt;...&gt; ||
is_invocable_v&lt;decay_t&lt;F&gt;, stop_token, decay_t&lt;Args&gt;...&gt;</tt>.</p></li>
</ol>
<p>
<del>-5- <i>Preconditions:</i> <tt>decay_t&lt;F&gt;</tt> and each type in <tt>decay_t&lt;Args&gt;</tt> meet the 
<i>Cpp17MoveConstructible</i> requirements.</del>
</p>
</blockquote>
</blockquote>

</li>


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

<blockquote>
<pre>
template&lt;class F, class... Args&gt;
  [[nodiscard]] future&lt;invoke_result_t&lt;decay_t&lt;F&gt;, decay_t&lt;Args&gt;...&gt;&gt;
    async(F&amp;&amp; f, Args&amp;&amp;... args);
template&lt;class F, class... Args&gt;
  [[nodiscard]] future&lt;invoke_result_t&lt;decay_t&lt;F&gt;, decay_t&lt;Args&gt;...&gt;&gt;
    async(launch policy, F&amp;&amp; f, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-2- <i>Mandates:</i> The following are all <tt>true</tt>:
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; <tt>is_constructible_v&lt;decay_t&lt;F&gt;, F&gt;</tt>,</p></li>
<li><p>(2.2) &mdash; <tt>(is_constructible_v&lt;decay_t&lt;Args&gt;, Args&gt; &amp;&amp; ...)</tt>, <ins>and</ins></p></li>
<li><p><del>(2.3) &mdash; <tt>is_move_constructible_v&lt;decay_t&lt;F&gt;&gt;</tt>,</del></p></li>
<li><p><del>(2.4) &mdash; <tt>(is_move_constructible_v&lt;decay_t&lt;Args&gt;&gt; &amp;&amp; ...)</tt>, and</del></p></li>
<li><p>(2.5) &mdash; <tt>is_invocable_v&lt;decay_t&lt;F&gt;, decay_t&lt;Args&gt;...&gt;</tt>.</p></li>
</ol>
<p>
<del>-3- <i>Preconditions:</i> <tt>decay_t&lt;F&gt;</tt> and each type in <tt>decay_t&lt;Args&gt;</tt> meet the 
<i>Cpp17MoveConstructible</i> requirements.</del>
</p>
</blockquote>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="3477" href="https://cplusplus.github.io/LWG/lwg-active.html#3477">3477</a>. Simplify constraints for <tt><i>semiregular-box</i></tt></h3>
<p><b>Section:</b> 24.7.3 <a href="https://wg21.link/range.semi.wrap">[range.semi.wrap]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-08-19 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.semi.wrap">active issues</a> in [range.semi.wrap].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.semi.wrap">issues</a> in [range.semi.wrap].</p>
<p><b>Discussion:</b></p>
<p>
The exposition-only <tt><i>semiregular-box</i></tt> class template specified in 24.7.3 <a href="https://wg21.link/range.semi.wrap">[range.semi.wrap]</a> 
implements a default constructor, copy assignment operator, and move assignment operator atop the facilities 
provided by <tt>std::optional</tt> when the wrapped type is not default constructible, copy assignable, or 
move assignable (respectively). The constraints on the copy and move assignment operator implementations go 
out of their way to be unnecessarily minimal. The meaning of the constraint on the copy assignment operator 
&mdash; <tt>!assignable&lt;T, const T&amp;&gt;</tt> &mdash; has even changed since this wording was written 
as a result of LWG reformulating the implicit expression variations wording in 18.2 <a href="https://wg21.link/concepts.equality">[concepts.equality]</a>.
<p/>
It would be much simpler for implementors and users if we recall that minimality is not the primary goal of 
constraints and instead constrain these assignment operators more simply with 
<tt>!movable&lt;T&gt;</tt> and <tt>!copyable&lt;T&gt;</tt>.
</p>

<p><i>[2020-09-03; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after six votes in favour during reflector discussions.
</p>


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

<ol>
<li><p>Modify 24.7.3 <a href="https://wg21.link/range.semi.wrap">[range.semi.wrap]</a> as indicated:</p>

<blockquote>
<p>
-1- Many types in this subclause are specified in terms of an exposition-only class template 
<tt><i>semiregular-box</i></tt>. <tt><i>semiregular-box</i>&lt;T&gt;</tt> behaves exactly like 
<tt>optional&lt;T&gt;</tt> with the following differences:
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; [&hellip;]</p></li>
<li><p>(1.2) &mdash; [&hellip;]</p></li>
<li><p>(1.3) &mdash; If <tt><del>assignable_from&lt;T&amp;, const T&amp;&gt;</del><ins>copyable&lt;T&gt;</ins></tt> 
is not modeled, the copy assignment operator is equivalent to:</p>
<pre>
<i>semiregular-box</i>&amp; operator=(const <i>semiregular-box</i>&amp; that)
  noexcept(is_nothrow_copy_constructible_v&lt;T&gt;)
{
  if (that) emplace(*that);
  else reset();
  return *this;
}
</pre>
</li>
<li><p>(1.4) &mdash; If <tt><del>assignable_from&lt;T&amp;, T&gt;</del><ins>movable&lt;T&gt;</ins></tt> 
is not modeled, the move assignment operator is equivalent to:</p>
<pre>
<i>semiregular-box</i>&amp; operator=(<i>semiregular-box</i>&amp;&amp; that)
  noexcept(is_nothrow_move_constructible_v&lt;T&gt;)
{
  if (that) emplace(std::move(*that));
  else reset();
  return *this;
}
</pre>
</li>
</ol>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3482" href="https://cplusplus.github.io/LWG/lwg-active.html#3482">3482</a>. <tt>drop_view</tt>'s <tt>const begin</tt> should additionally require <tt>sized_range</tt></h3>
<p><b>Section:</b> 24.7.9.2 <a href="https://wg21.link/range.drop.view">[range.drop.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-08-31 <b>Last modified:</b> 2020-09-29</p>
<p><b>Priority: </b>0
</p>
<p><b>Discussion:</b></p>
<p>
When the underlying range models both <tt>random_access_range</tt> and <tt>sized_range</tt>, a 
<tt>drop_view</tt> can easily calculate its first iterator in <tt>&#x1d4aa;</tt>(1) as by the 
underlying range's first iterator  plus the minimum of the number of elements to drop and the 
size of the underlying range. In this case <tt>drop_view::begin</tt> need not "cache the result 
within the <tt>drop_view</tt> for use on subsequent calls" "in order to provide the amortized 
constant-time complexity required by the <tt>range</tt> concept" (24.7.9.2 <a href="https://wg21.link/range.drop.view">[range.drop.view]</a>/4). 
However, <tt>drop_view::begin() const</tt> does not require <tt>sized_range</tt>, it requires 
only <tt>random_access_range</tt>. There's no way to implementing what amounts to a requirement 
that calls to <tt>begin</tt> after the first must be <tt>&#x1d4aa;</tt>(1) without memoization.
<p/>
Performing memoization in a <tt>const</tt> member function in a manner consistent with 
16.4.6.10 <a href="https://wg21.link/res.on.data.races">[res.on.data.races]</a> is impossible without some kind of thread synchronization. It 
is not the intended design for anything in current Range library to require such implementation 
heroics, we typically fall back to mutable-only iteration to avoid thread synchronization concerns. 
(Note that both <tt>range-v3</tt> and <tt>cmcstl2</tt> handle <tt>drop_view::begin() const</tt> 
incorrectly by performing <tt>&#x1d4aa;</tt>(<tt><i>N</i></tt>) lookup of the first iterator on each call to 
<tt>begin</tt>, which is consistent with 16.4.6.10 <a href="https://wg21.link/res.on.data.races">[res.on.data.races]</a> but fails to meet the 
complexity requirements imposed by the <tt>range</tt> concept.) We should fall back to mutable-only 
iteration here as well when the underlying range is not a <tt>sized_range</tt>.
<p/>
For <tt>drop_view</tt>, changing the constraints on the <tt>const</tt> overload of <tt>begin</tt> 
also requires changing the constraints on the non-<tt>const</tt> overload. The non-<tt>const begin</tt> 
tries to constrain itself out of overload resolution when the <tt>const</tt> overload would be valid 
if the underlying range models the exposition-only <tt><i>simple-view</i></tt> concept. (Recall that 
<tt>T</tt> models simple-view iff <tt>T</tt> models <tt>view</tt>, <tt>const T</tt> models <tt>range</tt>, 
and <tt>T</tt> and <tt>const T</tt> have the same iterator and sentinel types.) Effectively this means 
the constraints on the non-<tt>const</tt> overload must require either that the underlying range fails 
to model <tt><i>simple-view</i></tt> or that the constraints on the <tt>const</tt> overload would not 
be satisfied. So when we add a new <tt>sized_range</tt> requirement to the <tt>const</tt> overload, 
we must also add its negation to the mutable overload. (The current form of the constraint on the 
mutable <tt>begin</tt> overload is <tt>!(<i>simple-view</i>&lt;V&gt; &amp;&amp; random_access_range&lt;V&gt;)</tt> 
instead of <tt>!(<i>simple-view</i>&lt;V&gt; &amp;&amp; random_access_range&lt;const V&gt;)</tt> because 
of an unstated premise that <tt>V</tt> and <tt>const V</tt> should both have the same category when 
both are ranges. Avoiding this unstated premise would make it easier for future readers to grasp what's 
happening here; we should formulate our new constraints in terms of <tt>const V</tt> instead of <tt>V</tt>.)
</p>

<p><i>[2020-09-29; Reflector discussions]</i></p>

<p>
Status to Tentatively Ready and priority to 0 after five positive votes on the reflector.
</p>



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

<ol>
<li><p>Modify 24.7.9.2 <a href="https://wg21.link/range.drop.view">[range.drop.view]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;view V&gt;
  class drop_view : public view_interface&lt;drop_view&lt;V&gt;&gt; {
  public:
    [&hellip;]
    constexpr auto begin()
      requires (!(<i>simple-view</i>&lt;V&gt; &amp;&amp; 
        random_access_range&lt;<ins>const</ins> V&gt; <ins>&amp;&amp; sized_range&lt;const V&gt;</ins>));
    constexpr auto begin() const
      requires random_access_range&lt;const V&gt; <ins>&amp;&amp; sized_range&lt;const V&gt;</ins>;    
    [&hellip;]
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
constexpr auto begin()
  requires (!(<i>simple-view</i>&lt;V&gt; &amp;&amp; 
    random_access_range&lt;<ins>const</ins> V&gt; <ins>&amp;&amp; sized_range&lt;const V&gt;</ins>));
constexpr auto begin() const
  requires random_access_range&lt;const V&gt; <ins>&amp;&amp; sized_range&lt;const V&gt;</ins>;
</pre>
<blockquote>
<p>
-3- <i>Returns:</i> <tt>ranges::next(ranges::begin(<i>base</i>_), <i>count</i>_, ranges::end(<i>base</i>_))</tt>.
<p/>
-4- <i>Remarks:</i> In order to provide the amortized constant-time complexity required by the 
<tt>range</tt> concept when <tt>drop_view</tt> models <tt>forward_range</tt>, the first overload 
caches the result within the <tt>drop_view</tt> for use on subsequent calls. [<i>Note:</i> Without 
this, applying a <tt>reverse_view</tt> over a <tt>drop_view</tt> would have quadratic iteration 
complexity. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3483" href="https://cplusplus.github.io/LWG/lwg-active.html#3483">3483</a>. <tt>transform_view::<i>iterator</i></tt>'s difference is overconstrained</h3>
<p><b>Section:</b> 24.7.6.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a>, 24.7.16.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-09-04 <b>Last modified:</b> 2020-09-13</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.transform.iterator">issues</a> in [range.transform.iterator].</p>
<p><b>Discussion:</b></p>
<p>
The difference operation for <tt>transform_view::<i>iterator</i></tt> is specified in 
24.7.6.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a> as:
</p>
<blockquote>
<pre>
friend constexpr difference_type operator-(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires random_access_range&lt;<i>Base</i>&gt;;
</pre>
<blockquote>
<p>
-22- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> - y.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
<p>
The member <tt><i>current_</i></tt> is an iterator of type <tt>iterator_t&lt;<i>Base</i>&gt;</tt>, where 
<tt><i>Base</i></tt> is <tt>V</tt> for <tt>transform_view&lt;V, F&gt;::<i>iterator</i>&lt;false&gt;</tt> 
and <tt>const V</tt> for <tt>transform_view&lt;V, F&gt;::<i>iterator</i>&lt;true&gt;</tt>. The difference 
of iterators that appears in the above <i>Effects:</i> element is notably well-defined if their type models 
<tt>sized_sentinel_for&lt;iterator_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</tt> which 
<tt>random_access_range&lt;<i>Base</i>&gt;</tt> refines. This overstrong requirement seems to be simply the 
result of an oversight; it has been present since <a href="https://wg21.link/p0789r0">P0789R0</a>, without 
&mdash; to my recollection &mdash; ever having been discussed. We should relax this requirement to provide 
difference capability for <tt>transform_view</tt>'s iterators whenever the underlying iterators do.
</p>

<p><i>[2020-09-08; Reflector discussion]</i></p>

<p>
During reflector discussions it was observed that <tt>elements_view::<i>iterator</i></tt> has the same issue
and the proposed wording has been extended to cover this template as well.
</p>

<p><i>[2020-09-13; Reflector prioritization]</i></p>

<p>
Set priority to 0 and status to Tentatively Ready after seven votes in favour during reflector discussions.
</p>


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

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

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, copy_constructible F&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;   
             regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt; &amp;&amp;
             <i>can-reference</i>&lt;invoke_result_t&lt;F&amp;, range_reference_t&lt;V&gt;&gt;&gt;
  template&lt;bool Const&gt;
  class transform_view&lt;V, F&gt;::<i>iterator</i> {
  public:
    [&hellip;]
    friend constexpr <i>iterator</i> operator-(<i>iterator</i> i, difference_type n)
      requires random_access_range&lt;<i>Base</i>&gt;;
    friend constexpr difference_type operator-(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires <del>random_access_range&lt;<i>Base</i>&gt;</del><ins>sized_sentinel_for&lt;iterator_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</ins>;
    [&hellip;]
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
friend constexpr difference_type operator-(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires <del>random_access_range&lt;<i>Base</i>&gt;</del><ins>sized_sentinel_for&lt;iterator_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</ins>;
</pre>
<blockquote>
<p>
-22- <i>Effects:</i> <tt>return x.<i>current_</i> - y.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 24.7.16.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, size_t N&gt;
    requires view&lt;V&gt; &amp;&amp; <i>has-tuple-element</i>&lt;range_value_t&lt;V&gt;, N&gt; &amp;&amp;
             <i>has-tuple-element</i>&lt;remove_reference_t&lt;range_reference_t&lt;V&gt;&gt;, N&gt;
  template&lt;bool Const&gt;
  class elements_view&lt;V, N&gt;::<i>iterator</i> {  <i>// exposition only</i>
    [&hellip;]
    friend constexpr <i>iterator</i> operator-(<i>iterator</i> x, difference_type y)
      requires random_access_range&lt;<i>Base</i>&gt;;
    friend constexpr difference_type operator-(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires <del>random_access_range&lt;<i>Base</i>&gt;</del><ins>sized_sentinel_for&lt;iterator_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</ins>;
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
constexpr difference_type operator-(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires <del>random_access_range&lt;<i>Base</i>&gt;</del><ins>sized_sentinel_for&lt;iterator_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;</ins>;
</pre>
<blockquote>
<p>
-21- <i>Effects:</i> <tt>return x.<i>current_</i> - y.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<h2 id="tentatively_nad">Tentatively NAD Issues</h2>
<p>
These issues were moved to <b>Tentatively NAD</b> since the Prague meeting,
either during LWG teleconferences or following reflector polls.
</p>
<hr>
<h3><a name="1396" href="https://cplusplus.github.io/LWG/lwg-active.html#1396">1396</a>. <tt>regex</tt> should support allocators</h3>
<p><b>Section:</b> 30.7 <a href="https://wg21.link/re.regex">[re.regex]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#re.regex">active issues</a> in [re.regex].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
<p><b>Duplicate of:</b> <a href="https://cplusplus.github.io/LWG/lwg-closed.html#1451">1451</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-104, US-141</b></p>
<p>
<tt>std::basic_regex</tt> should have an allocator for all the
reasons that a <tt>std::string</tt> does. For example, I can use
<tt>boost::interprocess</tt> to put a <tt>string</tt> or <tt>vector</tt>
in shared memory, but not a <tt>regex</tt>.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Add allocators to regexes
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote><p>
Accepting <a href="https://wg21.link/n3171.pdf">n3171</a> would solve this issue.
</p></blockquote>

<p><i>[2011-03-22 Madrid]</i></p>

<p>Close 1396 as NAD Future.</p>

<p><i>[LEWG Kona 2017]</i></p>

<p>Recommend Open: Covered in LEWG9, P0269, which is in wording review.</p>

<p><i>[2020-07-17; status changed to Tentatively NAD in issue processing telecon]</i></p>

<p>
P0269R0 has been superseded by P1294R0.
Requested LEWG to confirm which version they forwarded to LWG.
In any case, this is a feature request, not a defect, and will be dealt with as a proposal not an issue.
</p>


<p><b>Rationale:</b></p><p>No consensus for a change at this time</p>

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





<hr>
<h3><a name="2335" href="https://cplusplus.github.io/LWG/lwg-active.html#2335">2335</a>. <tt>array&lt;array&lt;int, 3&gt;, 4&gt;</tt> should be layout-compatible with <tt>int[4][3]</tt></h3>
<p><b>Section:</b> 22.3.7 <a href="https://wg21.link/array">[array]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2013-10-04 <b>Last modified:</b> 2020-02-16</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#array">issues</a> in [array].</p>
<p><b>Discussion:</b></p>
<p>
In order to replace some uses of C arrays with <tt>std::array</tt>, we need it
to be possible to cast from a <tt>std::array&lt;&gt;</tt> to an equivalent C array.
Core wording doesn't appear to be in quite the right state to allow
casting, but if we specify that appropriate types are
layout-compatible, we can at least write:
</p>
<blockquote><pre>
union {
  array&lt;array&lt;array&lt;int, 2&gt;, 3&gt;, 4&gt; arr;
  int carr[4][3][2];
};
</pre></blockquote>
<p>
to view memory as the other type: C++14 CD [class.mem]p18.
</p>
I believe it's sufficient to add "<tt>array&lt;T, N&gt;</tt> shall be
layout-compatible (6.8 <a href="https://wg21.link/basic.types">[basic.types]</a>) with <tt>T[N]</tt>." to 
22.3.7.1 <a href="https://wg21.link/array.overview">[array.overview]</a>, but we might also need some extension to 
11.4 <a href="https://wg21.link/class.mem">[class.mem]</a> to address the possibility of layout-compatibility 
between struct and array types.
<p>
I checked that libc++ on MacOS already implements this, although it
would be good for someone else to double-check; I haven't checked any
other standard libraries.
</p>

<p><i>[2020-02-14, Prague]</i></p>

<p>
LWG discussions and decision for NAD. 
</p>


<p><b>Rationale:</b></p>
The desire to use <tt>std::array</tt> like this seems like an "XY problem". The goal 
should be "replace C arrays" not "replace C arrays with <tt>std::array</tt>", because 
<tt>std::array</tt> is not suitable here. There are superior solutions being proposed, 
and will be available in a future version of C++ (e.g. using <tt>mdspan</tt> as a 
multi-dimensional view on an array).


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





<hr>
<h3><a name="3207" href="https://cplusplus.github.io/LWG/lwg-active.html#3207">3207</a>. <tt>N</tt> in <tt>ssize(const T (&amp;)[N])</tt> should be <tt>size_t</tt></h3>
<p><b>Section:</b> 23.7 <a href="https://wg21.link/iterator.range">[iterator.range]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2019-05-23 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#iterator.range">active issues</a> in [iterator.range].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#iterator.range">issues</a> in [iterator.range].</p>
<p><b>Discussion:</b></p>
<p>
The <tt>N</tt> in <tt>ssize(const T (&amp;)[N])</tt> is specified to be of type <tt>ptrdiff_t</tt>.  
It should be <tt>size_t</tt> to be consistent with the rest of the standard library, such as the
array overloads for all other range access functions, the <tt>swap</tt> overload for arrays, and
other function template overloads for arrays. (Note: the return type of this function should still 
be <tt>ptrdiff_t</tt>.)
</p>

<p><i>[2019-06-12 Tentatively NAD after reflector discussion]</i></p>



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

<ol>
<li><p>Modify 23.7 <a href="https://wg21.link/iterator.range">[iterator.range]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T, <del>ptrdiff</del><ins>size</ins>_t N&gt; constexpr ptrdiff_t ssize(const T (&amp;array)[N]) noexcept;
</pre>
<blockquote>
<p>
-19- <i>Returns:</i> <tt><ins>static_cast&lt;ptrdiff_t&gt;(</ins>N<ins>)</ins></tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3365" href="https://cplusplus.github.io/LWG/lwg-active.html#3365">3365</a>. Rename <i>ref-is-glvalue</i> to <i>deref-is-ref</i></h3>
<p><b>Section:</b> 24.7.11.3 <a href="https://wg21.link/range.join.iterator">[range.join.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Johel Ernesto Guerrero Pe&ntilde;a <b>Opened:</b> 2020-01-07 <b>Last modified:</b> 2020-01-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.join.iterator">issues</a> in [range.join.iterator].</p>
<p><b>Discussion:</b></p>
<p>The name of <i>join_view::iterator::ref-is-glvalue</i>, defined as 
<tt>is_reference_v&lt;range_reference_t&lt;Base&gt;&gt;</tt>, doesn't take into account 
the fact that it may also be true because <tt>range_reference_t&lt;Base&gt;</tt>
is an rvalue (e.g. for <tt>move_iterator&lt;int&gt;</tt>).</p>

<p>We suggest renaming it to <i>deref-is-ref</i>.</p>

<p><i>[2020-01-14 Status set to Tentatively NAD after five positive votes on the reflector. 
This issue was based on a misunderstanding by the submitter which had been cleared up in an 
<a href="https://github.com/cplusplus/draft/issues/3610">related editorial issue</a>.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>Rename all occurrences referring to the symbol 
<i>join_view::iterator::ref-is-glvalue</i> to <i>deref-is-ref</i>.</p>





<hr>
<h3><a name="3394" href="https://cplusplus.github.io/LWG/lwg-active.html#3394">3394</a>. <tt>ranges::basic_istream_view::<i>iterator</i></tt> has an empty <tt>iterator_traits</tt></h3>
<p><b>Section:</b> 24.6.5.3 <a href="https://wg21.link/range.istream.iterator">[range.istream.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Patrick Palka <b>Opened:</b> 2020-02-09 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.istream.iterator">active issues</a> in [range.istream.iterator].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.istream.iterator">issues</a> in [range.istream.iterator].</p>
<p><b>Discussion:</b></p>
<p>
Every instantiation of <tt>ranges::basic_istream_view::<i>iterator</i></tt> has an empty
<tt>iterator_traits</tt>, i.e. the type
</p>
<blockquote><pre>
iterator_traits&lt;ranges::basic_istream_view&lt;Val, CharT, Traits&gt;::iterator&gt;
</pre></blockquote>
<p>
has no members.
<p/>
This happens because <tt>basic_istream_view::<i>iterator</i></tt> neither models
<tt><i>cpp17-iterator</i></tt> (since this concept requires copyability, which this
iterator is by design not) nor does it define all four of the member
types <tt>difference_type</tt>, <tt>value_type</tt>, <tt>reference</tt>, and 
<tt>iterator_category</tt> (it is missing <tt>reference</tt>). Therefore by 
23.3.2.3 <a href="https://wg21.link/iterator.traits">[iterator.traits]</a> p3, this iterator's specialization of 
<tt>iterator_traits</tt> will be empty if generated from the 
<tt>iterator_traits</tt> primary template.
<p/>
Since <tt>basic_istream_view::iterator</tt> is indeed an iterator, its
<tt>iterator_traits</tt> should certainly not be empty. The simplest solution
here is to define the member type <tt>reference</tt> in the definition of
<tt>basic_istream_view::iterator</tt>, which will enable its <tt>iterator_traits</tt>
specialization to be appropriately populated from the primary template.
</p>

<p><i>[2020-02-10; Jonathan comments]</i></p>

<p>
Jonathan and Casey have concerns about the proposed resolution. Casey: The wording makes it look
as if this iterator is supposed to be an <tt><i>cpp17-input-iterator</i></tt>.
<p/>
See also LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3283">3283</a> and  <a href="https://cplusplus.github.io/LWG/lwg-active.html#3289">3289</a>.
</p>

<p><i>[2020-02 Prioritized as P2 Monday morning in Prague]</i></p>


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

<ol>
<li><p>Modify 24.6.5.3 <a href="https://wg21.link/range.istream.iterator">[range.istream.iterator]</a>, class template 
<tt>basic_istream_view::<i>iterator</i></tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;class Val, class CharT, class Traits&gt;
  class basic_istream_view&lt;Val, CharT, Traits&gt;::<i>iterator</i> { <i>// exposition only</i>
  public:
    using iterator_category = input_iterator_tag;
    using difference_type = ptrdiff_t;
    using value_type = Val;
    <ins>using reference = Val&amp;;</ins>

    <i>iterator</i>() = default;
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
LWG decided for NAD: The <tt>ranges::basic_istream_view::iterator</tt> is a move-only type 
and thus cannot meet the <i>Cpp17</i> requirements (even <tt>output_iterator_tag</tt>), as such it should not 
specialize <tt>iterator_traits</tt>, to avoid misleading results when it is passed to new algorithms.
<p/>
A related issue, LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3397">3397</a>, is supposed to take care for a problem with the definition of the
<tt>iterator_category</tt> member type of this template.
</p>


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





<hr>
<h3><a name="3399" href="https://cplusplus.github.io/LWG/lwg-active.html#3399">3399</a>. <tt>basic_syncbuf::emit()</tt> + Qt's <tt>#define emit</tt> = Big Bada-Boom</h3>
<p><b>Section:</b> 29.10.2.1 <a href="https://wg21.link/syncstream.syncbuf.overview">[syncstream.syncbuf.overview]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Marc Mutz <b>Opened:</b> 2019-02-14 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#syncstream.syncbuf.overview">issues</a> in [syncstream.syncbuf.overview].</p>
<p><b>Discussion:</b></p>
<p>
The current IS contains a function called <tt>emit()</tt> (in <tt>basic_syncbuf</tt>, added by <a href="https://wg21.link/p0053">P0053</a>).
<p/>
<tt>emit</tt> is a macro in pervasive use in every <a href="https://doc.qt.io/qt-5/signalsandslots.html#a-small-example">Qt program</a>. 
<tt>#include</tt>'ing <tt>&lt;osyncstream&gt;</tt> after any Qt header would break, because <tt>emit</tt> was <tt>#define</tt>'d 
to nothing by the Qt headers.
<p/>
It is understood that the committee cannot check every 3rd-party library out there that chooses (badly, as I’d readily concur) to 
<tt>#define</tt> a macro of all-lowercase letters, but the <tt>min</tt>/<tt>max</tt> issue in the Windows headers caused so much 
pain for our users, that we probably should avoid a breakage here, for the benefit of our users that have to work Qt.
<p/>
It also doesn’t seem like <tt>emit()</tt> is a particularly mandatory name for the syncbuf function. Since it returns <tt>bool</tt>, 
it could just as easily be called <tt>try_emit()</tt> and the issue would be solved.
<p/>
Suggested approach:
<p/>
In <tt>basic_syncbuf</tt>, rename <tt>bool emit()</tt> to <tt>bool try_emit()</tt>. In <tt>basic_osyncstream</tt>, where the function 
doesn't return <tt>bool</tt>, but sets the stream's <tt>failbit</tt>, rename <tt>void emit()</tt> to <tt>void emit_or_fail()</tt>.
</p>

<p><i>[2020-02-14, Prague]</i></p>

<p>
The issue was send to LEWG, who made the following poll:
</p>
<blockquote>
<p>
We're open to renaming <tt>osyncstream::emit()</tt> (and related).
</p>
<blockquote><pre>
SF F N A SA
1  1 5 8 20
</pre></blockquote>
</blockquote>


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

<ol>
<li><p>Modify 29.7.5.5 <a href="https://wg21.link/ostream.manip">[ostream.manip]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT, traits&gt;&amp; flush_emit(basic_ostream&lt;charT, traits&gt;&amp; os);
</pre>
<blockquote>
<p>
-12- <i>Effects:</i> Calls <tt>os.flush()</tt>. Then, if <tt>os.rdbuf()</tt> is a <tt>basic_syncbuf&lt;charT, traits, Allocator&gt;*</tt>,
called <tt>buf</tt> for the purpose of exposition, calls <tt>buf-&gt;<ins>try_</ins>emit()</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 29.10.2.1 <a href="https://wg21.link/syncstream.syncbuf.overview">[syncstream.syncbuf.overview]</a> as indicated:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 29.10.2.4 <a href="https://wg21.link/syncstream.syncbuf.members">[syncstream.syncbuf.members]</a>, member functions</i>
bool <ins>try_</ins>emit();
streambuf_type* get_wrapped() const noexcept;
[&hellip;]
</pre>
<blockquote>
<p>
-1- Class template <tt>basic_syncbuf</tt> stores character data written to it, known as the associated output, into
internal buffers allocated using the object's allocator. The associated output is transferred to the wrapped
stream buffer object <tt>*wrapped</tt> when <tt><ins>try_</ins>emit()</tt> is called or when the <tt>basic_syncbuf</tt> 
object is destroyed. Such transfers are atomic with respect to transfers by other <tt>basic_syncbuf</tt> objects 
with the same wrapped stream buffer object.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 29.10.2.2 <a href="https://wg21.link/syncstream.syncbuf.cons">[syncstream.syncbuf.cons]</a> as indicated:</p>

<blockquote>
<pre>
~basic_syncbuf();
</pre>
<blockquote>
<p>
-7- <i>Effects:</i> Calls <tt><ins>try_</ins>emit()</tt>.
<p/>
-8- <i>Throws:</i> Nothing. If an exception is thrown from <tt><ins>try_</ins>emit()</tt>, the destructor catches and ignores that
exception.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 29.10.2.3 <a href="https://wg21.link/syncstream.syncbuf.assign">[syncstream.syncbuf.assign]</a> as indicated:</p>

<blockquote>
<pre>
basic_syncbuf&amp; operator=(basic_syncbuf&amp;&amp; rhs) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Calls <tt><ins>try_</ins>emit()</tt> then move assigns from <tt>rhs</tt>. After the move assignment <tt>*this</tt> 
has the observable state it would have had if it had been move constructed from <tt>rhs</tt> (29.10.2.2 <a href="https://wg21.link/syncstream.syncbuf.cons">[syncstream.syncbuf.cons]</a>).
</p>
</blockquote>
</blockquote>
</li>

<li><p>Replace in 29.10.2.4 <a href="https://wg21.link/syncstream.syncbuf.members">[syncstream.syncbuf.members]</a> all occurrences of <tt>emit()</tt> by <tt>try_emit()</tt> (five occurrences)</p>
</li>

<li><p>Replace in 29.10.2.5 <a href="https://wg21.link/syncstream.syncbuf.virtuals">[syncstream.syncbuf.virtuals]</a> all occurrences of <tt>emit()</tt> by <tt>try_emit()</tt> (three occurrences)</p>
</li>

<li><p>Modify 29.10.3.1 <a href="https://wg21.link/syncstream.osyncstream.overview">[syncstream.osyncstream.overview]</a> as indicated:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 29.10.3.3 <a href="https://wg21.link/syncstream.osyncstream.members">[syncstream.osyncstream.members]</a>, member functions</i>
void emit<ins>_or_fail</ins>();
streambuf_type* get_wrapped() const noexcept;
[&hellip;]
</pre>
<blockquote>
</blockquote>
</blockquote>
</li>

<li><p>Replace in 29.10.3.2 <a href="https://wg21.link/syncstream.osyncstream.cons">[syncstream.osyncstream.cons]</a> all occurrences of <tt>emit()</tt> by <tt>emit_or_fail()</tt> (three occurrences)</p>
</li>

<li><p>Replace in  [syncstream.osyncstream.assign] all occurrences of <tt>emit()</tt> by <tt>emit_or_fail()</tt> (two occurrences)</p>
</li>

<li><p>Replace in 29.10.3.3 <a href="https://wg21.link/syncstream.osyncstream.members">[syncstream.osyncstream.members]</a> all occurrences of <tt>emit()</tt> by <tt>emit_or_fail()</tt> (six occurrences)</p>
</li>

</ol>




<hr>
<h3><a name="3440" href="https://cplusplus.github.io/LWG/lwg-active.html#3440">3440</a>. Aggregate-paren-init breaks direct-initializing a <tt>tuple</tt> or <tt>optional</tt> from <tt>{<i>aggregate-member-value</i>}</tt></h3>
<p><b>Section:</b> 20.5.3.1 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a>, 20.6.3.2 <a href="https://wg21.link/optional.ctor">[optional.ctor]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#NAD">Tentatively NAD</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2020-05-01 <b>Last modified:</b> 2020-06-27</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
<p><b>Discussion:</b></p>
<p>
For reference, see <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890">this gcc bug report</a>.
<p/>
Constructing a <tt>tuple</tt> or <tt>optional</tt> from an element value of an aggregate
is broken in C++20. <tt>tuple&lt;c&gt; t({val});</tt> and <tt>optional&lt;c&gt; t({val});</tt>
invoked a non-forwarding constructor before, but now the perfect-forwarding converting
constructors are a match, because the element is constructible from <tt>{val}</tt>. But
it's not convertible, so overload resolution chooses the explicit constructor, and the
initialization fails.
<p/>
Tim Song explains the overload resolution in <a href="https://lists.isocpp.org/lib/2020/05/16131.php">
this reflector discussion</a>.
<p/>
Now that we understand that C++17 called the non-forwarding conversion constructor,
and C++20 tries to use the forwarding conversion constructor, we have the solution.
SFINAE away the forwarding conversion constructor when it would convert an aggregate.
<p/>
This also means that <tt>tuple&lt;c&gt; t(0);</tt> won't work, which is unfortunate
because <tt>tuple&lt;c&gt;/optional&lt;c&gt;</tt> no longer mirrors what <tt>c</tt> can do.
That's okay; in this LWG issue, we first restore feature parity with C++17, and later,
as an extension, enable such initializations so that <tt>tuple</tt>/<tt>optional</tt>
mirrors what <tt>c</tt> can do in C++20.
<p/>
The proposed wording below has been implemented and tested.
</p>

<p><i>[2020-05-09; Reflector prioritization]</i></p>

<p>
Set priority to 2 after reflector discussions.
</p>

<p><i>[2020-06-11; LWG Telecon: Status changed: New &rarr; LEWG.]</i></p>

<p>
Ask LEWG if it's desirable to make <tt>({val})</tt> work again.
Tomasz would prefer it to be explicit e.g. via <tt>std::in_place</tt>.
</p>

<p><i>[2020-06-23; LEWG Telecon]</i></p>

<p>
POLL: Make <tt>({val})</tt> work again, at the risk of non-transparency of tuple constructors and further complicating 
the tuple and optional overload set.
</p>
<pre>
SF F N A SA
0  5 6 9 0
</pre>
<p>
No consensus for change. Close as Not a defect.
</p>


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

<ol>
<li><p>Modify 20.5.3.1 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class... UTypes&gt; constexpr explicit(<i>see below</i>) tuple(UTypes&amp;&amp;... u);
</pre>
<blockquote>
<p>
-11- <i>Constraints:</i> <tt>sizeof...(Types)</tt> equals <tt>sizeof...(UTypes)</tt> and
<tt>sizeof...(Types) &ge; 1</tt> and <tt>is_constructible_v&lt;T<sub><i>i</i></sub>, U<sub><i>i</i></sub>&gt;</tt>
is <tt>true</tt> for all <tt><i>i</i></tt> <ins>and <tt>conjunction_v&lt;is_aggregate&lt;remove_reference_t&lt;T<sub><i>i</i></sub>&gt;&gt;,
negation&lt;is_same&lt;remove_reference_t&lt;T<sub><i>i</i></sub>&gt;, remove_reference_t&lt;U<sub><i>i</i></sub>&gt;&gt;&gt;&gt;</tt> is
<tt>false</tt> for all <tt><i>i</i></tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 20.6.3.2 <a href="https://wg21.link/optional.ctor">[optional.ctor]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class U = T&gt; constexpr explicit(<i>see below</i>) optional(U&amp;&amp; v);
</pre>
<blockquote>
<p>
-22- <i>Constraints:</i> <tt>is_constructible_v&lt;T, U&gt;</tt> is <tt>true</tt>,
<tt>is_same_v&lt;remove_cvref_t&lt;U&gt;, in_place_t&gt;</tt> is <tt>false</tt>, <del>and</del>
<tt>is_same_v&lt;remove_cvref_t&lt;U&gt;, optional&gt;</tt> is <tt>false</tt><ins>, and
<tt>conjunction_v&lt;is_aggregate&lt;T&gt;, negation&lt;is_same&lt;T,
remove_reference_t&lt;U&gt;&gt;&gt;&gt;</tt> is <tt>false</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




</body>
</html>
