<!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, Jul. 2022</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, Jul. 2022</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P2618R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>2022-07-15</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>
</ul>
<h2 id="ready">Ready Issues</h2>
<p>
<p>The committee is requested to approve the proposed resolutions for the
issues in this document.

<p>
These issues are in <b>Ready</b> status, meaning the LWG has reached consensus
that the issue is a defect in the Standard, the <b>Proposed Resolution</b> is
correct, and the issue is ready to forward to the full committee for approval.
</p>

</p>
<hr>
<h3><a name="3564" href="https://cplusplus.github.io/LWG/lwg-active.html#3564">3564</a>. <tt>transform_view::<i>iterator</i>&lt;true&gt;::value_type</tt> and <tt>iterator_category</tt> should 
use <tt>const F&amp;</tt></h3>
<p><b>Section:</b> 26.7.7.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</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> 2021-06-06 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>2
</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>
Iterators obtained from a <tt>const transform_view</tt> invoke the
transformation function as <tt>const</tt>, but the <tt>value_type</tt> and
<tt>iterator_category</tt> determination uses plain <tt>F&amp;</tt>, i.e., non-<tt>const</tt>.
</p>

<p><i>[2021-06-14; Reflector poll]</i></p>

<p>
Set priority to 2 after reflector poll, send to SG9 for design clarification.
Should <code>r</code> and <code>as_const(r)</code> guarantee same elements?
</p>

<p><i>[2022-07-08; Reflector poll]</i></p>

<p>
SG9 has decided to proceed with this PR in its 2021-09-13 telecon and
not block the issue for a paper on the more general const/non-const
problem.
</p>
<p>
Set status to Tentatively Ready after five votes in favour during reflector poll.
</p>

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 26.7.7.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> {
  private:
    [&hellip;]
  public:
    using iterator_concept = <i>see below</i>;
    using iterator_category = <i>see below</i>; <i>// not always present</i>
    using value_type =
      remove_cvref_t&lt;invoke_result_t&lt;<ins><i>maybe-const</i>&lt;Const,</ins> F<ins>&gt;</ins>&amp;, 
      range_reference_t&lt;<i>Base</i>&gt;&gt;&gt;;
    using difference_type = range_difference_t&lt;<i>Base</i>&gt;;  
    [&hellip;]
  };
}
</pre>
</blockquote>
<p>
-1- [&hellip;]
<p/>
-2- The member <i>typedef-name</i> <tt>iterator_category</tt> is defined if and only if <tt><i>Base</i></tt> 
models <tt>forward_range</tt>. In that case, <tt>iterator::iterator_category</tt> is defined as follows: Let 
<tt>C</tt> denote the type <tt>iterator_traits&lt;iterator_t&lt;<i>Base</i>&gt;&gt;::iterator_category</tt>.
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; If <tt>is_lvalue_reference_v&lt;invoke_result_t&lt;<ins><i>maybe-const</i>&lt;Const,</ins> 
F<ins>&gt;</ins>&amp;, range_reference_t&lt;<i>Base</i>&gt;&gt;&gt;</tt> 
is <tt>true</tt>, then</p>
<ol style="list-style-type: none">
<li><p>(2.1.1) &mdash; [&hellip;]</p></li>
<li><p>(2.1.2) &mdash; [&hellip;]</p></li>
</ol>
</li>
<li><p>(2.2) &mdash; Otherwise, <tt>iterator_category</tt> denotes <tt>input_iterator_tag</tt>.</p></li>
</ol>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3617" href="https://cplusplus.github.io/LWG/lwg-active.html#3617">3617</a>. <tt>function</tt>/<tt>packaged_task</tt> deduction guides and deducing <tt>this</tt></h3>
<p><b>Section:</b> 22.10.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a>, 33.10.10.2 <a href="https://wg21.link/futures.task.members">[futures.task.members]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2021-10-09 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#func.wrap.func.con">active issues</a> in [func.wrap.func.con].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>Discussion:</b></p>
<p>
With the adoption of deducing <tt>this</tt> (<a href="https://wg21.link/p0847">P0847</a>), we can now create 
types whose call operator is an explicit object member function, which means that <tt>decltype(&amp;F::operator())</tt> 
could have pointer-to-function type rather than pointer-to-member-function type. This means that the deduction 
guides for <tt>std::function</tt> (22.10.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a>) and <tt>std::packaged_task</tt> 
(33.10.10.2 <a href="https://wg21.link/futures.task.members">[futures.task.members]</a>) will simply fail:
</p>
<blockquote><pre>
struct F {
  int operator()(this const F&amp;) { return 42; }
};

std::function g = F{}; // error: decltype(&amp;F::operator()) is not of the form R(G::*)(A...) <i>cv</i> &amp;<sub>opt</sub> noexcept<sub>opt</sub>
</pre></blockquote>
<p>
We should update the deduction guides to keep them in line with the core language.
</p>

<p><i>[2021-10-14; Reflector poll]</i></p>

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

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

<ol>
<li><p>Modify 22.10.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class F&gt; function(F) -&gt; function&lt;<i>see below</i>&gt;;
</pre>
<blockquote>
<p>
-16- <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 <ins>either</ins> of the form <tt>R(G::*)(A...) <i>cv</i> 
&amp;<sub>opt</sub> noexcept<sub>opt</sub></tt> <ins>or of the form <tt>R(*)(G <i>cv</i> &amp;<sub>opt</sub>, A...) 
noexcept<sub>opt</sub></tt></ins> for a <del>class</del> type <tt>G</tt>.
<p/>
-17- <i>Remarks:</i> The deduced type is <tt>function&lt;R(A...)&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 33.10.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) -&gt; packaged_task&lt;<i>see below</i>&gt;;
</pre>
<blockquote>
<p>
-7- <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 <ins>either</ins> of the form <tt>R(G::*)(A...) <i>cv</i> 
&amp;<sub>opt</sub> noexcept<sub>opt</sub></tt> <ins>or of the form <tt>R(*)(G <i>cv</i> &amp;<sub>opt</sub>, A...) 
  noexcept<sub>opt</sub></tt></ins> for a <del>class</del> type <tt>G</tt>.
<p/>
-8- <i>Remarks:</i> The deduced type is <tt>packaged_task&lt;R(A...)&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2021-10-17; Improved wording based on Tim Song's suggestion]</i></p>


<p><i>[2022-07-01; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 22.10.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class F&gt; function(F) -&gt; function&lt;<i>see below</i>&gt;;
</pre>
<blockquote>
<p>
-16- <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 <ins>either</ins> of the form <tt>R(G::*)(A...) <i>cv</i> 
&amp;<sub>opt</sub> noexcept<sub>opt</sub></tt> <ins>or of the form <tt>R(*)(G, A...) noexcept<sub>opt</sub></tt></ins> 
for a <del>class</del> type <tt>G</tt>.
<p/>
-17- <i>Remarks:</i> The deduced type is <tt>function&lt;R(A...)&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 33.10.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) -&gt; packaged_task&lt;<i>see below</i>&gt;;
</pre>
<blockquote>
<p>
-7- <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 <ins>either</ins> of the form <tt>R(G::*)(A...) <i>cv</i> 
&amp;<sub>opt</sub> noexcept<sub>opt</sub></tt> <ins>or of the form <tt>R(*)(G, A...) noexcept<sub>opt</sub></tt></ins> 
for a <del>class</del> type <tt>G</tt>.
<p/>
-8- <i>Remarks:</i> The deduced type is <tt>packaged_task&lt;R(A...)&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3656" href="https://cplusplus.github.io/LWG/lwg-active.html#3656">3656</a>. Inconsistent bit operations returning a count</h3>
<p><b>Section:</b> 22.15.5 <a href="https://wg21.link/bit.pow.two">[bit.pow.two]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2021-12-30 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
Among the bit operations returning a count, <tt>bit_width()</tt> is the only one not returning an <tt>int</tt>.
<p/>
This has the following consequences:
</p>
<blockquote><pre>
std::uint64_t b64 = 1;
b64 = std::rotr(b64, 1);
int count1 = std::popcount(b64);     // OK
int count2 = std::countl_zero(b64);  // OK
int count3 = std::bit_width(b64);    // OOPS
</pre></blockquote>
<p>
The last line may result in a warning such as:
</p>
<blockquote><p>
Warning: conversion from <tt>long long unsigned</tt> to <tt>int</tt> may change value
</p></blockquote>
<p>
You have to use a <tt>static_cast</tt> to avoid the warning.
<p/>
Note that <a href="https://wg21.link/P0553R4">P0553R4</a> explicitly states the following design considerations,
which I would also assume to apply to the later added functions from <a href="https://wg21.link/P0556R3">P0556R3</a>:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
The counting operations return "<tt>int</tt>" quantities, consistent with the rule "use an <tt>int</tt> unless you 
need something else". This choice does not reflect, in the type, the fact that counts are always non-negative. 
</p>
</blockquote>

<p><i>[2022-01-30; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll.
Eight votes for P0, but request LEWG confirmation before setting it to
Tentatively Ready.
</p>

<p><i>[2022-02-22 LEWG telecon; Status changed: LEWG &rarr; Open]</i></p>

<p>
No objection to unanimous consent to send the proposed resolution for LWG3656 to LWG for C++23.
The changes in P1956 changed the functions to be more counting than mathematical.
</p>


<p><i>[2022-07-08; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<pre>
[&hellip;]
template&lt;class T&gt;
  constexpr <del>T</del><ins>int</ins> bit_width(T x) noexcept;
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 22.15.5 <a href="https://wg21.link/bit.pow.two">[bit.pow.two]</a>, as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt;
  constexpr <del>T</del><ins>int</ins> bit_width(T x) noexcept;
</pre>
<blockquote>
<p>
-11- <i>Constraints:</i> <tt>T</tt> is an unsigned integer type (6.8.2 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a>).
<p/>
-12- <i>Returns:</i> If <tt>x == 0</tt>, <tt>0</tt>; otherwise one plus the base-2 logarithm of <tt>x</tt>, 
with any fractional part discarded.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3659" href="https://cplusplus.github.io/LWG/lwg-active.html#3659">3659</a>. Consider <tt>ATOMIC_FLAG_INIT</tt> undeprecation</h3>
<p><b>Section:</b> D.26.5 <a href="https://wg21.link/depr.atomics.flag">[depr.atomics.flag]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Aaron Ballman <b>Opened:</b> 2022-01-18 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P0883R2">P0883R2</a> deprecated <tt>ATOMTIC_VAR_INIT</tt> and
<tt>ATOMIC_FLAG_INIT</tt> largely based on rationale from WG14. However, WG14
only deprecated <tt>ATOMIC_VAR_INIT</tt> because we were told by implementers
that <tt>ATOMIC_FLAG_INIT</tt> is still necessary for some platforms (platforms
for which "clear" is actually not all zero bits, which I guess exist).
<p/>
I'd like to explore whether WG21 should undeprecate <tt>ATOMIC_FLAG_INIT</tt>
as there was no motivation that I could find in the paper on the topic
or in the discussion at 
<a href="https://wiki.edg.com/bin/view/Wg21jacksonville2018/P0883R0">P0883R0 [Jacksonville 2018]</a>.
<p/>
One possible approach would be to undeprecate it from <tt>&lt;stdatomic.h&gt;</tt> only (C++ 
can still use the constructors from <tt>&lt;atomic&gt;</tt> and shared code can use the macros 
from <tt>&lt;stdatomic.h&gt;</tt>).
</p>

<p><i>[2022-01-30; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll. Send to SG1.
</p>

<p><i>[2022-07-06; SG1 confirm the direction, Jonathan adds wording]</i></p>

<p>
"In response to LWG 3659, add ATOMIC_FLAG_INIT to &lt;stdatomic.h&gt; as undeprecated."
</p>
<table>
<tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr>
<tr><td>3</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
</table>
<p>
"In response to LWG 3659, undeprecate ATOMIC_FLAG_INIT in &lt;atomic&gt;."
</p>
<table>
<tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr>
<tr><td>2</td><td>3</td><td>1</td><td>0</td><td>0</td></tr>
</table>


<p><i>[2022-07-11; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<pre>
void atomic_flag_notify_all(volatile atomic_flag*) noexcept;
void atomic_flag_notify_all(atomic_flag*) noexcept;
<ins>#define ATOMIC_FLAG_INIT <i>see below</i></ins>

// [atomics.fences], fences
extern "C" void atomic_thread_fence(memory_order) noexcept;
extern "C" void atomic_signal_fence(memory_order) noexcept;
</pre>
</blockquote>
</li>

<li>
<p>
Move the content of D.26.5 <a href="https://wg21.link/depr.atomics.flag">[depr.atomics.flag]</a> from Annex D to
the end of 33.5.10 <a href="https://wg21.link/atomics.flag">[atomics.flag]</a>.
</p>
<blockquote>
<pre>
#define ATOMIC_FLAG_INIT <i>see below</i>
</pre>
<blockquote>
<p>
<i>Remarks:</i> The macro <code>ATOMIC_FLAG_INIT</code> is defined in
such a way that it can be used to initialize an object of type
<code>atomic_flag</code> to the clear state. The macro can be used in the form:
</p>
<pre>
  atomic_flag guard = ATOMIC_FLAG_INIT;
</pre>
<p>
It is unspecified whether the macro can be used in other initialization
contexts.
For a complete static-duration object, that initialization shall be static.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Modify 33.5.12 <a href="https://wg21.link/stdatomic.h.syn">[stdatomic.h.syn]</a> C compatibility, as indicated:
</p>

<blockquote>
<pre>
using std::atomic_flag_clear;            <i>// see below</i>
using std::atomic_flag_clear_explicit;   <i>// see below</i>
<ins>#define ATOMIC_FLAG_INIT <i>see below</i></ins>

using std::atomic_thread_fence;          <i>// see below</i>
using std::atomic_signal_fence;          <i>// see below</i>
</pre>
</blockquote>
</li>

<li>
<p>
Modify D.26.1 <a href="https://wg21.link/depr.atomics.general">[depr.atomics.general]</a> in Annex D as indicated:
</p>

<blockquote>
<pre>
#define ATOMIC_VAR_INIT(value) <i>see below</i>

<del>#define ATOMIC_FLAG_INIT <i>see below</i></del>
}
</pre>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="3670" href="https://cplusplus.github.io/LWG/lwg-active.html#3670">3670</a>. <i>Cpp17InputIterator</i>s don't have integer-class difference types</h3>
<p><b>Section:</b> 26.6.4.3 <a href="https://wg21.link/range.iota.iterator">[range.iota.iterator]</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> 2022-02-04 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.iota.iterator">issues</a> in [range.iota.iterator].</p>
<p><b>Discussion:</b></p>
<p>
26.6.4.3 <a href="https://wg21.link/range.iota.iterator">[range.iota.iterator]</a> defines 
</p>
<blockquote><pre>
using iterator_category = input_iterator_tag; <i>// present only if W models incrementable</i>
</pre></blockquote>
<p>
but when <tt>difference_type</tt> is an integer-class type the iterator does not meet the 
<i>Cpp17InputIterator</i> requirements.
</p>

<p><i>[2022-02-07; Daniel comments]</i></p>

<p>
As requested by LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3376">3376</a> and wording implemented by <a href="https://wg21.link/P2393R1">P2393R1</a>,
integer-class types are no longer required to have class type.
</p>

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

<ol>
<li><p>Modify 26.6.4.3 <a href="https://wg21.link/range.iota.iterator">[range.iota.iterator]</a>, class <tt>iota_view::<i>iterator</i></tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;weakly_incrementable W, semiregular Bound&gt;
    requires <i>weakly-equality-comparable-with</i>&lt;W, Bound&gt; &amp;&amp; copyable&lt;W&gt;
  struct iota_view&lt;W, Bound&gt;::<i>iterator</i> {
    [&hellip;]
    using iterator_category = input_iterator_tag; <i>// present only if W models incrementable <ins>and</ins></i> 
                                                  <i><ins>// IOTA-DIFF-T(W) is not a class type</ins></i>
    using value_type = W;
    using difference_type = <i>IOTA-DIFF-T</i>(W);
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2022-02-07; Casey Carter provides improved wording]</i></p>


<p><i>[2022-03-04; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 26.6.4.3 <a href="https://wg21.link/range.iota.iterator">[range.iota.iterator]</a>, class <tt>iota_view::<i>iterator</i></tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;weakly_incrementable W, semiregular Bound&gt;
    requires <i>weakly-equality-comparable-with</i>&lt;W, Bound&gt; &amp;&amp; copyable&lt;W&gt;
  struct iota_view&lt;W, Bound&gt;::<i>iterator</i> {
    [&hellip;]
    using iterator_category = input_iterator_tag; <i>// present only if W models incrementable <ins>and</ins></i> 
                                                  <i><ins>// IOTA-DIFF-T(W) is an integral type</ins></i>
    using value_type = W;
    using difference_type = <i>IOTA-DIFF-T</i>(W);
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3671" href="https://cplusplus.github.io/LWG/lwg-active.html#3671">3671</a>. <tt>atomic_fetch_xor</tt> missing from <tt>stdatomic.h</tt></h3>
<p><b>Section:</b> 33.5.12 <a href="https://wg21.link/stdatomic.h.syn">[stdatomic.h.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2022-02-09 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://web.archive.org/web/20181230041359/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf#page=208">C17 subclause 7.17.7.5</a> provides <tt>atomic_fetch_xor</tt> and <tt>atomic_fetch_xor_explicit</tt>.
<tt>stdatomic.h</tt> in the working draft (<a href="https://wg21.link/N4901">N4901</a>) does not.
</p>

<p><i>[2022-02-09; Jonathan comments and provides wording]</i></p>

<p>
C++20 33.5.2 <a href="https://wg21.link/atomics.syn">[atomics.syn]</a> has both of them, too, so it should definitely be in the common subset.
</p>

<p><i>[2022-03-04; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote class="note">
<p>
[<i>Drafting Note:</i> The editor is kindly requested to reorder these "<tt>atomic_fetch_<i>KEY</i></tt>" 
declarations to match the other synopses in Clause 33.5 <a href="https://wg21.link/atomics">[atomics]</a>: <tt>add</tt>, <tt>sub</tt>, 
<tt>and</tt>, <tt>or</tt>, <tt>xor</tt>.] 
</p>
</blockquote>

<blockquote>
<pre>
[&hellip;]
using std::atomic_fetch_or;                    <i>// see below</i>
using std::atomic_fetch_or_explicit;           <i>// see below</i>
<ins>using std::atomic_fetch_xor;                   <i>// see below</i>
using std::atomic_fetch_xor_explicit;          <i>// see below</i></ins>
using std::atomic_fetch_and;                   <i>// see below</i>
using std::atomic_fetch_and_explicit;          <i>// see below</i>
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3672" href="https://cplusplus.github.io/LWG/lwg-active.html#3672">3672</a>. <tt>common_iterator::operator-&gt;()</tt> should return by value</h3>
<p><b>Section:</b> 25.5.4.4 <a href="https://wg21.link/common.iter.access">[common.iter.access]</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> 2022-02-12 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#common.iter.access">issues</a> in [common.iter.access].</p>
<p><b>Discussion:</b></p>
<p>
25.5.4.4 <a href="https://wg21.link/common.iter.access">[common.iter.access]</a> p5 (5.1) says that <tt>common_iterator&lt;T*, S&gt;::operator-&gt;()</tt> 
returns <tt>std::get&lt;T*&gt;(v_)</tt> which has type <tt>T* const&amp;</tt>. That means that 
<tt>iterator_traits::pointer</tt> is <tt>T* const&amp;</tt> as well (this was recently clarified by LWG 
<a href="https://cplusplus.github.io/LWG/lwg-defects.html#3660">3660</a>). We have an actual pointer here, why are we returning it by reference?
<p/>
For the three bullet points in 25.5.4.4 <a href="https://wg21.link/common.iter.access">[common.iter.access]</a> p5, the second and third return by value 
anyway, so <tt>decltype(auto)</tt> is equivalent to <tt>auto</tt>. For the first bullet, it would make a lot 
more sense for raw pointers to be returned by value. That leaves the case where the iterator has an 
<tt>operator-&gt;()</tt> member, which could potentially benefit from returning by reference. But it must 
return something that is iterator-like or pointer-like, which we usually just pass by value. Casey suggested 
we should just change <tt>common_iterator&lt;I, S&gt;::operator-&gt;()</tt> to return by value in all cases.
<p/>
Libstdc++ has always returned by value, as an unintended consequence of using a union instead of 
<tt>std::variant&lt;I, S&gt;</tt>, so that it doesn't use <tt>std::get&lt;I&gt;</tt> to return the member.
</p>

<p><i>[2022-03-04; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 25.5.4.1 <a href="https://wg21.link/common.iterator">[common.iterator]</a>, class template <tt>common_iterator</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
constexpr decltype(auto) operator*();
constexpr decltype(auto) operator*() const
  requires <i>dereferenceable</i>&lt;const I&gt;;
constexpr <del>decltype(</del>auto<del>)</del> operator-&gt;() const
  requires <i>see below</i>;
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 25.5.4.4 <a href="https://wg21.link/common.iter.access">[common.iter.access]</a> as indicated:</p>

<blockquote>
<pre>
constexpr <del>decltype(</del>auto<del>)</del> operator-&gt;() const
  requires <i>see below</i>;
</pre>
<blockquote>
<p>
-3- The expression in the <i>requires-clause</i> is equivalent to: [&hellip;]
<p/>
-4- <i>Preconditions:</i> <tt>holds_alternative&lt;I&gt;(v_)</tt> is <tt>true</tt>.
<p/>
-5- <i>Effects:</i>
</p>
<ol style="list-style-type:none">
<li><p>(5.1) &mdash; If <tt>I</tt> is a pointer type or if the expression <tt>get&lt;I&gt;(v_).operator-&gt;()</tt> 
is well-formed, equivalent to: <tt>return get&lt;I&gt;(v_);</tt></p></li>
<li><p>(5.2) &mdash; Otherwise, if <tt>iter_reference_t&lt;I&gt;</tt> is a reference type, equivalent to:</p>
<blockquote><pre>
auto&amp;&amp; tmp = *get&lt;I&gt;  (v_);
return addressof(tmp);
</pre></blockquote>
</li>
<li><p>(5.3) &mdash; Otherwise, equivalent to: <tt>return <i>proxy</i>(*get&lt;I&gt;(v_));</tt> where <tt><i>proxy</i></tt> 
is the exposition-only class:</p>
<blockquote><pre>
class <i>proxy</i> {
  iter_value_t&lt;I&gt; keep_;
  constexpr <i>proxy</i>(iter_reference_t&lt;I&gt;&amp;&amp; x)
    : keep_(std::move(x)) {}
public:
  constexpr const iter_value_t&lt;I&gt;* operator-&gt;() const noexcept {
    return addressof(keep_);
  }
};
</pre></blockquote>
</li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3683" href="https://cplusplus.github.io/LWG/lwg-active.html#3683">3683</a>. <tt>operator==</tt> for <tt>polymorphic_allocator</tt> cannot deduce template argument in common cases</h3>
<p><b>Section:</b> 20.4.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">Ready</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2022-03-18 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</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>
In <tt>&lt;memory_resource&gt;</tt>, the equality comparison operator for <tt>pmr::polymorphic_allocator</tt> 
is declared in namespace scope as:
</p>
<blockquote><pre>
template&lt;class T1, class T2&gt;
  bool operator==(const polymorphic_allocator&lt;T1&gt;&amp; a,
                  const polymorphic_allocator&lt;T2&gt;&amp; b) noexcept;
</pre></blockquote>
<p>
Since <tt>polymorphic_allocator</tt> is implicitly convertible from <tt>memory_resource*</tt>, 
one would naively expect &mdash; and the author of <tt>polymorphic_allocator</tt> intended 
&mdash; the following code to work:
</p>
<blockquote><pre>
std::pmr::unsynchronized_pool_resource pool_rsrc;
std::pmr::vector&lt;int&gt; vec(&amp;pool_rsrc); // Converts to std::pmr::polymorphic_allocator&lt;int&gt;
[&hellip;]
assert(vec.get_allocator() == &amp;pool_rsrc);  // (1) Compare polymorphic_allocator to memory_resource*
</pre></blockquote>
<p>
Unfortunately, the line labeled (1) is ill-formed because the type <tt>T2</tt> in <tt>operator==</tt> cannot be deduced.
<p/>
Possible resolution 1 (PR1) is to supply a second <tt>operator==</tt>, overloaded for comparison to 
<tt>memory_resource*</tt>:
</p>
<blockquote><pre>
template&lt;class T1, class T2&gt;
  bool operator==(const polymorphic_allocator&lt;T1&gt;&amp; a,
                  const polymorphic_allocator&lt;T2&gt;&amp; b) noexcept;
<ins>template&lt;class T&gt;
  bool operator==(const polymorphic_allocator&lt;T&gt;&amp; a,
                  memory_resource* b) noexcept;</ins>
</pre></blockquote>
<p>
The rules for implicitly defined spaceship and comparison operators obviates defining <tt>operator!=</tt> 
or <tt>operator==(b, a)</tt>. This PR would allow <tt>polymorphic_allocator</tt> to be compared for equality 
with <tt>memory_resource*</tt>, but not with any other type that is convertible to <tt>polymorphic_allocator</tt>.
<p/>
Possible resolution 2 (PR2) is to replace <tt>operator==</tt> with a homogeneous version where type deduction 
occurs only for one template parameter:
</p>
<blockquote><pre>
<del>template&lt;class T1, class T2&gt;
  bool operator==(const polymorphic_allocator&lt;T1&gt;&amp; a,
                  const polymorphic_allocator&lt;T2&gt;&amp; b) noexcept;</del>
<ins>template&lt;class T&gt;
  bool operator==(const polymorphic_allocator&lt;T&gt;&amp; a,
                  const type_identity_t&lt;polymorphic_allocator&lt;T&gt;&gt;&amp; b) noexcept;</ins>
</pre></blockquote>
<p>
This version will work with any type that is convertible to <tt>polymorphic_allocator</tt>.
<p/>
Possible resolution 3 (PR3), the proposed resolution, below, is to add a homogeneous equality operator 
as a "hidden friend", such that it is found by ADL only if one argument is a <tt>polymorphic_allocator</tt> 
and the other argument is convertible to <tt>polymorphic_allocator</tt>. As with PR2, this PR will work 
with any type that is convertible to <tt>polymorphic_allocator</tt>.
</p>

<blockquote class="note">
<p>
Note to reader: Proof of concept for the three possible resolutions can be seen at 
<a href="https://godbolt.org/z/1oqG66qqe">this godbolt link</a>. Uncomment one of PR1, PR2, 
or PR3 macros to see the effects of each PR.
</p>
</blockquote>

<p><i>[2022-05-17; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 20.4.3 <a href="https://wg21.link/mem.poly.allocator.class">[mem.poly.allocator.class]</a>, class template <tt>polymorphic_allocator</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::pmr {
  template&lt;class Tp = byte&gt; class polymorphic_allocator {
    memory_resource* memory_rsrc; <i>// exposition only</i>

  public:
    using value_type = Tp;

    [&hellip;]
    memory_resource* resource() const;
    
    <ins><i>// friends</i>
    friend bool operator==(const polymorphic_allocator&amp; a,
                           const polymorphic_allocator&amp; b) noexcept {
      return *a.resource() == *b.resource();
    }</ins>
  };
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3687" href="https://cplusplus.github.io/LWG/lwg-active.html#3687">3687</a>. <tt>expected&lt;<i>cv</i> void, E&gt;</tt> move constructor should move</h3>
<p><b>Section:</b> 22.8.7.4 <a href="https://wg21.link/expected.void.assign">[expected.void.assign]</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> 2022-03-23 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
For <tt>expected&lt;<i>cv</i> void&gt;::operator=(expected&amp;&amp;)</tt> we have this 
in the last bullet of the <i>Effects</i> element:
</p>
<blockquote><p>
Otherwise, equivalent to <tt><i>unex</i> = rhs.error()</tt>.
</p></blockquote>
<p>
That should be a move assignment, not a copy assignment.
</p>

<p><i>[2022-05-17; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 22.8.7.4 <a href="https://wg21.link/expected.void.assign">[expected.void.assign]</a> as indicated:</p>

<blockquote>
<pre>
constexpr expected&amp; operator=(expected&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
-4- <i>Effects:</i>
</p>
<ol style="list-style-type:none">
<li><p>(4.1) &mdash; If <tt>this-&gt;has_value() &amp;&amp; rhs.has_value()</tt> is <tt>true</tt>, no effects.</p></li>
<li><p>(4.2) &mdash; Otherwise, if <tt>this-&gt;has_value()</tt> is <tt>true</tt>, equivalent to:</p>
<blockquote><pre>
construct_at(addressof(<i>unex</i>), std::move(rhs.<i>unex</i>));
<i>has_val</i> = false;
</pre></blockquote>
</li>
<li><p>(4.3) &mdash; Otherwise, if <tt>rhs.has_value()</tt> is <tt>true</tt>, destroys <tt><i>unex</i></tt> 
and sets <tt><i>has_val</i></tt> to <tt>true</tt>.</p></li>
<li><p>(4.4) &mdash; Otherwise, equivalent to <tt><i>unex</i> = <ins>std::move(</ins>rhs.error()<ins>)</ins></tt>.</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3692" href="https://cplusplus.github.io/LWG/lwg-active.html#3692">3692</a>. <tt>zip_view::<i>iterator</i></tt>'s <tt>operator&lt;=&gt;</tt> is overconstrained</h3>
<p><b>Section:</b> 26.7.20.3 <a href="https://wg21.link/range.zip.iterator">[range.zip.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> S. B. Tam <b>Opened:</b> 2022-04-21 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<tt>zip_view::<i>iterator</i></tt>'s <tt>operator&lt;=&gt;</tt> is constrained with 
<tt>(three_way_comparable&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, Views>>> &amp;&amp; ...)</tt>. 
This is unnecessary, because the comparison is performed on the stored <tt><i>tuple-or-pair</i></tt>, 
and both <tt>std::tuple</tt> and <tt>std::pair</tt> provide <tt>operator&lt;=&gt;</tt> regardless of 
whether the elements are three-way comparable.
<p/>
Note that, because neither <tt>std::tuple</tt> nor <tt>std::pair</tt> provides <tt>operator&lt;</tt> 
since C++20, comparing two <tt>zip::<i>iterator</i></tt>s with <tt>operator&lt;</tt> (which is specified 
to return <tt>x.<i>current_</i> &lt; y.<i>current_</i></tt>, where <tt><i>current_</i></tt> is a 
<tt><i>tuple-or-pair</i></tt>) eventually uses <tt>tuple</tt> or <tt>pair</tt>'s <tt>operator&lt;=&gt;</tt> 
anyway.
<p/>
Thus, I think it's possible to make <tt>operator&lt;=&gt;</tt> not require <tt>three_way_comparable</tt>. 
This also makes it possible to remove the operator functions for <tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, 
<tt>&gt;=</tt> and rely on the operators synthesized from <tt>operator&lt;=&gt;</tt>.
</p>

<p><i>[2022-04-24; Daniel comments and provides wording]</i></p>

<p>
It should be pointed out that by still constraining <tt>operator&lt;=&gt;</tt> with 
<tt><i>all-random-access</i>&lt;Const, Views...&gt;</tt> we also constrain by 
<tt>random_access_iterator&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, Views&gt;&gt;&gt;</tt>
which again means that we constrain by 
<tt>totally_ordered&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, Views&gt;&gt;&gt;</tt>, so
this operator will only be satisfied with iterators <tt>I</tt> that satisfy 
<tt><i>partially-ordered-with</i>&lt;I, I&gt;</tt>. Based on this argument the delegation to
<tt><i>tuple-or-pair</i></tt>'s <tt>operator&lt;=&gt;</tt> that solely depends on 
<tt><i>synth-three-way</i></tt> should be appropriate.
</p>

<p><i>[2022-05-17; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]
  template&lt;input_range... Views&gt;
    requires (view&lt;Views&gt; &amp;&amp; ...) &amp;&amp; (sizeof...(Views) &gt; 0)
  template&lt;bool Const&gt;
  class zip_view&lt;Views...&gt;::<i>iterator</i> {
    <i>tuple-or-pair</i>&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, Views&gt;&gt;...&gt; <i>current_</i>; <i>// exposition only</i>
    constexpr explicit <i>iterator</i>(<i>tuple-or-pair</i>&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, Views&gt;&gt;...&gt;); <i>// exposition only</i>
  public:
    [&hellip;]
    friend constexpr bool operator==(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires (equality_comparable&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, Views&gt;&gt;&gt; &amp;&amp; ...);
    
    <del>friend constexpr bool operator&lt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires <i>all-random-access</i>&lt;Const, Views...&gt;;
    friend constexpr bool operator&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires <i>all-random-access</i>&lt;Const, Views...&gt;;
    friend constexpr bool operator&lt;=(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires <i>all-random-access</i>&lt;Const, Views...&gt;;
    friend constexpr bool operator&gt;=(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires <i>all-random-access</i>&lt;Const, Views...&gt;;</del>
    friend constexpr auto operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires <i>all-random-access</i>&lt;Const, Views...&gt; <del>&amp;&amp;
               three_way_comparable&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, Views&gt;&gt;&gt; &amp;&amp; ...)</del>;    
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
[&hellip;]
<pre>
<del>friend constexpr bool operator&lt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires <i>all-random-access</i>&lt;Const, Views...&gt;;</del>
</pre>
<blockquote>
<p>
<del>-16- <i>Returns:</i> <tt>x.<i>current_</i> &lt; y.<i>current_</i></tt>.</del>
</p>
</blockquote>
<pre>
<del>friend constexpr bool operator&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires <i>all-random-access</i>&lt;Const, Views...&gt;;</del>
</pre>
<blockquote>
<p>
<del>-17- <i>Effects:</i> Equivalent to: <tt>return y &lt; x;</tt></del>
</p>
</blockquote>
<pre>
<del>friend constexpr bool operator&lt;=(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires <i>all-random-access</i>&lt;Const, Views...&gt;;</del>
</pre>
<blockquote>
<p>
<del>-18- <i>Effects:</i> Equivalent to: <tt>return !(y &lt; x);</tt></del>
</p>
</blockquote>
<pre>
<del>friend constexpr bool operator&gt;=(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires <i>all-random-access</i>&lt;Const, Views...&gt;;</del>
</pre>
<blockquote>
<p>
<del>-19- <i>Effects:</i> Equivalent to: <tt>return !(x &lt; y);</tt></del>
</p>
</blockquote>
<pre>
friend constexpr auto operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires <i>all-random-access</i>&lt;Const, Views...&gt; <del>&amp;&amp;
          (three_way_comparable&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, Views&gt;&gt;&gt; &amp;&amp; ...)</del>;
</pre>
<blockquote>
<p>
-20- <i>Returns:</i> <tt>x.<i>current_</i> &lt;=&gt; y.<i>current_</i></tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3701" href="https://cplusplus.github.io/LWG/lwg-active.html#3701">3701</a>. Make <tt>formatter&lt;remove_cvref_t&lt;const charT[N]&gt;, charT&gt;</tt> requirement explicit</h3>
<p><b>Section:</b> 22.14.6.2 <a href="https://wg21.link/format.formatter.spec">[format.formatter.spec]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Mark de Wever <b>Opened:</b> 2022-05-17 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#format.formatter.spec">active issues</a> in [format.formatter.spec].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#format.formatter.spec">issues</a> in [format.formatter.spec].</p>
<p><b>Discussion:</b></p>
<p>
The wording in 22.14.5 <a href="https://wg21.link/format.functions">[format.functions]</a>/20 and 22.14.5 <a href="https://wg21.link/format.functions">[format.functions]</a>/25 both contain
</p>
<blockquote>
<p>
<tt>formatter&lt;remove_cvref_t&lt;T<sub><i>i</i></sub>&gt;, charT&gt;</tt> meets the <i>BasicFormatter</i> 
requirements (22.14.6.1 <a href="https://wg21.link/formatter.requirements">[formatter.requirements]</a>) for each <tt>T<sub><i>i</i></sub></tt> in <tt>Args</tt>.
</p>
</blockquote>
<p>
The issue is that <tt>remove_cvref_t&lt;const charT[N]&gt;</tt> becomes <tt>charT[N]</tt>. 
22.14.6.2 <a href="https://wg21.link/format.formatter.spec">[format.formatter.spec]</a>/2.2 requires a specialization for
</p>
<blockquote>
<pre>
template&lt;size_t N&gt; struct formatter&lt;const charT[N], charT&gt;;
</pre>
</blockquote>
<p>
but there's no requirement to provide
</p>
<blockquote>
<pre>
 template&lt;size_t N&gt; struct formatter&lt;charT[N], charT&gt;;
</pre>
</blockquote>
<p>
There's no wording preventing library vendors from providing additional specializations. 
So it's possible to implement the current specification but the indirect requirement is odd. 
I noticed this while implementing a <tt>formattable</tt> concept. The concept is based on the 
<tt>formattable</tt> concept of <a href="https://wg21.link/P2286">P2286</a> "Formatting Ranges" (This paper is targeting C++23.)
<p/>
It could be argued that the specialization
</p>
<blockquote>
<pre>
template&lt;size_t N&gt; struct formatter&lt;const charT[N], charT&gt;
</pre>
</blockquote>
<p>
is not needed and should be removed from the Standard. This will be an API break. Vendors 
can decide to keep the no longer required specialization as an extension; which would lead 
to implementation divergence. Microsoft is already shipping this specialization as stable
and Victor doesn't like the removal too.
<p/>
Therefore I only propose to add the required <tt>formatter</tt> specialization.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<p>
-2- Let <tt>charT</tt> be either <tt>char</tt> or <tt>wchar_t</tt>. Each specialization of 
<tt>formatter</tt> is either enabled or disabled, as described below. Each header that declares the 
template <tt>formatter</tt> provides the following enabled specializations:
</p>
<ol style="list-style-type:none">
<li><p>(2.1) &mdash; The specializations [&hellip;]</p></li>
<li><p>(2.2) &mdash; For each <tt>charT</tt>, the string type specializations</p>
<blockquote><pre>
template&lt;&gt; struct formatter&lt;charT*, charT&gt;;
template&lt;&gt; struct formatter&lt;const charT*, charT&gt;;
<ins>template&lt;size_t N&gt; struct formatter&lt;charT[N], charT&gt;;</ins>
template&lt;size_t N&gt; struct formatter&lt;const charT[N], charT&gt;;
template&lt;class traits, class Allocator&gt;
  struct formatter&lt;basic_string&lt;charT, traits, Allocator&gt;, charT&gt;;
template&lt;class traits&gt;
  struct formatter&lt;basic_string_view&lt;charT, traits&gt;, charT&gt;;
</pre></blockquote>
</li>
<li><p>(2.3) &mdash; [&hellip;]</p></li>
<li><p>(2.4) &mdash; [&hellip;]</p></li>
</ol>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3702" href="https://cplusplus.github.io/LWG/lwg-active.html#3702">3702</a>. Should <tt>zip_transform_view::<i>iterator</i></tt> remove <tt>operator&lt;</tt>?</h3>
<p><b>Section:</b> 26.7.21.3 <a href="https://wg21.link/range.zip.transform.iterator">[range.zip.transform.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2022-05-21 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
After LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3692">3692</a>, <tt>zip_view::<i>iterator</i></tt> only provides <tt>operator&lt;=&gt;</tt>. 
Since the comparison of <tt>zip_transform_view::<i>iterator</i></tt> uses <tt>zip_view::<i>iterator</i></tt>'s 
<tt>operator&lt;=&gt;</tt>, it is possible to remove <tt>zip_transform_view::<i>iterator</i></tt>'s 
<tt>operator&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, <tt>&gt;=</tt> and just detect if <tt><i>ziperator</i></tt>'s 
<tt>operator&lt;=&gt;</tt> is available.
<p/>
Since the <tt><i>ziperator</i></tt>'s <tt>operator&lt;=&gt;</tt> is valid only when <tt>zip_view</tt> is a 
<tt>random_access_range</tt>, we don't need to additionally constrain the <tt><i>ziperator</i></tt> to be 
<tt>three_way_comparable</tt>.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
[&hellip;]
template&lt;copy_constructible F, input_range... Views&gt;
requires (view&lt;Views&gt; &amp;&amp; ...) &amp;&amp; (sizeof...(Views) &gt; 0) &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
         regular_invocable&lt;F&amp;, range_reference_t&lt;Views&gt;...&gt; &amp;&amp;
         <i>can-reference</i>&lt;invoke_result_t&lt;F&amp;, range_reference_t&lt;Views&gt;...&gt;&gt;
template&lt;bool Const&gt;
class zip_transform_view&lt;F, Views...&gt;::<i>iterator</i> {
  using <i>Parent</i> = <i>maybe-const&lt;</i>Const, zip_transform_view&gt;;        // exposition only
  using <i>Base</i> = <i>maybe-const</i>&lt;Const, <i>InnerView</i>&gt;;                   // exposition only
  <i>Parent</i>* <i>parent_</i> = nullptr;                                    // exposition only
  <i>ziperator</i>&lt;Const&gt; <i>inner_</i>;                                      // exposition only

  constexpr <i>iterator</i>(<i>Parent</i>&amp; parent, <i>ziperator</i>&lt;Const&gt; inner);   // exposition only
public:
  [&hellip;]
  friend constexpr bool operator==(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires equality_comparable&lt;<i>ziperator</i>&lt;Const&gt;&gt;;
  
  <del>friend constexpr bool operator&lt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires random_access_range&lt;<i>Base</i>&gt;;
  friend constexpr bool operator&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires random_access_range&lt;<i>Base</i>&gt;;
  friend constexpr bool operator&lt;=(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires random_access_range&lt;<i>Base</i>&gt;;
  friend constexpr bool operator&gt;=(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires random_access_range&lt;<i>Base</i>&gt;;</del>
  friend constexpr auto operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires random_access_range&lt;<i>Base</i>&gt;<del>&amp;&amp; three_way_comparable&lt;<i>ziperator</i>&lt;Const&gt;&gt;</del>;
  [&hellip;]
};
[&hellip;]
}
</pre>
</blockquote>
[&hellip;]
<pre>
friend constexpr bool operator==(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires equality_comparable&lt;<i>ziperator</i>&lt;Const&gt;&gt;;
<del>friend constexpr bool operator&lt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires random_access_range&lt;<i>Base</i>&gt;;
friend constexpr bool operator&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires random_access_range&lt;<i>Base</i>&gt;;
friend constexpr bool operator&lt;=(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires random_access_range&lt;<i>Base</i>&gt;;
friend constexpr bool operator&gt;=(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires random_access_range&lt;<i>Base</i>&gt;;</del>
friend constexpr auto operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  requires random_access_range&lt;<i>Base</i>&gt;<del>&amp;&amp; three_way_comparable&lt;<i>ziperator</i>&lt;Const&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-14- Let <tt><i>op</i></tt> be the operator.
</p>
<p>
-15- <i>Effects</i>: Equivalent to: <tt>return x.<i>inner_</i> <i>op</i> y.<i>inner_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3703" href="https://cplusplus.github.io/LWG/lwg-active.html#3703">3703</a>. Missing requirements for <tt>expected&lt;T, E&gt; requires is_void&lt;T&gt;</tt></h3>
<p><b>Section:</b> 22.8.7.1 <a href="https://wg21.link/expected.void.general">[expected.void.general]</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> 2022-05-24 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
The partial specialization <tt>expected&lt;T, E&gt; requires is_void&lt;T&gt;</tt> specified in 
22.8.7.1 <a href="https://wg21.link/expected.void.general">[expected.void.general]</a> is missing some template parameter requirements that should 
have been copied from 22.8.6.1 <a href="https://wg21.link/expected.object.general">[expected.object.general]</a>. We should copy the pertinent 
requirements from the first two paragraphs of the latter subclause into new paragraphs in the first 
subclause (the pertinent requirement from the third paragraph is already present in 
22.8.7.1 <a href="https://wg21.link/expected.void.general">[expected.void.general]</a>).
</p>

<p><i>[2022-06-21; Jonathan adds "<ins>Member</ins>" before "<tt>has_val</tt>"]</i></p>



<p><i>[2022-06-21; Reflector poll]</i></p>

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


<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<blockquote class="note">
<p>
[<i>Drafting note:</i> There is some drive-by cleanup that I couldn't resist while touching this wording: (1) 
strike the redundant "suitably aligned" guarantee, (2) Don't repeat in prose that the exposition-only members 
are exposition-only.]
</p>
</blockquote>

<ol>
<li><p>Modify 22.8.6.1 <a href="https://wg21.link/expected.object.general">[expected.object.general]</a> as indicated:</p>

<blockquote>
<p>
-1- Any object of type <tt>expected&lt;T, E&gt;</tt> either contains a value of type <tt>T</tt> or a value 
of type <tt>E</tt> within its own storage. Implementations are not permitted to use additional storage, such 
as dynamic memory, to allocate the object of type <tt>T</tt> or the object of type <tt>E</tt>. <del>These objects 
are allocated in a region of the <tt>expected&lt;T, E&gt;</tt> storage suitably aligned for the types <tt>T</tt> 
and <tt>E</tt>. Members <tt><i>has_val</i></tt>, <tt><i>val</i></tt>, and <tt><i>unex</i></tt> are provided 
for exposition only.</del> <ins>Member</ins> <tt><i>has_val</i></tt> indicates whether the <tt>expected&lt;T, E&gt;</tt> object 
contains an object of type <tt>T</tt>.
</p>
</blockquote>
</li>

<li><p>Modify 22.8.7.1 <a href="https://wg21.link/expected.void.general">[expected.void.general]</a> as indicated:</p>

<blockquote>
<p>
<ins>-?- Any object of type <tt>expected&lt;T, E&gt;</tt> either represents a value of type <tt>T</tt>, or contains 
a value of type <tt>E</tt> within its own storage. Implementations are not permitted to use additional storage, 
such as dynamic memory, to allocate the object of type <tt>E</tt>. Member <tt><i>has_val</i></tt> indicates whether the 
<tt>expected&lt;T, E&gt;</tt> object represents a value of type <tt>T</tt>.</ins>
<p/>
<ins>-?- A program that instantiates the definition of the template <tt>expected&lt;T, E&gt;</tt> with a type for the 
<tt>E</tt> parameter that is not a valid template argument for <tt>unexpected</tt> is ill-formed.</ins>
<p/>
-1- <tt>E</tt> shall meet the requirements of <i>Cpp17Destructible</i> (Table [tab:cpp17.destructible]).
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3704" href="https://cplusplus.github.io/LWG/lwg-active.html#3704">3704</a>. LWG 2059 added overloads that might be ill-formed for sets</h3>
<p><b>Section:</b> 24.4.6.1 <a href="https://wg21.link/set.overview">[set.overview]</a>, 24.4.7.1 <a href="https://wg21.link/multiset.overview">[multiset.overview]</a>, 24.5.6.1 <a href="https://wg21.link/unord.set.overview">[unord.set.overview]</a>, 24.5.7.1 <a href="https://wg21.link/unord.multiset.overview">[unord.multiset.overview]</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> 2022-05-25 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The restored <tt>erase(iterator)</tt> overloads introduced by LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2059">2059</a> would be duplicates 
of the <tt>erase(const_iterator)</tt> ones if <tt>iterator</tt> and <tt>const_iterator</tt> are the same 
type, which is allowed for sets.
<p/>
We should constrain them (or add prose) so that the <tt>erase(iterator)</tt> overloads are only present 
when the iterator types are distinct.
<p/>
This applies to <tt>set</tt>, <tt>multiset</tt>, <tt>unordered_set</tt>, <tt>unordered_multiset</tt> 
(and <tt>flat_set</tt> and <tt>flat_multiset</tt>).
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 24.4.6.1 <a href="https://wg21.link/set.overview">[set.overview]</a>, class template <tt>set</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
iterator erase(iterator position) <ins>requires (!same_as&lt;iterator, const_iterator&gt;)</ins>;
iterator erase(const_iterator position);
</pre>
</blockquote>
</li>

<li><p>Modify 24.4.7.1 <a href="https://wg21.link/multiset.overview">[multiset.overview]</a>, class template <tt>multiset</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
iterator erase(iterator position) <ins>requires (!same_as&lt;iterator, const_iterator&gt;)</ins>;
iterator erase(const_iterator position);
</pre>
</blockquote>
</li>

<li><p>Modify 24.5.6.1 <a href="https://wg21.link/unord.set.overview">[unord.set.overview]</a>, class template <tt>unordered_set</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
iterator erase(iterator position) <ins>requires (!same_as&lt;iterator, const_iterator&gt;)</ins>;
iterator erase(const_iterator position);
</pre>
</blockquote>
</li>

<li><p>Modify 24.5.7.1 <a href="https://wg21.link/unord.multiset.overview">[unord.multiset.overview]</a>, class template <tt>unordered_multiset</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
iterator erase(iterator position) <ins>requires (!same_as&lt;iterator, const_iterator&gt;)</ins>;
iterator erase(const_iterator position);
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3705" href="https://cplusplus.github.io/LWG/lwg-active.html#3705">3705</a>. Hashability shouldn't depend on <tt>basic_string</tt>'s allocator</h3>
<p><b>Section:</b> 23.4.6 <a href="https://wg21.link/basic.string.hash">[basic.string.hash]</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> 2022-05-26 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#basic.string.hash">issues</a> in [basic.string.hash].</p>
<p><b>Discussion:</b></p>
<p>
23.4.6 <a href="https://wg21.link/basic.string.hash">[basic.string.hash]</a> says:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<pre>
template&lt;&gt; struct hash&lt;string&gt;;
template&lt;&gt; struct hash&lt;u8string&gt;;
template&lt;&gt; struct hash&lt;u16string&gt;;
template&lt;&gt; struct hash&lt;u32string&gt;;
template&lt;&gt; struct hash&lt;wstring&gt;;
template&lt;&gt; struct hash&lt;pmr::string&gt;;
template&lt;&gt; struct hash&lt;pmr::u8string&gt;;
template&lt;&gt; struct hash&lt;pmr::u16string&gt;;
template&lt;&gt; struct hash&lt;pmr::u32string&gt;;
template&lt;&gt; struct hash&lt;pmr::wstring&gt;;
</pre>
<blockquote>
<p>
-1- If <tt>S</tt> is one of these string types, <tt>SV</tt> is the corresponding string view type, and 
<tt>s</tt> is an object of type <tt>S</tt>, then <tt>hash&lt;S&gt;()(s) == hash&lt;SV&gt;()(SV(s))</tt>
</p>
</blockquote>
</blockquote>
<p>
Despite that the hash value of a <tt>basic_string</tt> object is equivalent to the hash value of a 
corresponding <tt>basic_string_view</tt> object, which has no allocator, the capability to hash a 
<tt>basic_string</tt> depends on its allocator. All of the enabled specializations have specific 
allocators, which fact becomes more clear if we expand the type aliases:
</p>
<blockquote><pre>
template&lt;&gt; struct hash&lt;basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt;&gt;;
template&lt;&gt; struct hash&lt;basic_string&lt;char8_t, char_traits&lt;char8_t&gt;, allocator&lt;char8_t&gt;&gt;;

template&lt;&gt; struct hash&lt;basic_string&lt;char16_t, char_traits&lt;char16_t&gt;, allocator&lt;char16_t&gt;&gt;;

template&lt;&gt; struct hash&lt;basic_string&lt;char32_t, char_traits&lt;char32_t&gt;, allocator&lt;char32_t&gt;&gt;;

template&lt;&gt; struct hash&lt;basic_string&lt;wchar_t, char_traits&lt;wchar_t&gt;, allocator&lt;wchar_t&gt;&gt;;

template&lt;&gt; struct hash&lt;basic_string&lt;char, char_traits&lt;char&gt;, pmr::polymorphic_allocator&lt;char&gt;&gt;;
template&lt;&gt; struct hash&lt;basic_string&lt;char8_t, char_traits&lt;char8_t&gt;, pmr::polymorphic_allocator&lt;char8_t&gt;&gt;;

template&lt;&gt; struct hash&lt;basic_string&lt;char16_t, char_traits&lt;char16_t&gt;, pmr::polymorphic_allocator&lt;char16_t&gt;&gt;;

template&lt;&gt; struct hash&lt;basic_string&lt;char32_t, char_traits&lt;char32_t&gt;, pmr::polymorphic_allocator&lt;char32_t&gt;&gt;;

template&lt;&gt; struct hash&lt;basic_string&lt;wchar_t, char_traits&lt;wchar_t&gt;, pmr::polymorphic_allocator&lt;wchar_t&gt;&gt;;
</pre></blockquote>
<p>
If the hash value doesn't depend on the allocator type, why should we care about the allocator type? 
I posit that we should not, and that these ten explicit specializations should be replaced by 5 partial 
specializations that enable hashing <tt>basic_string</tt> specializations using these combinations of 
character type and traits type with any allocator type.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<pre>
[&hellip;]

<i>// 23.4.6 <a href="https://wg21.link/basic.string.hash">[basic.string.hash]</a>, hash support</i>
template&lt;class T&gt; struct hash;
<del>template&lt;&gt; struct hash&lt;string&gt;;
template&lt;&gt; struct hash&lt;u8string&gt;;
template&lt;&gt; struct hash&lt;u16string&gt;;
template&lt;&gt; struct hash&lt;u32string&gt;;
template&lt;&gt; struct hash&lt;wstring&gt;;
template&lt;&gt; struct hash&lt;pmr::string&gt;;
template&lt;&gt; struct hash&lt;pmr::u8string&gt;;
template&lt;&gt; struct hash&lt;pmr::u16string&gt;;
template&lt;&gt; struct hash&lt;pmr::u32string&gt;;
template&lt;&gt; struct hash&lt;pmr::wstring&gt;;</del>
<ins>template&lt;class A&gt; struct hash&lt;basic_string&lt;char, char_traits&lt;char&gt;, A&gt;&gt;;
template&lt;class A&gt; struct hash&lt;basic_string&lt;char8_t, char_traits&lt;char8_t&gt;, A&gt;&gt;;
template&lt;class A&gt; struct hash&lt;basic_string&lt;char16_t, char_traits&lt;char16_t&gt;, A&gt;&gt;;
template&lt;class A&gt; struct hash&lt;basic_string&lt;char32_t, char_traits&lt;char32_t&gt;, A&gt;&gt;;
template&lt;class A&gt; struct hash&lt;basic_string&lt;wchar_t, char_traits&lt;wchar_t&gt;, A&gt;&gt;;</ins>

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

<li><p>Modify 23.4.6 <a href="https://wg21.link/basic.string.hash">[basic.string.hash]</a> as indicated:</p>

<blockquote>
<pre>
<del>template&lt;&gt; struct hash&lt;string&gt;;
template&lt;&gt; struct hash&lt;u8string&gt;;
template&lt;&gt; struct hash&lt;u16string&gt;;
template&lt;&gt; struct hash&lt;u32string&gt;;
template&lt;&gt; struct hash&lt;wstring&gt;;
template&lt;&gt; struct hash&lt;pmr::string&gt;;
template&lt;&gt; struct hash&lt;pmr::u8string&gt;;
template&lt;&gt; struct hash&lt;pmr::u16string&gt;;
template&lt;&gt; struct hash&lt;pmr::u32string&gt;;
template&lt;&gt; struct hash&lt;pmr::wstring&gt;;</del>
<ins>template&lt;class A&gt; struct hash&lt;basic_string&lt;char, char_traits&lt;char&gt;, A&gt;&gt;;
template&lt;class A&gt; struct hash&lt;basic_string&lt;char8_t, char_traits&lt;char8_t&gt;, A&gt;&gt;;
template&lt;class A&gt; struct hash&lt;basic_string&lt;char16_t, char_traits&lt;char16_t&gt;, A&gt;&gt;;
template&lt;class A&gt; struct hash&lt;basic_string&lt;char32_t, char_traits&lt;char32_t&gt;, A&gt;&gt;;
template&lt;class A&gt; struct hash&lt;basic_string&lt;wchar_t, char_traits&lt;wchar_t&gt;, A&gt;&gt;;</ins>
</pre>
<blockquote>
<p>
-1- If <tt>S</tt> is one of these string types, <tt>SV</tt> is the corresponding string view type, and 
<tt>s</tt> is an object of type <tt>S</tt>, then <tt>hash&lt;S&gt;()(s) == hash&lt;SV&gt;()(SV(s))</tt>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3707" href="https://cplusplus.github.io/LWG/lwg-active.html#3707">3707</a>. <tt>chunk_view::<i>outer-iterator</i>::value_type::size</tt> should return unsigned type</h3>
<p><b>Section:</b> 26.7.24.4 <a href="https://wg21.link/range.chunk.outer.value">[range.chunk.outer.value]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2022-06-01 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
Currently, the <tt>size</tt> function of <tt>chunk_view::<i>outer-iterator</i>::value_type</tt> returns 
the result of <tt>ranges::min</tt>, since the operands are of type <tt>range_difference_t&lt;V&gt;</tt>, 
this will return a signed type, which is inconsistent with the return type of <tt>size</tt> of the 
<tt>forward</tt>-version of <tt>chunk_view::<i>iterator</i>::value_type</tt> (26.7.24.7 <a href="https://wg21.link/range.chunk.fwd.iter">[range.chunk.fwd.iter]</a>), 
which always returns an unsigned type.
</p>
<p>
I think it's more reasonable to return an unsigned type, since this is intentional behavior and 
doesn't fall back to using the default <tt>view_interface::size</tt>.
And if LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3646">3646</a> is eventually adopted, there's no reason why it shouldn't be made 
unsigned.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 26.7.24.4 <a href="https://wg21.link/range.chunk.outer.value">[range.chunk.outer.value]</a> as indicated:</p>

<blockquote>
<pre>
constexpr auto size() const
  requires sized_sentinel_for&lt;sentinel_t&lt;V&gt;, iterator_t&lt;V&gt;&gt;;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return <ins><i>to-unsigned-like</i>(</ins>ranges::min(<i>parent_</i>-&gt;<i>remainder_</i>, ranges::end(<i>parent_</i>-&gt;<i>base_</i>) - *<i>parent_</i>-&gt;<i>current_</i>)<ins>)</ins>;
</pre></blockquote>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3708" href="https://cplusplus.github.io/LWG/lwg-active.html#3708">3708</a>. <tt>take_while_view::<i>sentinel</i></tt>'s conversion constructor should move</h3>
<p><b>Section:</b> 26.7.9.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">Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2022-06-03 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The conversion constructor of <tt>take_while_view::<i>sentinel</i></tt> requires 
<tt>sentinel_t&lt;V&gt;</tt> must satisfy <tt>convertible_to&lt;sentinel_t&lt;<i>Base</i>&gt;&gt;</tt>, 
which indicates that the rvalue reference of <tt>sentinel_t&lt;V&gt;</tt> can be converted to 
<tt>sentinel_t&lt;<i>Base</i>&gt;</tt>, but in the <i>Effects</i> element, we assign the lvalue 
<tt>s.<i>end_</i></tt> to <tt><i>end_</i></tt>.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<pre>
constexpr <i>sentinel</i>(<i>sentinel</i>&lt;!Const&gt; s)
  requires Const &amp;&amp; convertible_to&lt;sentinel_t&lt;V&gt;, sentinel_t&lt;<i>Base</i>&gt;&gt;;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> Initializes <tt><i>end_</i></tt> with <tt><ins>std::move(</ins>s.<i>end_</i><ins>)</ins></tt> and <tt>pred_</tt> with <tt>s.<i>pred_</i></tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3709" href="https://cplusplus.github.io/LWG/lwg-active.html#3709">3709</a>. LWG-3703 was underly ambitious</h3>
<p><b>Section:</b> 22.5.3.1 <a href="https://wg21.link/optional.optional.general">[optional.optional.general]</a>, 22.6.3.1 <a href="https://wg21.link/variant.variant.general">[variant.variant.general]</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> 2022-06-08 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3703">3703</a> struck redundant language from 22.8.7.1 <a href="https://wg21.link/expected.void.general">[expected.void.general]</a> specifying that 
(1) space allocated for an object is suitably aligned, and (2) a member annotated <tt><i>// exposition only</i></tt> 
in a class synopsis "is provided for exposition only." 
<p/>
Let's also strike similar occurrences from the wording for <tt>optional</tt> and <tt>variant</tt>.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<p>
-1- Any instance of <tt>optional&lt;T&gt;</tt> at any given time either contains a value 
or does not contain a value. When an instance of <tt>optional&lt;T&gt;</tt> <i>contains a value</i>, 
it means that an object of type <tt>T</tt>, referred to as the optional object's <i>contained value</i>, 
is allocated within the storage of the optional object. Implementations are not permitted to use 
additional storage, such as dynamic memory, to allocate its contained value. <del>The contained
value shall be allocated in a region of the <tt>optional&lt;T&gt;</tt> storage suitably aligned 
for the type <tt>T</tt>.</del> When an object of type <tt>optional&lt;T&gt;</tt> is contextually 
converted to <tt>bool</tt>, the conversion returns <tt>true</tt> if the object contains a value; 
otherwise the conversion returns <tt>false</tt>.
<p/>
-2- <del>Member <tt>val</tt> is provided for exposition only.</del> When an <tt>optional&lt;T&gt;</tt> 
object contains a value, <ins>member</ins> <tt>val</tt> points to the contained value.
</p>
</blockquote>
</li>

<li><p>Modify 22.6.3.1 <a href="https://wg21.link/variant.variant.general">[variant.variant.general]</a> as indicated:</p>

<blockquote>
<p>
-1- Any instance of <tt>variant</tt> at any given time either holds a value of one of its alternative 
types or holds no value. When an instance of <tt>variant</tt> holds a value of alternative type <tt>T</tt>, 
it means that a value of type <tt>T</tt>, referred to as the <tt>variant</tt> object's <i>contained value</i>, 
is allocated within the storage of the <tt>variant</tt> object. Implementations are not permitted to use 
additional storage, such as dynamic memory, to allocate the contained value. <del>The contained value shall 
be allocated in a region of the variant storage suitably aligned for all types in <tt>Types</tt>.</del>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3710" href="https://cplusplus.github.io/LWG/lwg-active.html#3710">3710</a>. The <tt>end</tt> of <tt>chunk_view</tt> for input ranges can be <tt>const</tt></h3>
<p><b>Section:</b> 26.7.24.2 <a href="https://wg21.link/range.chunk.view.input">[range.chunk.view.input]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2022-06-09 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.chunk.view.input">active issues</a> in [range.chunk.view.input].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.chunk.view.input">issues</a> in [range.chunk.view.input].</p>
<p><b>Discussion:</b></p>
<p>
The input range version of <tt>chunk_view</tt>'s <tt>end</tt> is a very simple function that only returns 
<tt>default_sentinel</tt>, and simple <tt>end</tt>s like this also appear in other range adaptors, such 
as <tt>basic_istream_view</tt>, <tt>lazy_split_view::<i>outer-iterator</i>::value_type</tt>, and 
<tt>chunk_view::<i>outer-iterator</i>::value_type</tt>. 
<p/>
However, unlike <tt>chunk_view</tt>, their <tt>end</tt>s all are <tt>const</tt>-qualified, 
which allows us to freely get <tt>default_sentinel</tt> through the <tt>end</tt> of these <tt>const</tt> 
objects even though they may not themselves be <tt>range</tt>s.
<p/>
I think we should add <tt>const</tt> to this <tt>chunk_view</tt>'s <tt>end</tt> as 
I don't see any harm in doing this, and in some cases, it may have a certain value. Also, this makes it 
consistent with <tt>basic_istream_view</tt> and the upcoming <tt>std::generator</tt>, which, like it, only 
has a non-<tt>const begin</tt>.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]
 
  template&lt;view V&gt;
    requires input_range&lt;V&gt;
  class chunk_view : public view_interface&lt;chunk_view&lt;V&gt;&gt; {
    V <i>base_</i> = V();                                        <i>// exposition only</i>
    [&hellip;]
  public:
    [&hellip;]

    constexpr <i>outer-iterator</i> begin();
    constexpr default_sentinel_t end() <ins>const</ins> noexcept;

    constexpr auto size() requires sized_range&lt;V&gt;;
    constexpr auto size() const requires sized_range&lt;const V&gt;;
  };
  [&hellip;]
}
</pre>
</blockquote>
[&hellip;]
<pre>
constexpr default_sentinel_t end() <ins>const</ins> noexcept;
</pre>
<blockquote>
<p>
-4- <i>Returns</i>: <tt>default_sentinel</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3711" href="https://cplusplus.github.io/LWG/lwg-active.html#3711">3711</a>. Missing preconditions for <tt>slide_view</tt> constructor</h3>
<p><b>Section:</b> 26.7.25.2 <a href="https://wg21.link/range.slide.view">[range.slide.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2022-06-10 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
It doesn't make sense for <tt>slide_view</tt> when <tt>n</tt> is not positive, 
we should therefore add a precondition for its constructor just like we did for 
<tt>chunk_view</tt>.
<p/>
<i>Daniel:</i>
<p/>
Indeed the accepted paper describes the intention in
<a href="https://wg21.link/p2442r1#slide">P2442R1 Section 4.2</a> by saying that 
"It is a precondition that <tt>N</tt> is positive" in the design wording
but omitted to add a normative precondition in the proposed wording.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<pre>
constexpr explicit slide_view(V base, range_difference_t&lt;V&gt; n);
</pre>
<blockquote>
<p>
<ins>-?- <i>Preconditions</i>: <tt>n &gt; 0</tt> is <tt>true</tt>.</ins>
<p/>
-1- <i>Effects</i>: Initializes <tt><i>base_</i></tt> with <tt>std::move(base)</tt> and <tt><i>n_</i></tt> with <tt>n</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3712" href="https://cplusplus.github.io/LWG/lwg-active.html#3712">3712</a>. <tt>chunk_view</tt> and <tt>slide_view</tt> should not be <tt>default_initializable</tt></h3>
<p><b>Section:</b> 26.7.24.2 <a href="https://wg21.link/range.chunk.view.input">[range.chunk.view.input]</a>, 26.7.24.6 <a href="https://wg21.link/range.chunk.view.fwd">[range.chunk.view.fwd]</a>, 26.7.25.2 <a href="https://wg21.link/range.slide.view">[range.slide.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2022-06-10 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.chunk.view.input">active issues</a> in [range.chunk.view.input].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.chunk.view.input">issues</a> in [range.chunk.view.input].</p>
<p><b>Discussion:</b></p>
<p>
Both <tt>chunk_view</tt> and <tt>slide_view</tt> have a precondition that <tt>N</tt> must be positive, 
but they are still <tt>default_initializable</tt> when the underlying range is <tt>default_initializable</tt>, 
which makes the member variable <tt><i>n_</i></tt> initialized with an invalid value <tt>0</tt> when they 
are default-constructed, which produces the following unexpected result:
</p>
<blockquote><pre>
#include &lt;ranges&gt;

using V = std::ranges::iota_view&lt;int, int&gt;;
static_assert(std::ranges::slide_view&lt;V&gt;().empty()); // <span style="color:red;font-weight:bolder">fails</span>
static_assert(std::ranges::chunk_view&lt;V&gt;().empty()); // <span style="color:red;font-weight:bolder">division by zero is not a constant expression</span>
</pre></blockquote>
<p>
Although we could provide a default positive value for <tt><i>n_</i></tt>, I think a more appropriate solution 
would be to not provide the default constructor, since default-constructed values for integer types will 
never be valid.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]
 
  template&lt;view V&gt;
    requires input_range&lt;V&gt;
  class chunk_view : public view_interface&lt;chunk_view&lt;V&gt;&gt; {
    V <i>base_</i> <del>= V()</del>;                                        <i>// exposition only</i>
    range_difference_t&lt;V&gt; <i>n_</i> <del>= 0</del>;                         <i>// exposition only</i>
    range_difference_t&lt;V&gt; <i>remainder_</i> = 0;                 <i>// exposition only</i>
    [&hellip;]
  public:
    <del>chunk_view() requires default_initializable&lt;V&gt; = default;</del>
    constexpr explicit chunk_view(V base, range_difference_t&lt;V&gt; n);
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 26.7.24.6 <a href="https://wg21.link/range.chunk.view.fwd">[range.chunk.view.fwd]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;view V&gt;
    requires forward_range&lt;V&gt;
  class chunk_view&lt;V&gt; : public view_interface&lt;chunk_view&lt;V&gt;&gt; {
    V <i>base_</i> <del>= V()</del>;                   <i>// exposition only</i>
    range_difference_t&lt;V&gt; <i>n_</i> <del>= 0</del>;    <i>// exposition only</i>
    [&hellip;]
  public:
    <del>chunk_view() requires default_initializable&lt;V&gt; = default;</del>
    constexpr explicit chunk_view(V base, range_difference_t&lt;V&gt; n);

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

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

<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]

  template&lt;forward_range V&gt;
    requires view&lt;V&gt;
  class slide_view : public view_interface&lt;slide_view&lt;V&gt;&gt; {
    V <i>base_</i> <del>= V()</del>;                      <i>// exposition only</i>
    range_difference_t&lt;V&gt; <i>n_</i> <del>= 0</del>;       <i>// exposition only</i>
    [&hellip;]
  public:
    <del>slide_view() requires default_initializable&lt;V&gt; = default;</del>
    constexpr explicit slide_view(V base, range_difference_t&lt;V&gt; n);

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

</ol>





<hr>
<h3><a name="3713" href="https://cplusplus.github.io/LWG/lwg-active.html#3713">3713</a>. Sorted with respect to comparator (only)</h3>
<p><b>Section:</b> 27.8.1 <a href="https://wg21.link/alg.sorting.general">[alg.sorting.general]</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> 2022-06-10 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P0896R4">P0896R4</a> changed the term of art "sorted with respect to comparator" defined in 
27.8.1 <a href="https://wg21.link/alg.sorting.general">[alg.sorting.general]</a> paragraph 5 to "sorted with respect to comparator and projection." 
That proposal updated the algorithm specifications consistently. However, there were uses of the old 
term outside of 27 <a href="https://wg21.link/algorithms">[algorithms]</a> that are now without meaning. We should bring back the term 
"sorted with respect to comparator" to fix that lack.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<p>
-5- A sequence is <i>sorted with respect to a <tt>comp</tt> and <tt>proj</tt></i> for a comparator and projection 
<tt>comp</tt> and <tt>proj</tt> if for every iterator <tt>i</tt> pointing to the sequence and every non-negative 
integer <tt>n</tt> such that <tt>i + n</tt> is a valid iterator pointing to an element of the sequence,
</p>
<blockquote><pre>
bool(invoke(comp, invoke(proj, *(i + n)), invoke(proj, *i)))
</pre></blockquote>
<p>
is <tt>false</tt>.
<p/>
<ins>-?- A sequence is <i>sorted with respect to a comparator <tt>comp</tt></i> for a comparator <tt>comp</tt> 
if it is sorted with respect to <tt>comp</tt> and <tt>identity{}</tt> (the identity projection).</ins>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3715" href="https://cplusplus.github.io/LWG/lwg-active.html#3715">3715</a>. <tt>view_interface::empty</tt> is overconstrained</h3>
<p><b>Section:</b> 26.5.3.1 <a href="https://wg21.link/view.interface.general">[view.interface.general]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2022-06-12 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#view.interface.general">active issues</a> in [view.interface.general].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#view.interface.general">issues</a> in [view.interface.general].</p>
<p><b>Discussion:</b></p>
<p>
Currently, <tt>view_interface::empty</tt> has the following constraints
</p>
<blockquote><pre>
constexpr bool empty() requires forward_range&lt;D&gt; {
  return ranges::begin(<i>derived</i>()) == ranges::end(<i>derived</i>());
}
</pre></blockquote>
<p>
which seems reasonable, since we need to guarantee the equality preservation of the expression 
<tt>ranges::begin(r)</tt>.
<p/>
However, this prevents a more efficient way in some cases, i.e., when <tt>D</tt> models 
<tt>sized_range</tt>, we only need to determine whether the value of <tt>ranges::size</tt> is <tt>0</tt>.
Since <tt>sized_range</tt> and <tt>forward_range</tt> are orthogonal to each other, this also 
prevents any range that models <tt>sized_range</tt> but not <tt>forward_range</tt>.
<p/>
Consider:
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;ranges&gt;

int main() {
  auto f = std::views::iota(0, 5)
         | std::views::filter([](int) { return true; });
  auto r = std::views::counted(f.begin(), 4)
         | std::views::slide(2);
  std::cout &lt;&lt; (r.size() == 0) &lt;&lt; "\n"; // #1
  std::cout &lt;&lt; r.empty() &lt;&lt; "\n";       // #2, <span style="color:red;font-weight:bolder">calls r.begin() == r.end()</span>
}
</pre></blockquote>
<p>
Since <tt>r</tt> models <tt>sized_range</tt>, <tt>#1</tt> will invoke <tt>slide_view::size</tt>, 
which mainly invokes <tt>ranges::distance</tt>; However, <tt>#2</tt> invokes <tt>view_interface::empty</tt> 
and evaluates <tt>r.begin() == r.end()</tt>, which constructs the iterator, invokes <tt>ranges::next</tt>, 
and caches the result, which is unnecessary.
<p/>
Also consider:
</p> 
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;ranges&gt;

int main() {
  auto i = std::views::istream&lt;int&gt;(std::cin);
  auto r = std::views::counted(i.begin(), 4)
         | std::views::chunk(2);
  std::cout &lt;&lt; (r.size() == 0) &lt;&lt; "\n"; // #1
  std::cout &lt;&lt; !r &lt;&lt; "\n";              // #2, equivalent to r.size() == 0
  std::cout &lt;&lt; r.empty() &lt;&lt; "\n";       // #3, <span style="color:red;font-weight:bolder">ill-formed</span>
}
</pre></blockquote>
<p>
Since <tt>r</tt> is still <tt>sized_range</tt>, <tt>#1</tt> will invoke <tt>chunk_view::size</tt>.
<tt>#2</tt> is also well-formed since <tt>view_interface::operator bool</tt> only requires the 
expression <tt>ranges::empty(r)</tt> to be well-formed, which first determines the validity of 
<tt>r.empty()</tt>, and ends up evaluating <tt>#1</tt>; However, <tt>#3</tt> is ill-formed since 
<tt>r</tt> is not a <tt>forward_range</tt>. 
<p/>
Although we can still use <tt>ranges::empty</tt> to determine whether <tt>r</tt> is empty, this 
inconsistency of the validity of <tt>!r</tt> and <tt>r.empty()</tt> is quite unsatisfactory.
</p>
<p>
I see no reason to prevent <tt>view_interface::empty</tt> when <tt>D</tt> is <tt>sized_range</tt>, 
since checking whether <tt>ranges::size(r) == 0</tt> is an intuitive way to check for empty, as 
<tt>ranges::empty</tt> does.
</p>

<p><i>[2022-06-21; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 26.5.3.1 <a href="https://wg21.link/view.interface.general">[view.interface.general]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;class D&gt;
    requires is_class_v&lt;D&gt; &amp;&amp; same_as&lt;D, remove_cv_t&lt;D&gt;&gt;
  class view_interface {
  private:
    constexpr D&amp; <i>derived</i>() noexcept {                  <i>// exposition only</i>
      return static_cast&lt;D&amp;&gt;(*this);
    }
    constexpr const D&amp; <i>derived</i>() const noexcept {      <i>// exposition only</i>
      return static_cast&lt;const D&amp;&gt;(*this);
    }

  public:
    constexpr bool empty() requires <ins>sized_range&lt;D&gt; ||</ins> forward_range&lt;D&gt; {
      <ins>if constexpr (sized_range&lt;D&gt;)
        return ranges::size(<i>derived</i>()) == 0;
      else</ins>
        return ranges::begin(<i>derived</i>()) == ranges::end(<i>derived</i>());
    }
    constexpr bool empty() const requires <ins>sized_range&lt;const D&gt; ||</ins> forward_range&lt;const D&gt; {
      <ins>if constexpr (sized_range&lt;const D&gt;)
        return ranges::size(<i>derived</i>()) == 0;
      else</ins>
        return ranges::begin(<i>derived</i>()) == ranges::end(<i>derived</i>());
    }
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3719" href="https://cplusplus.github.io/LWG/lwg-active.html#3719">3719</a>. Directory iterators should be usable with default sentinel</h3>
<p><b>Section:</b> 31.12.11.1 <a href="https://wg21.link/fs.class.directory.iterator.general">[fs.class.directory.iterator.general]</a>, 31.12.12.1 <a href="https://wg21.link/fs.class.rec.dir.itr.general">[fs.class.rec.dir.itr.general]</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> 2022-06-17 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
We added comparisons with <tt>default_sentinel_t</tt> to the stream and streambuf iterators, because their
past-the-end iterator is just a default-constructed iterator. We didn't do the same for filesystem directory
iterators, but they also use a default-constructed value as the sentinel.
<p/>
The proposed resolution addresses this oversight.
</p>

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

<ol>
<li><p>Modify 31.12.11.1 <a href="https://wg21.link/fs.class.directory.iterator.general">[fs.class.directory.iterator.general]</a>, class <tt>directory_iterator</tt> synopsis,
as indicated:</p>

<blockquote>
<pre>
namespace std::filesystem {
  class directory_iterator {
    [&hellip;]

    const directory_entry&amp; operator*() const;
    const directory_entry* operator-&gt;() const;
    directory_iterator&amp; operator++();
    directory_iterator&amp; increment(error_code&amp; ec);

    <ins>friend bool operator==(const directory_iterator&amp; lhs, default_sentinel_t) noexcept
    { return lhs == end(lhs); }</ins>

    <i>// other members as required by 25.3.5.3 <a href="https://wg21.link/input.iterators">[input.iterators]</a>, input iterators</i>
  };
}
</pre>
</blockquote>
</li>

<li><p>Modify 31.12.12.1 <a href="https://wg21.link/fs.class.rec.dir.itr.general">[fs.class.rec.dir.itr.general]</a>, class <tt>recursive_directory_iterator</tt> synopsis,
as indicated:</p>

<blockquote>
<pre>
namespace std::filesystem {
  class recursive_directory_iterator {
    [&hellip;]

    void pop();
    void pop(error_code&amp; ec);
    void disable_recursion_pending();

    <ins>friend bool operator==(const recursive_directory_iterator&amp; lhs, default_sentinel_t) noexcept
    { return lhs == end(lhs); }</ins>

    <i>// other members as required by 25.3.5.3 <a href="https://wg21.link/input.iterators">[input.iterators]</a>, input iterators</i>
  };
}
</pre>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2022-07-06; Jonathan Wakely revises proposed resolution and adds
regex iterators as suggested on the reflector.]</i></p>



<p><i>[2022-07-11; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 31.12.11.1 <a href="https://wg21.link/fs.class.directory.iterator.general">[fs.class.directory.iterator.general]</a>, class <tt>directory_iterator</tt> synopsis,
as indicated:</p>

<blockquote>
<pre>
namespace std::filesystem {
  class directory_iterator {
    [&hellip;]

    const directory_entry&amp; operator*() const;
    const directory_entry* operator-&gt;() const;
    directory_iterator&amp; operator++();
    directory_iterator&amp; increment(error_code&amp; ec);

    <ins>bool operator==(default_sentinel_t) const noexcept</ins>
    <ins>{ return *this == directory_iterator(); }</ins>

    <i>// other members as required by 25.3.5.3 <a href="https://wg21.link/input.iterators">[input.iterators]</a>, input iterators</i>
  };
}
</pre>
</blockquote>
</li>

<li><p>Modify 31.12.12.1 <a href="https://wg21.link/fs.class.rec.dir.itr.general">[fs.class.rec.dir.itr.general]</a>, class <tt>recursive_directory_iterator</tt> synopsis,
as indicated:</p>

<blockquote>
<pre>
namespace std::filesystem {
  class recursive_directory_iterator {
    [&hellip;]

    void pop();
    void pop(error_code&amp; ec);
    void disable_recursion_pending();

    <ins>bool operator==(default_sentinel_t) const noexcept</ins>
    <ins>{ return *this == recursive_directory_iterator(); }</ins>

    <i>// other members as required by 25.3.5.3 <a href="https://wg21.link/input.iterators">[input.iterators]</a>, input iterators</i>
  };
}
</pre>
</blockquote>
</li>

<li><p>Modify 32.11.1.1 <a href="https://wg21.link/re.regiter.general">[re.regiter.general]</a>, <tt>regex_iterator</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class BidirectionalIterator,
            class charT = typename iterator_traits&lt;BidirectionalIterator&gt;::value_type,
            class traits = regex_traits&lt;charT&gt;&gt;
    class regex_iterator {
      [&hellip;]
      regex_iterator&amp; operator=(const regex_iterator&);
      bool operator==(const regex_iterator&amp;) const;
      <ins>bool operator==(default_sentinel_t) const { return *this == regex_iterator(); }</ins>
      const value_type&amp; operator*() const;
      const value_type* operator-&gt;() const;
</pre>
</blockquote>
</li>

<li><p>Modify 32.11.2.1 <a href="https://wg21.link/re.tokiter.general">[re.tokiter.general]</a>, <tt>regex_token_iterator</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class BidirectionalIterator,
            class charT = typename iterator_traits&lt;BidirectionalIterator&gt;::value_type,
            class traits = regex_traits&lt;charT&gt;&gt;
    class regex_token_iterator {
      [&hellip;]
      regex_iterator&amp; operator=(const regex_token_iterator&);
      bool operator==(const regex_token_iterator&amp;) const;
      <ins>bool operator==(default_sentinel_t) const { return *this == regex_token_iterator(); }</ins>
      const value_type&amp; operator*() const;
      const value_type* operator-&gt;() const;
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3721" href="https://cplusplus.github.io/LWG/lwg-active.html#3721">3721</a>. Allow an <i>arg-id</i> with a value of zero for <i>width</i> in <i>std-format-spec</i></h3>
<p><b>Section:</b> 22.14.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Mark de Wever <b>Opened:</b> 2022-06-19 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#format.string.std">active issues</a> in [format.string.std].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#format.string.std">issues</a> in [format.string.std].</p>
<p><b>Discussion:</b></p>
<p>
Per 22.14.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a>/7
</p>
<blockquote><p>
If <tt>{ <i>arg-id<sub>opt</sub></i> }</tt> is used in a <i>width</i> or <i>precision</i>, 
the value of the corresponding formatting argument is used in its place. If the
corresponding formatting argument is not of integral type, or its value is negative for 
<i>precision</i> or non-positive for <i>width</i>, an exception of type <tt>format_error</tt> 
is thrown.
</p></blockquote>
<p>
During a libc++ code review Victor mentioned it would be nice to allow zero as a valid value 
for the <i>arg-id</i> when used for the <i>width</i>. This would simplify the code by having 
the same requirements for the <i>arg-id</i> for the <i>width</i> and <i>precision</i> fields. 
A <i>width</i> of zero has no effect on the output.
<p/>
In the <i>std-format-spec</i> the <i>width</i> is restricted to a positive-integer to
avoid parsing ambiguity with the zero-padding option. This ambiguity doesn't happen using an 
<i>arg-id</i> with the value zero. Therefore I only propose to change the <i>arg-id</i>'s requirement.
<p/>
Note the Standard doesn't specify the <i>width</i> field's effect on the
output. Specifically  [tab:format.align] doesn't refer to the <i>width</i>
field. This is one of the items addressed by <a href="https://wg21.link/P2572">P2572</a>. The proposed resolution
works in combination with the wording of that paper.
</p>

<p><i>[2022-07-08; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll.
</p>


<p><i>[2022-07-11; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

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

<blockquote>
<p>
-7- If <tt>{ <i>arg-id<sub>opt</sub></i> }</tt> is used in a <i>width</i> or <i>precision</i>, 
the value of the corresponding formatting argument is used in its place. If the corresponding 
formatting argument is not of integral type, or its value is negative <del>for <i>precision</i> 
or non-positive for <i>width</i></del>, an exception of type <tt>format_error</tt> is thrown.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3724" href="https://cplusplus.github.io/LWG/lwg-active.html#3724">3724</a>. <tt><i>decay-copy</i></tt> should be constrained</h3>
<p><b>Section:</b> 16.3.3.2 <a href="https://wg21.link/expos.only.func">[expos.only.func]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hui Xie <b>Opened:</b> 2022-06-23 <b>Last modified:</b> 2022-07-15</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#expos.only.func">issues</a> in [expos.only.func].</p>
<p><b>Discussion:</b></p>
<p>
The spec of <tt>views::all</tt> 26.7.5.1 <a href="https://wg21.link/range.all.general">[range.all.general]</a> p2 says:
</p>
<blockquote><p>
Given a subexpression <tt>E</tt>, the expression <tt>views::all(E)</tt> is expression-equivalent to:
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; <tt><i>decay-copy</i>(E)</tt> if the decayed type of E models <tt>view</tt>.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
<p>
If <tt>E</tt> is an lvalue move-only <tt>view</tt>, according to the spec, <tt>views::all(E)</tt> 
would be expression-equivalent to <tt><i>decay-copy</i>(E)</tt>.
<p/>
However, 16.3.3.2 <a href="https://wg21.link/expos.only.func">[expos.only.func]</a> p2 defines <tt><i>decay-copy</i></tt> as follows
</p>
<blockquote><pre>
template&lt;class T&gt; constexpr decay_t&lt;T&gt; <i>decay-copy</i>(T&amp;&amp; v)
    noexcept(is_nothrow_convertible_v&lt;T, decay_t&lt;T&gt;&gt;)         <i>// exposition only</i>
  { return std::forward&lt;T&gt;(v); }
</pre></blockquote>
<p>
It is unconstrained.  As a result, for the above example, <tt>views::all(E)</tt> is a well-formed 
expression and it would only error on the template instantiation of the function body of 
<tt><i>decay-copy</i></tt>, because <tt>E</tt> is an lvalue of move-only type and not copyable.
<p/>
I think this behaviour is wrong, instead, we should make <tt><i>decay-copy(E)</i></tt> ill-formed 
if it is not copyable, so that <tt>views::all(E)</tt> can be SFINAE friendly.
</p>

<p><i>[2022-07-08; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll.
</p>


<p><i>[2022-07-11; Reflector poll]</i></p>

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

<p><i>[2022-07-15; LWG telecon: move to Ready]</i></p>




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

<ol>
<li><p>Modify 16.3.3.2 <a href="https://wg21.link/expos.only.func">[expos.only.func]</a> as indicated:</p>

<blockquote>
<p>
-2- The following are defined for exposition only to aid in the specification of the library:
</p>
<blockquote>
<pre>
namespace std {
  template&lt;class T&gt; 
    <ins>requires convertible_to&lt;T, decay_t&lt;T&gt;&gt;</ins>
      constexpr decay_t&lt;T&gt; decay-copy(T&amp;&amp; v)
        noexcept(is_nothrow_convertible_v&lt;T, decay_t&lt;T&gt;&gt;) <i>// exposition only</i>
      { return std::forward&lt;T&gt;(v); }
  [&hellip;]
}
</pre>
</blockquote>
</blockquote>
</li>

</ol>





</body>
</html>
