<!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 Issaquah, Feb. 2023</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 Issaquah, Feb. 2023</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P2789R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>2023-02-06</p>
</td>
</tr>
<tr>
<td align="left">Audience:</td>
<td align="left">WG21</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Jonathan Wakely &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<ul>
<li><a href="#ready">Ready Issues</a></li>
<li><a href="#tentatively_ready">Tentatively Ready Issues</a></li>
</ul>
<h2 id="ready">Ready Issues</h2>
<hr>
<h3><a name="2195" href="https://cplusplus.github.io/LWG/lwg-active.html#2195">2195</a>. Missing constructors for <tt>match_results</tt></h3>
<p><b>Section:</b> 32.9 <a href="https://wg21.link/re.results">[re.results]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-10-06 <b>Last modified:</b> 2022-11-10</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#re.results">issues</a> in [re.results].</p>
<p><b>Discussion:</b></p>

<p>
The requirement expressed in 32.9 <a href="https://wg21.link/re.results">[re.results]</a> p2
</p>
<blockquote><p>
The class template <tt>match_results</tt> shall satisfy the requirements of an allocator-aware container and of a
sequence container, as specified in 24.2.4 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a>, except that only operations defined for 
const-qualified sequence containers are supported.
</p></blockquote>
<p>
can be read to require the existence of the described constructors from as well, but they do not exist in the
synopsis. 
<p/>
The missing sequence constructors are: 
</p>
<blockquote><pre>
match_results(initializer_list&lt;value_type&gt;);
match_results(size_type, const value_type&amp;);
template&lt;class InputIterator&gt; match_results(InputIterator, InputIterator);
</pre></blockquote>
<p>
The missing allocator-aware container constructors are:
</p>
<blockquote><pre>
match_results(const match_results&amp;, const Allocator&amp;);
match_results(match_results&amp;&amp;, const Allocator&amp;);
</pre></blockquote>
<p>
It should be clarified, whether (a) constructors are an exception of above mentioned operations or (b) whether
at least some of them (like those accepting a <tt>match_results</tt> value and an allocator) should be added.
<p/>
As visible in several places of the standard (including the core language), constructors seem usually to be considered 
as "operations" and they certainly can be invoked for const-qualified objects.
<p/>
The below given proposed resolution applies only the minimum necessary fix, i.e. it excludes constructors from
above requirement. 
</p>

<p><i>[2013-04-20, Bristol]</i></p>

<p>Check current implementations to see what they do and, possibly, write a paper.</p>

<p><i>[2013-09 Chicago]</i></p>

<p>Ask Daniel to update the proposed wording to include the allocator copy and move constructors.</p>

<p><i>[2014-01-18 Daniel changes proposed resolution]</i></p>

<p><strong>Previous resolution from Daniel [SUPERSEDED]:</strong></p>

<blockquote class="note">
<ol>
<li><p>Change 32.9 <a href="https://wg21.link/re.results">[re.results]</a> p2 as indicated:</p>
<blockquote><p>
The class template <tt>match_results</tt> shall satisfy the requirements of an allocator-aware container and of a
sequence container, as specified in 24.2.4 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a>, except that only operations defined for 
const-qualified sequence containers <ins>that are not constructors</ins> are supported.
</p></blockquote>
</li>
</ol>
</blockquote>

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

<p>MC passes important knowledge to EF.</p>
<p>VV, RP: Looks good.</p>
<p>TK: Second form should be conditionally noexcept</p>
<p>JY: Sequence constructors are not here, but mentioned in the issue writeup. Why?</p>
<p>TK: That would have been fixed by the superseded wording.</p>
<p>JW: How does this interact with Mike Spertus' allocator-aware regexes? [...] Perhaps it doesn't.</p>
<p>JW: Can't create match_results, want both old and new resolution.</p>
<p>JY: It's problematic that users can't create these, but not this issue.</p>
<p>VV: Why conditional noexcept?</p>
<p>MC: Allocator move might throw.</p>
<p>JW: Update superseded wording to "only non-constructor operations that are"?</p>
<p>MC: Only keep superseded, but append "and the means of constructing match_results are limited to [...]"?</p>
<p>JY: Bullet 4 paragraph 2 needs to address the allocator constructor.</p>
<p>Assigned to JW for drafting.</p>

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

<p>STL: I want Mike Spertus to be aware of this issue.</p>

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

<ol>
<li><p>Change 32.9 <a href="https://wg21.link/re.results">[re.results]</a> p4, class template <tt>match_results</tt> synopsis, as indicated:</p>
<blockquote><pre>
[&hellip;]
// 28.10.1, construct/copy/destroy:
explicit match_results(const Allocator&amp; a = Allocator());
match_results(const match_results&amp; m);
<ins>match_results(const match_results&amp; m, const Allocator&amp; a);</ins>
match_results(match_results&amp;&amp; m) noexcept;
<ins>match_results(match_results&amp;&amp; m, const Allocator&amp; a) noexcept;</ins>
[&hellip;]
</pre></blockquote>
</li>

<li><p>Change 32.9.2 <a href="https://wg21.link/re.results.const">[re.results.const]</a>  as indicated: [<i>Drafting note:</i> Paragraph 6 as currently written,
makes not much sense, because the <tt>noexcept</tt> does not allow any exception to propagate. Further-on, the allocator requirements
do not allow for throwing move constructors. Deleting it seems to be near to editorial &mdash; <i>end drafting note</i>]</p>
<blockquote>

<pre>
match_results(const match_results&amp; m);
<ins>match_results(const match_results&amp; m, const Allocator&amp; a);</ins>
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Constructs an object of class <tt>match_results</tt>, as a copy of <tt>m</tt>.
</p>
</blockquote>

<pre>
match_results(match_results&amp;&amp; m) noexcept;
<ins>match_results(match_results&amp;&amp; m, const Allocator&amp; a) noexcept;</ins>
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Move-constructs an object of class <tt>match_results</tt> from <tt>m</tt> satisfying the same postconditions
as Table 142. <del>Additionally</del><ins>For the first form</ins>, the stored <tt>Allocator</tt> value is move constructed 
from <tt>m.get_allocator()</tt>.
<p/>
<del>-6- <i>Throws:</i> Nothing if the allocator's move constructor throws nothing.</del>
</p>
</blockquote>

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

<p><i>[2019-03-27 Jonathan updates proposed resolution]</i></p>


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

<p>
These edits overlap with the proposed resolution of <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2191">2191</a>
but it should be obvious how to resolve the conflicts.
Both resolutions remove the word "Additionally" from p4.
Issue 2191 removes the entire <i>Throws:</i> element in p5 but this issue
replaces it with different text that applies to the new constructor only.
</p>

<ol>
<li><p>Change 32.9 <a href="https://wg21.link/re.results">[re.results]</a> p4, class template <tt>match_results</tt> synopsis, as indicated:</p>
<blockquote><pre>
[&hellip;]
// 30.10.1, construct/copy/destroy:
explicit match_results(const Allocator&amp; a = Allocator());
match_results(const match_results&amp; m);
<ins>match_results(const match_results&amp; m, const Allocator&amp; a);</ins>
match_results(match_results&amp;&amp; m) noexcept;
<ins>match_results(match_results&amp;&amp; m, const Allocator&amp; a);</ins>
[&hellip;]
</pre></blockquote>
</li>

<li><p>Change 32.9.2 <a href="https://wg21.link/re.results.const">[re.results.const]</a>  as indicated:</p>
<blockquote>

<pre>
match_results(const match_results&amp; m);
<ins>match_results(const match_results&amp; m, const Allocator&amp; a);</ins>
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Constructs an object of class <tt>match_results</tt>, as a copy of <tt>m</tt>.
<ins>For the second form, the stored <tt>Allocator</tt> value is constructed from <tt>a</tt>.</ins>
</p>
</blockquote>

<pre>
match_results(match_results&amp;&amp; m) noexcept;
<ins>match_results(match_results&amp;&amp; m, const Allocator&amp; a);</ins>
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Move-constructs an object of class <tt>match_results</tt> from <tt>m</tt> satisfying the same postconditions
as Table 128. <del>Additionally</del><ins>For the first form</ins>, the stored <tt>Allocator</tt> value is move constructed
from <tt>m.get_allocator()</tt>.
<ins>For the second form, the stored <tt>Allocator</tt> value is constructed from <tt>a</tt>.</ins>
</p>
<p>
-6- <i>Throws:</i> <del>Nothing.</del>
<ins>The second form throws nothing if <tt>a == m.get_allocator()</tt>.</ins>
</p>
</blockquote>

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

<p><i>[2022-11-06; Daniel syncs wording with recent working draft]</i></p>

<p>
To ensure that all constructors are consistent in regard to the information about how the stored
allocator is constructed, more wording is added. This harmonizes with the way how we specify the
individual container constructors (Such as <tt>vector</tt>) even though 24.2.2.5 <a href="https://wg21.link/container.alloc.reqmts">[container.alloc.reqmts]</a>
already provides some guarantees. For the copy-constructor we intentionally refer to
24.2.2.2 <a href="https://wg21.link/container.reqmts">[container.reqmts]</a> so that we don't need to repeat what is said there.
</p>

<p><i>[Kona 2022-11-08; Move to Ready]</i></p>




<p id="res-2195"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>
<li><p>Change 32.9 <a href="https://wg21.link/re.results">[re.results]</a>, class template <tt>match_results</tt> synopsis, as indicated:</p>
<blockquote><pre>
[&hellip;]
<i>// 32.9.2 <a href="https://wg21.link/re.results.const">[re.results.const]</a>, construct/copy/destroy:</i>
match_results() : match_results(Allocator()) {}
explicit match_results(const Allocator&amp; <ins>a</ins>);
match_results(const match_results&amp; m);
<ins>match_results(const match_results&amp; m, const Allocator&amp; a);</ins>
match_results(match_results&amp;&amp; m) noexcept;
<ins>match_results(match_results&amp;&amp; m, const Allocator&amp; a);</ins>
[&hellip;]
</pre></blockquote>
</li>

<li><p>Change 32.9.2 <a href="https://wg21.link/re.results.const">[re.results.const]</a> as indicated:</p>

<blockquote>
<pre>
explicit match_results(const Allocator&amp; a);
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> The stored <tt>Allocator</tt> value is constructed from <tt>a</tt>.</ins>
<p/>
-2- <i>Postconditions</i>: <tt>ready()</tt> returns <tt>false</tt>. <tt>size()</tt> returns <tt>0</tt>.
</p>
</blockquote>
<pre>
match_results(const match_results&amp; m);
<ins>match_results(const match_results&amp; m, const Allocator&amp; a);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> For the first form, the stored <tt>Allocator</tt> value 
is obtained as specified in 24.2.2.2 <a href="https://wg21.link/container.reqmts">[container.reqmts]</a>. For the second form, the stored 
<tt>Allocator</tt> value is constructed from <tt>a</tt>.</ins>
<p/>
-3- <i>Postconditions</i>: As specified in Table 142 [tab:re.results.const].
</p>
</blockquote>
<pre>
match_results(match_results&amp;&amp; m) noexcept;
<ins>match_results(match_results&amp;&amp; m, const Allocator&amp; a);</ins>
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> <ins>For the first form, t</ins><del>T</del>he stored <tt>Allocator</tt> value 
is move constructed from <tt>m.get_allocator()</tt>. <ins>For the second form, the stored <tt>Allocator</tt> 
value is constructed from <tt>a</tt>.</ins>
<p/>
-5- <i>Postconditions</i>: As specified in Table 142 [tab:re.results.const].
<p/>
<ins>-?- <i>Throws:</i> The second form throws nothing if <tt>a == m.get_allocator()</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>

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






<hr>
<h3><a name="2295" href="https://cplusplus.github.io/LWG/lwg-active.html#2295">2295</a>. Locale name when the provided <tt>Facet</tt> is a <tt>nullptr</tt></h3>
<p><b>Section:</b> 30.3.1.3 <a href="https://wg21.link/locale.cons">[locale.cons]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2013-09-04 <b>Last modified:</b> 2022-11-09</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#locale.cons">active issues</a> in [locale.cons].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#locale.cons">issues</a> in [locale.cons].</p>
<p><b>Discussion:</b></p>
<p>
30.3.1.3 <a href="https://wg21.link/locale.cons">[locale.cons]</a> p14 ends with:
</p>
<blockquote><p>
"[&hellip;] If <tt>f</tt> is null, the resulting object is a copy of <tt>other</tt>."
</p></blockquote>
<p>
but the next line p15 says: 
</p>
<blockquote><p>
"<i>Remarks:</i> The resulting locale has no name."
</p></blockquote>
<p>
But both can't be true when <tt>other</tt> has a name and <tt>f</tt> is null.
<p/>
I've tried it on two implementations (MSVC,GCC) and they are inconsistent with each other on this.
</p>
<p>
Daniel Kr&uuml;gler:
<p/>
As currently written, the <i>Remarks</i> element applies unconditionally for all cases and thus should
"win". The question arises whether the introduction of this element by LWG <a href="https://cplusplus.github.io/LWG/lwg-closed.html#424">424</a> had actually intended
to change the previous <i>Note</i> to a <i>Remarks</i> element. In either case the wording should be improved
to clarify this special case.
</p>

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

<p>
This issue seems to have some overlap with LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3676">3676</a> so both should presumably be resolved
in a harmonized way.
</p>

<p><i>[2022-11-01; Jonathan provides wording]</i></p>

<p>
This also resolves <a href="https://cplusplus.github.io/LWG/lwg-active.html#3673">3673</a> and <a href="https://cplusplus.github.io/LWG/lwg-active.html#3676">3676</a>.
</p>

<p><i>[2022-11-04; Jonathan revises wording after feedback]</i></p>

<p>Revert an incorrect edit to p8, which was incorrectly changed to:</p>
<p>
"If <tt>cats</tt> is equal to <tt>locale::none</tt>, the resulting locale
has the same name as <tt>locale(std_name)</tt>. Otherwise, the locale
has a name if and only if <tt>other</tt> has a name."
</p>

<p><i>[Kona 2022-11-08; Move to Ready status]</i></p>




<p id="res-2295"><b>Proposed resolution:</b></p>

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

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

<blockquote>
<blockquote><pre>
explicit locale(const char* std_name);
</pre></blockquote>
<blockquote>
<p>-2- <i>Effects</i>:
Constructs a locale using standard C locale names, e.g., <tt>"POSIX"</tt>.
The resulting locale implements semantics defined to be associated with that name.
</p>
<p>-3- <i>Throws</i>:
<tt>runtime_error</tt> if the argument is not valid, or is null.
</p>
<p>-4- <i>Remarks</i>:
The set of valid string argument values is <tt>"C"</tt>, <tt>""</tt>,
and any implementation-defined values.
</p>
</blockquote>

<blockquote><pre>
explicit locale(const string&amp; std_name);
</pre></blockquote>
<blockquote>
<p>-5- <i>Effects</i>:
<del>The same as</del><ins>Equivalent to</ins>
<tt>locale(std_name.c_str())</tt>.
</p>
</blockquote>

<blockquote><pre>
locale(const locale&amp; other, const char* std_name, category <ins>cats</ins>);
</pre></blockquote>
<blockquote>
<p><ins>-?- <i>Preconditions</i>:
<tt>cats</tt> is a valid <tt>category</tt> value
(30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a>).
</ins></p>
<p>-6- <i>Effects</i>:
Constructs a locale as a copy of <tt>other</tt> except for the facets
identified by the <tt>category</tt> argument, which instead implement
the same semantics as <tt>locale(std_name)</tt>.
</p>
<p>-7- <i>Throws</i>:
<tt>runtime_error</tt> if the <ins>second</ins> argument is not valid,
or is null.
</p>
<p>-8- <i>Remarks</i>:
The locale has a name if and only if <tt>other</tt> has a name.
</p>
</blockquote>

<blockquote><pre>
locale(const locale&amp; other, const string&amp; std_name, category cat<ins>s</ins>);
</pre></blockquote>
<blockquote>
<p>-9- <i>Effects</i>:
<del>The same as</del><ins>Equivalent to</ins>
<tt>locale(other, std_name.c_str(), cat<ins>s</ins>)</tt>.
</p>
</blockquote>

<blockquote><pre>
template&lt;class Facet&gt; locale(const locale&amp; other, Facet* f);
</pre></blockquote>
<blockquote>
<p>-10- <i>Effects</i>: Constructs a locale incorporating all facets from the
first argument except that of type <tt>Facet</tt>,
and installs the second argument as the remaining facet.
If <tt>f</tt> is null, the resulting object is a copy of <tt>other</tt>.
</p>
<p>-11- <em>Remarks</em>:
<ins>If <tt>f</tt> is null,
the resulting locale has the same name as <tt>other</tt>.
Otherwise, the</ins>
<del>The</del>
resulting locale has no name.
</p>
</blockquote>

<blockquote><pre>
locale(const locale&amp; other, const locale&amp; one, category cats);
</pre></blockquote>
<blockquote>
<p><ins>-?- <i>Preconditions</i>:
<tt>cats</tt> is a valid <tt>category</tt> value.
</ins></p>
<p>-12- <i>Effects</i>:
Constructs a locale incorporating all facets from the first argument
except for those that implement <tt>cats</tt>, which are instead
incorporated from the second argument.
</p>
<p>-13- <i>Remarks</i>:
<ins>If <tt>cats</tt> is equal to <tt>locale::none</tt>,
the resulting locale has a name if and only if the first argument has a name.
Otherwise, the</ins>
<del>The</del>
locale has a name if and only if the first two arguments
<ins>both</ins>
have names.
</p>
</blockquote>

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






<hr>
<h3><a name="3032" href="https://cplusplus.github.io/LWG/lwg-active.html#3032">3032</a>. <tt>ValueSwappable</tt> requirement missing for <tt>push_heap</tt> and <tt>make_heap</tt></h3>
<p><b>Section:</b> 27.8.8 <a href="https://wg21.link/alg.heap.operations">[alg.heap.operations]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Robert Douglas <b>Opened:</b> 2017-11-08 <b>Last modified:</b> 2022-11-10</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#alg.heap.operations">issues</a> in [alg.heap.operations].</p>
<p><b>Discussion:</b></p>
<p>
In discussion of D0202R3 in Albuquerque, it was observed that <tt>pop_heap</tt> and <tt>sort_heap</tt> had 
<tt>constexpr</tt> removed for their requirement of <tt>ValueSwappable</tt>. It was then observed that 
<tt>push_heap</tt> and <tt>make_heap</tt> were not similarly marked as having the <tt>ValueSwappable</tt> requirement. 
The room believed this was likely a specification error, and asked to open an issue to track it.
</p>

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

<p>Priority set to 3; Marshall to investigate</p>

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

<ol>
<li><p>Change 27.8.8.2 <a href="https://wg21.link/push.heap">[push.heap]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RandomAccessIterator&gt;
  void push_heap(RandomAccessIterator first, RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void push_heap(RandomAccessIterator first, RandomAccessIterator last,
                 Compare comp);
</pre>
<blockquote>
<p>
-1- <i>Requires:</i> The range <tt>[first, last - 1)</tt> shall be a valid heap. <ins><tt>RandomAccessIterator</tt> shall satisfy 
the requirements of <tt>ValueSwappable</tt> (16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>).</ins> The type of <tt>*first</tt> 
shall satisfy the <tt>MoveConstructible</tt> requirements (Table 23) and the <tt>MoveAssignable</tt> requirements (Table 25).
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 27.8.8.4 <a href="https://wg21.link/make.heap">[make.heap]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RandomAccessIterator&gt;
  void make_heap(RandomAccessIterator first, RandomAccessIterator last);
template&lt;class RandomAccessIterator, class Compare&gt;
  void make_heap(RandomAccessIterator first, RandomAccessIterator last,
                 Compare comp);
</pre>
<blockquote>
<p>
-1- <i>Requires:</i> <ins><tt>RandomAccessIterator</tt> shall satisfy the requirements of <tt>ValueSwappable</tt> 
(16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>).</ins> The type of <tt>*first</tt> shall satisfy the <tt>MoveConstructible</tt> 
requirements (Table 23) and the <tt>MoveAssignable</tt> requirements (Table 25).
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2022-11-06; Daniel comments and syncs wording with recent working draft]</i></p>

<p>
For reference, the finally accepted paper was <a href="https://wg21.link/P0202R3">P0202R3</a> and the constexpr-ification of
swap-related algorithms had been realized later by <a href="https://wg21.link/P0879R0">P0879R0</a> after resolution of
<a href="https://wg21.link/cwg1581">CWG 1581</a> and more importantly <a href="https://wg21.link/cwg1330">CWG 1330</a>.
</p>

<p><i>[Kona 2022-11-09; Move to Ready]</i></p>



<p id="res-3032"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>
<li><p>Change 27.8.8.2 <a href="https://wg21.link/push.heap">[push.heap]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RandomAccessIterator&gt;
  constexpr void push_heap(RandomAccessIterator first, RandomAccessIterator last);

template&lt;class RandomAccessIterator, class Compare&gt;
  constexpr void push_heap(RandomAccessIterator first, RandomAccessIterator last,
                           Compare comp);
                 
template&lt;random_access_iterator I, sentinel_for&lt;I&gt; S, class Comp = ranges::less,
         class Proj = identity&gt;
  requires sortable&lt;I, Comp, Proj&gt;
  constexpr I
    ranges::push_heap(I first, S last, Comp comp = {}, Proj proj = {});
template&lt;random_access_range R, class Comp = ranges::less, class Proj = identity&gt;
  requires sortable&lt;iterator_t&lt;R&gt;, Comp, Proj&gt;
  constexpr borrowed_iterator_t&lt;R&gt;
    ranges::push_heap(R&amp;&amp; r, Comp comp = {}, Proj proj = {});
</pre>
<blockquote>
<p>
-1- Let <tt>comp</tt> be <tt>less{}</tt> and <tt>proj</tt> be <tt>identity{}</tt> for the overloads with no parameters by those names.
<p/>
-2- <i>Preconditions</i>: The range <tt>[first, last - 1)</tt> is a valid heap with respect to 
<tt>comp</tt> and <tt>proj</tt>. For the overloads in namespace <tt>std</tt>, 
<ins><tt>RandomAccessIterator</tt> meets the <i>Cpp17ValueSwappable</i> requirements 
(16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>) and</ins> the type of <tt>*first</tt> meets the 
<i>Cpp17MoveConstructible</i> requirements (Table 32) and the <i>Cpp17MoveAssignable</i> 
requirements (Table 34).
<p/>
-3- <i>Effects</i>: Places the value in the location <tt>last - 1</tt> into the resulting heap <tt>[first, last)</tt>.
<p/>
-4- <i>Returns</i>: <tt>last</tt> for the overloads in namespace <tt>ranges</tt>.
<p/>
-5- <i>Complexity</i>: At most log(<tt>last - first</tt>) comparisons and twice as many projections.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 27.8.8.4 <a href="https://wg21.link/make.heap">[make.heap]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RandomAccessIterator&gt;
  constexpr void make_heap(RandomAccessIterator first, RandomAccessIterator last);

template&lt;class RandomAccessIterator, class Compare&gt;
  constexpr void make_heap(RandomAccessIterator first, RandomAccessIterator last,
                           Compare comp);
                           
template&lt;random_access_iterator I, sentinel_for&lt;I&gt; S, class Comp = ranges::less,
         class Proj = identity&gt;
  requires sortable&lt;I, Comp, Proj&gt;
  constexpr I
    ranges::make_heap(I first, S last, Comp comp = {}, Proj proj = {});
template&lt;random_access_range R, class Comp = ranges::less, class Proj = identity&gt;
  requires sortable&lt;iterator_t&lt;R&gt;, Comp, Proj&gt;
  constexpr borrowed_iterator_t&lt;R&gt;
    ranges::make_heap(R&amp;&amp; r, Comp comp = {}, Proj proj = {});
</pre>
<blockquote>
<p>
-1- Let <tt>comp</tt> be <tt>less{}</tt> and <tt>proj</tt> be <tt>identity{}</tt> for the overloads with no parameters by those names.
<p/>
-2- <i>Preconditions</i>: For the overloads in namespace <tt>std</tt>, <ins><tt>RandomAccessIterator</tt> 
meets the <i>Cpp17ValueSwappable</i> requirements (16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>) and</ins> the type 
of <tt>*first</tt> meets the <i>Cpp17MoveConstructible</i> (Table 32) and <i>Cpp17MoveAssignable</i> (Table 34) requirements.
<p/>
-3- <i>Effects</i>: Constructs a heap with respect to <tt>comp</tt> and <tt>proj</tt> out of the range <tt>[first, last)</tt>.
<p/>
-4- <i>Returns</i>: <tt>last</tt> for the overloads in namespace <tt>ranges</tt>.
<p/>
-5- <i>Complexity</i>: At most 3(<tt>last - first</tt>) comparisons and twice as many projections.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3085" href="https://cplusplus.github.io/LWG/lwg-active.html#3085">3085</a>. <tt>char_traits::copy</tt> precondition too weak</h3>
<p><b>Section:</b> 23.2.2 <a href="https://wg21.link/char.traits.require">[char.traits.require]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2018-03-16 <b>Last modified:</b> 2022-11-11</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#char.traits.require">active issues</a> in [char.traits.require].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#char.traits.require">issues</a> in [char.traits.require].</p>
<p><b>Discussion:</b></p>
<p>
Table 54, Character traits requirements, says that <tt>char_traits::move</tt> allows the ranges to overlap, 
but <tt>char_traits::copy</tt> requires that <tt>p</tt> is not in the range <tt>[s, s + n)</tt>. This 
appears to be an attempt to map to the requirements of <tt>memmove</tt> and <tt>memcpy</tt> respectively,
allowing those to be used to implement the functions, however the requirements for <tt>copy</tt> are 
weaker than those for <tt>memcpy</tt>. The C standard says for <tt>memcpy</tt> "If copying takes place 
between objects that overlap, the behavior is undefined" which is a stronger requirement than the start 
of the source range not being in the destination range.
<p/>
All of libstdc++, libc++ and VC++ simply use <tt>memcpy</tt> for <tt>char_traits&lt;char&gt;::copy</tt>, 
resulting in undefined behaviour in this example:
</p>
<blockquote><pre>
char p[] = "abc";
char* s = p + 1;
std::char_traits&lt;char&gt;::copy(s, p, 2);
assert(std::char_traits&lt;char&gt;::compare(p, "aab", 3) == 0);
</pre></blockquote>
<p>
If the intention is to allow <tt>memcpy</tt> as a valid implementation then the precondition is 
wrong (unfortunately nobody realized this when fixing <tt>char_traits::move</tt> in LWG DR <a href="https://cplusplus.github.io/LWG/lwg-defects.html#7">7</a>). 
If the intention is to require <tt>memmove</tt> then it is strange to have separate <tt>copy</tt> and 
<tt>move</tt> functions that both use <tt>memmove</tt>.
<p/>
N.B. <tt>std::copy</tt> and <tt>std::copy_backward</tt> are not valid implementations of 
<tt>char_traits::copy</tt> either, due to different preconditions.
<p/>
Changing the precondition implicitly applies to <tt>basic_string::copy</tt> (23.4.3.7.7 <a href="https://wg21.link/string.copy">[string.copy]</a>), 
and <tt>basic_string_view::copy</tt> (23.3.3.8 <a href="https://wg21.link/string.view.ops">[string.view.ops]</a>), which are currently required 
to support partially overlapping ranges:
</p>
<blockquote><pre>
std::string s = "abc";
s.copy(s.data() + 1, s.length() - 1);
assert(s == "aab");
</pre></blockquote>

<p><i>[2018-04-03 Priority set to 2 after discussion on the reflector.]</i></p>


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

<p>No consensus for direction; revisit in San Diego. Status to Open.</p>

<p><i>[2022-04-25; Daniel rebases wording on <a href="https://wg21.link/N4910">N4910</a>]</i></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>

<p>
Option A:
</p>
<blockquote>
<ol>
<li>
<p>Edit 23.2.2 <a href="https://wg21.link/char.traits.require">[char.traits.require]</a>, Table 75 &mdash; "Character traits requirements" [tab:char.traits.req], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 75 &mdash; Character traits requirements [tab:char.traits.req]</caption>
<tr style="text-align:center">
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br/>pre/post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>X::copy(s,p,n)</tt>
</td>
<td>
<tt>X::char_type*</tt>
</td>
<td>
<i>Preconditions:</i> <del><tt>p</tt> not in <tt>[s,s+n)</tt></del><ins>The ranges <tt>[p,p+n)</tt><br/>
and <tt>[s,s+n)</tt> do not overlap</ins>.<br/>
<i>Returns:</i> <tt>s</tt>.<br/>
for each <tt>i</tt> in <tt>[0,n)</tt>, performs<br/>
<tt>X::assign(s[i],p[i])</tt>.
</td>
<td>
linear
</td>
</tr>
<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

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

<p>
Option B:
</p>
<blockquote>
<p>NAD (i.e. implementations need to be fixed, in practice <tt>char_traits::copy</tt> and 
<tt>char_traits::move</tt> might be equivalent).
</p>
</blockquote>
</blockquote>

<p><i>[Kona 2022-11-11; Move to Ready]</i></p>

<p>LWG voted for Option A (6 for, 0 against, 1 netural)</p>



<p id="res-3085"><b>Proposed resolution:</b></p>
<ol>
<li>
<p>Edit 23.2.2 <a href="https://wg21.link/char.traits.require">[char.traits.require]</a>, Table 75 &mdash; "Character traits requirements" [tab:char.traits.req], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 75 &mdash; Character traits requirements [tab:char.traits.req]</caption>
<tr style="text-align:center">
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br/>pre/post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>X::copy(s,p,n)</tt>
</td>
<td>
<tt>X::char_type*</tt>
</td>
<td>
<i>Preconditions:</i> <del><tt>p</tt> not in <tt>[s,s+n)</tt></del><ins>The ranges <tt>[p,p+n)</tt><br/>
and <tt>[s,s+n)</tt> do not overlap</ins>.<br/>
<i>Returns:</i> <tt>s</tt>.<br/>
for each <tt>i</tt> in <tt>[0,n)</tt>, performs<br/>
<tt>X::assign(s[i],p[i])</tt>.
</td>
<td>
linear
</td>
</tr>
<tr>
<td colspan="4" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

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






<hr>
<h3><a name="3664" href="https://cplusplus.github.io/LWG/lwg-active.html#3664">3664</a>. LWG 3392 broke <tt>std::ranges::distance(a, a+3)</tt></h3>
<p><b>Section:</b> 25.4.4.3 <a href="https://wg21.link/range.iter.op.distance">[range.iter.op.distance]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Arthur O'Dwyer <b>Opened:</b> 2022-01-23 <b>Last modified:</b> 2022-11-10</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.iter.op.distance">issues</a> in [range.iter.op.distance].</p>
<p><b>Discussion:</b></p>
<p>
Consider the use of <tt>std::ranges::distance(first, last)</tt> on a simple C array.
This works fine with <tt>std::distance</tt>, but currently does not work with
<tt>std::ranges::distance</tt>.
</p>
<blockquote>
<pre>
// <a href="https://godbolt.org/z/vsxbcfEv6">godbolt link</a>
#include &lt;ranges&gt;
#include &lt;cassert&gt;

int main() {
  int a[] = {1, 2, 3};
  assert(std::ranges::distance(a, a+3) == 3);
  assert(std::ranges::distance(a, a) == 0);
  assert(std::ranges::distance(a+3, a) == -3);
}
</pre>
</blockquote>
<p>
Before LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3392">3392</a>, we had a single iterator-pair overload:
</p>
<blockquote><pre>
template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
  constexpr iter_difference_t&lt;I&gt; distance(I first, S last);
</pre></blockquote>
<p>
which works fine for C pointers. After LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3392">3392</a>, we have two
iterator-pair overloads:
</p>
<blockquote><pre>
template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
  requires (!sized_sentinel_for&lt;S, I&gt;)
    constexpr iter_difference_t&lt;I&gt; distance(I first, S last);

template&lt;input_or_output_iterator I, sized_sentinel_for&lt;I&gt; S&gt;
  constexpr iter_difference_t&lt;I&gt; distance(const I&amp; first, const S&amp; last);
</pre></blockquote>
<p>
and unfortunately the one we want &mdash; <tt>distance(I first, S last)</tt> &mdash; 
is no longer viable because [with <tt>I=int*</tt>, <tt>S=int*</tt>], we have
<tt>sized_sentinel_for&lt;S, I&gt;</tt> and so its constraints aren't satisfied.
So we look at the other overload [with <tt>I=int[3]</tt>, <tt>S=int[3]</tt>], but
unfortunately its constraints aren't satisfied either, because <tt>int[3]</tt>
is not an <tt>input_or_output_iterator</tt>.
</p>

<p><i>[2022-01-30; 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/N4901">N4901</a>. 
</p>

<blockquote class="note">
<p>
[<i>Drafting Note:</i> Thanks to Casey Carter. Notice that <tt>sentinel_for&lt;S, I&gt;</tt> 
already implies and subsumes <tt>input_or_output_iterator&lt;I&gt;</tt>, so that constraint 
wasn't doing anything; personally I'd prefer to remove it for symmetry (and to save the 
environment). Otherwise you'll have people asking why one of the <tt>I</tt>'s is constrained 
and the other isn't.] 
</p>
</blockquote>

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

<blockquote>
<pre>
[&hellip;]
<i>// 25.4.4.3 <a href="https://wg21.link/range.iter.op.distance">[range.iter.op.distance]</a>, ranges::distance</i>
template&lt;<ins>class</ins><del>input_or_output_iterator</del> I, sentinel_for&lt;I&gt; S&gt;
  requires (!sized_sentinel_for&lt;S, I&gt;)
  constexpr iter_difference_t&lt;I&gt; distance(I first, S last);
template&lt;<ins>class</ins><del>input_or_output_iterator</del> I, sized_sentinel_for&lt;<ins>decay_t&lt;</ins>I<ins>&gt;</ins>&gt; S&gt;
  constexpr iter_difference_t&lt;I&gt; distance(const I&amp; first, <del>const</del> S<del>&amp;</del> last);
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;<ins>class</ins><del>input_or_output_iterator</del> I, sentinel_for&lt;I&gt; S&gt;
  requires (!sized_sentinel_for&lt;S, I&gt;)
  constexpr iter_difference_t&lt;I&gt; ranges::distance(I first, S last);
</pre>
<blockquote>
<p>
-1- <i>Preconditions:</i> <tt>[first, last)</tt> denotes a range.
<p/>
-2- <i>Effects:</i> Increments <tt>first</tt> until <tt>last</tt> is reached and returns the number of increments.
</p>
</blockquote>
<pre>
template&lt;<ins>class</ins><del>input_or_output_iterator</del> I, sized_sentinel_for&lt;<ins>decay_t&lt;</ins>I<ins>&gt;</ins>&gt; S&gt;
  constexpr iter_difference_t&lt;I&gt; ranges::distance(const I&amp; first, <del>const</del> S<del>&amp;</del> last);
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Equivalent to: <tt>return last - first;</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2022-02-16; Arthur and Casey provide improved wording]</i></p>


<p><i>[Kona 2022-11-08; Move to Ready]</i></p>




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

<blockquote class="note">
<p>
[<i>Drafting Note:</i> Arthur thinks it's a bit "cute" of the <i>Effects:</i> element to <tt>static_cast</tt> 
from <tt>T(&amp;)[N]</tt> to <tt>T* const&amp;</tt> in the array case, but it does seem to do the right thing 
in all cases, and it saves us from having to use an <tt>if constexpr (is_array_v...)</tt> or something like that.] 
</p>
</blockquote>

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

<blockquote>
<pre>
[&hellip;]
<i>// 25.4.4.3 <a href="https://wg21.link/range.iter.op.distance">[range.iter.op.distance]</a>, ranges::distance</i>
template&lt;<ins>class</ins><del>input_or_output_iterator</del> I, sentinel_for&lt;I&gt; S&gt;
  requires (!sized_sentinel_for&lt;S, I&gt;)
  constexpr iter_difference_t&lt;I&gt; distance(I first, S last);
template&lt;<ins>class</ins><del>input_or_output_iterator</del> I, sized_sentinel_for&lt;<ins>decay_t&lt;</ins>I<ins>&gt;</ins>&gt; S&gt;
  constexpr iter_difference_t&lt;<ins>decay_t&lt;</ins>I<ins>&gt;</ins>&gt; distance(<del>const</del> I&amp;<ins>&amp;</ins> first, <del>const</del> S<del>&amp;</del> last);
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;<ins>class</ins><del>input_or_output_iterator</del> I, sentinel_for&lt;I&gt; S&gt;
  requires (!sized_sentinel_for&lt;S, I&gt;)
  constexpr iter_difference_t&lt;I&gt; ranges::distance(I first, S last);
</pre>
<blockquote>
<p>
-1- <i>Preconditions:</i> <tt>[first, last)</tt> denotes a range.
<p/>
-2- <i>Effects:</i> Increments <tt>first</tt> until <tt>last</tt> is reached and returns the number of increments.
</p>
</blockquote>
<pre>
template&lt;<ins>class</ins><del>input_or_output_iterator</del> I, sized_sentinel_for&lt;<ins>decay_t&lt;</ins>I<ins>&gt;</ins>&gt; S&gt;
  constexpr iter_difference_t&lt;<ins>decay_t&lt;</ins>I<ins>&gt;</ins>&gt; ranges::distance(<del>const</del> I&amp;<ins>&amp;</ins> first, <del>const</del> S<del>&amp;</del> last);
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Equivalent to: <tt>return last - <ins>static_cast&lt;const decay_t&lt;I&gt;&amp;&gt;(</ins>first<ins>)</ins>;</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3720" href="https://cplusplus.github.io/LWG/lwg-active.html#3720">3720</a>. Restrict the valid types of <i>arg-id</i> for <i>width</i> and <i>precision</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-11-10</p>
<p><b>Priority: </b>2
</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>
The issue is the integral type requirement. The following code is currently valid:
</p>
<blockquote><pre>
std::cout &lt;&lt; std::format("{:*^{}}\n", 'a', '0');
std::cout &lt;&lt; std::format("{:*^{}}\n", 'a', true);
</pre></blockquote>
<p>
The output of the first example depends on the value of <tt>'0'</tt> in the implementation. 
When a <tt>char</tt> has <tt>signed char</tt> as underlying type negative values are invalid, 
while the same value would be valid when the underlying type is <tt>unsigned char</tt>.
For the second example the range of a boolean is very small, so this seems not really useful.
<p/>
Currently libc++ rejects these two examples and MSVC STL accepts them.
The members of the MSVC STL team, I spoke, agree these two cases should be rejected.
<p/>
The following integral types are rejected by both libc++ and MSVC STL:
</p>
<blockquote><pre>
std::cout &lt;&lt; std::format("{:*^{}}\n", 'a', L'0');
std::cout &lt;&lt; std::format("{:*^{}}\n", 'a', u'0');
std::cout &lt;&lt; std::format("{:*^{}}\n", 'a', U'0');
std::cout &lt;&lt; std::format("{:*^{}}\n", 'a', u8'0');
</pre></blockquote>
<p>
In order to accept these character types they need to meet the basic formatter 
requirements per 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
</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>
which requires adding the following enabled formatter specializations to
22.14.6.3 <a href="https://wg21.link/format.formatter.spec">[format.formatter.spec]</a>.
</p>
<blockquote><pre>
template&lt;&gt; struct formatter&lt;wchar_t, char&gt;;

template&lt;&gt; struct formatter&lt;char8_t, charT&gt;;
template&lt;&gt; struct formatter&lt;char16_t, charT&gt;;
template&lt;&gt; struct formatter&lt;char32_t, charT&gt;;
</pre></blockquote>
<p>
Note, that the specialization <tt>template&lt;&gt; struct formatter&lt;char, wchar_t&gt;</tt>
is already required by the Standard.
<p/>
Not only do they need to be added, but it also needs to be specified how
they behave when their value is not in the range of representable values
for <tt>charT</tt>.
<p/>
Instead of requiring these specializations, I propose to go the other
direction and limit the allowed types to signed and unsigned integers.
</p>

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

<p>
Set priority to 2 after reflector poll. Tim Song commented:
</p>
<blockquote><p>
"This is technically a breaking change, so we should do it sooner rather than later.
</p><p>
"I don't agree with the second part of the argument though - I don't see how this wording requires adding those transcoding specializations. Nothing in this wording requires integral types that cannot be packed into basic_format_arg to be accepted.
</p><p>
"I also think we need to restrict this to signed or unsigned integer types with size no greater than sizeof(long long). Larger types get type-erased into a handle and the value isn't really recoverable without heroics."
</p></blockquote>

<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 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 <del>integral</del><ins>signed or unsigned integer</ins> 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>
</li>

<li><p>Add a new paragraph to C.1.9 <a href="https://wg21.link/diff.cpp20.utilities">[diff.cpp20.utilities]</a> as indicated:</p>

<blockquote>
<p>
<ins><b>Affected subclause:</b> 22.14 <a href="https://wg21.link/format">[format]</a></ins>
<p/>
<ins><b>Change:</b> Requirement changes of <i>arg-id</i> of the <i>width</i> and <i>precision</i>
fields of <i>std-format-spec</i>. <i>arg-id</i> now requires a signed or unsigned integer type instead 
of an integral type.</ins>
<p/>
<ins><b>Rationale:</b> Avoid types that are not useful and the need to specify enabled
  formatter specializations for all character types.</ins>
<p/>
<ins><b>Effect on original feature:</b> Valid C++ 2020 code that passes a boolean or character type 
as <i>arg-id</i> becomes invalid. For example:</ins>
</p>
<blockquote><pre>
<ins>std::format("{:*^{}}", "", true); <i>// ill-formed, previously returned "*"</i></ins>
</pre></blockquote>
</blockquote>

</li>

</ol>
</blockquote>

<p><i>[2022-11-01; Jonathan provides improved wording]</i></p>


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

<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</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>
-8- 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
<del>integral</del><ins>standard signed or unsigned integer</ins> type,
or its value is negative, an exception of type <tt>format_error</tt> is thrown.
</p>
</blockquote>
</li>

<li><p>Add a new paragraph to C.1.9 <a href="https://wg21.link/diff.cpp20.utilities">[diff.cpp20.utilities]</a> as indicated:</p>

<blockquote>
<p>
<ins><b>Affected subclause:</b> 22.14.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a></ins>
<p/>
<ins><b>Change:</b> Restrict types of formatting arguments used as
<i>width</i> or <i>precision</i> in a <i>std-format-spec</i>.</ins>
<p/>
<ins><b>Rationale:</b> Avoid types that are not useful or do not have
portable semantics.</ins>
<p/>
<ins><b>Effect on original feature:</b> Valid C++ 2020 code that passes a boolean or character type
as <i>arg-id</i> becomes invalid. For example:</ins>
</p>
<blockquote><pre>
<ins>std::format("{:*^{}}", "", true); <i>// ill-formed, previously returned "*"</i></ins>
<ins>std::format("{:*^{}}", "", '1'); <i>// ill-formed, previously returned an implementation-defined number of '*' characters</i></ins>
</pre></blockquote>
</blockquote>
</li>
</ol>

</blockquote>

<p><i>[2022-11-10; Jonathan revises wording]</i></p>

<p>Improve Annex C entry.</p>
<p><i>[Kona 2022-11-10; Move to Ready]</i></p>




<p id="res-3720"><b>Proposed resolution:</b></p>

<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</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>
-8- 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
<del>integral</del><ins>standard signed or unsigned integer</ins> type,
or its value is negative, an exception of type <tt>format_error</tt> is thrown.
</p>
</blockquote>
</li>

<li><p>Add a new paragraph to C.1.9 <a href="https://wg21.link/diff.cpp20.utilities">[diff.cpp20.utilities]</a> as indicated:</p>

<blockquote>
<p>
<ins><b>Affected subclause:</b> 22.14.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a></ins>
<p/>
<ins><b>Change:</b> Restrict types of formatting arguments used as
<i>width</i> or <i>precision</i> in a <i>std-format-spec</i>.</ins>
<p/>
<ins><b>Rationale:</b> Disallow types that do not have useful or portable
semantics as a formatting width or precision. </ins>
<p/>
<ins><b>Effect on original feature:</b> Valid C++ 2020 code that passes a boolean or character type
as <i>arg-id</i> becomes invalid. For example:</ins>
</p>
<blockquote><pre>
<ins>std::format("{:*^{}}", "", true); <i>// ill-formed, previously returned "*"</i></ins>
<ins>std::format("{:*^{}}", "", '1'); <i>// ill-formed, previously returned an implementation-defined number of '*' characters</i></ins>
</pre></blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3756" href="https://cplusplus.github.io/LWG/lwg-active.html#3756">3756</a>. Is the <tt>std::atomic_flag</tt> class signal-safe?</h3>
<p><b>Section:</b> 17.13.5 <a href="https://wg21.link/support.signal">[support.signal]</a>, 33.5.10 <a href="https://wg21.link/atomics.flag">[atomics.flag]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Ruslan Baratov <b>Opened:</b> 2022-08-18 <b>Last modified:</b> 2022-11-11</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
Following document number <a href="https://wg21.link/N4910">N4910</a> about signal-safe instructions
17.13.5 <a href="https://wg21.link/support.signal">[support.signal]</a> Signal handlers, and it's unclear whether
<tt>std::atomic_flag</tt> is signal-safe.
<p/>
Formally it doesn't fit any of the mentioned conditions:
</p>
<ul>
<li><p><tt>f</tt> is a non-static member function invoked on an object <tt>A</tt>, such that
<tt>A.is_lock_free()</tt> yields <tt>true</tt>, or</p>
<blockquote class="note"><p>
(there is no <tt>is_lock_free</tt> method in <tt>std::atomic_flag</tt> class)
</p></blockquote>
</li>
<li><p><tt>f</tt> is a non-member function, and for every pointer-to-atomic argument <tt>A</tt>
passed to <tt>f</tt>, <tt>atomic_is_lock_free(A)</tt> yields <tt>true</tt></p>
<blockquote class="note"><p>
(<tt>std::atomic_flag</tt> object can't be passed to <tt>atomic_is_lock_free</tt> as argument)
</p></blockquote></li>
</ul>
<p>
However, <tt>std::atomic_flag</tt> seem to fit well here, it's atomic, and it's
always lock-free.
<p/>
The suggestion is as follows: If <tt>std::atomic_flag</tt> is signal-safe, then it
should be explicitly mentioned in 17.13.5 <a href="https://wg21.link/support.signal">[support.signal]</a>, e.g., the following lines
should be added:
</p>
<blockquote>
<ul>
<li><p><ins><tt>f</tt> is a non-static member function invoked on an <tt>atomic_flag</tt> object, or</ins></p></li>
<li><p><ins><tt>f</tt> is a non-member function, and every pointer-to-atomic argument
passed to <tt>f</tt> is <tt>atomic_flag</tt>, or</ins></p></li>
</ul>
</blockquote>
<p>
If the <tt>std::atomic_flag</tt> is not signal-safe, the following note could be added:
</p>
<blockquote>
<p>
<ins>[<i>Note:</i> Even though <tt>atomic_flag</tt> is atomic and lock-free, it's not signal-safe. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>

<p><i>[2022-09-23; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll. Send to SG1.
</p>
<p>
Another way to fix this is to add <tt>is_always_lock_free (=true)</tt> and
<tt>is_lock_free() { return true; }</tt> to <tt>atomic_flag</tt>.
</p>

<p><i>[Kona 2022-11-10; SG1 yields a recommendation]</i></p>

<p>
Poll: Adopt the proposed resolution for LWG3756 <br/>
"f is a non-static member function invoked on an
atomic_flag object, or"
<br/>
"f is a non-member function, and every pointer-to-
atomic argument passed to f is atomic_flag, or"
<pre>
SF F N A SA
11 3 0 0 0
</pre>
</p>
<p>
Unanimous consent
</p>
<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">

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

<ol>
<li><p>Modify 17.13.5 <a href="https://wg21.link/support.signal">[support.signal]</a> as indicated:</p>
<blockquote>
<p>-1-
A call to the function <tt>signal</tt> synchronizes with any resulting
invocation of the signal handler so installed.
</p>

<p>-2-
A <i>plain lock-free atomic operation</i> is an invocation of a function
<tt>f</tt> from 33.5 <a href="https://wg21.link/atomics">[atomics]</a>, such that:
</p>
<ol style="list-style-type: none">
<li>(2.1) &mdash;
<tt>f</tt> is the function <tt>atomic_is_lock_free()</tt>, or
</li>
<li>(2.2) &mdash;
<tt>f</tt> is the member function <tt>is_lock_free()</tt>, or
</li>
<li><ins>(2.?) &mdash;
<tt>f</tt> is a non-static member function invoked on an
<tt>atomic_flag</tt> object, or</ins>
</li>
<li><ins>(2.?) &mdash;
<tt>f</tt> is a non-member function, and every pointer-to-atomic argument
passed to <tt>f</tt> is <tt>atomic_flag</tt>, or</ins>
</li>
<li>(2.3) &mdash;
<tt>f</tt> is a non-static member function invoked on an object <tt>A</tt>,
such that <tt>A.is_lock_free()</tt> yields <tt>true</tt>, or
</li>
<li>(2.4) &mdash;
<tt>f</tt> is a non-member function, and for every pointer-to-atomic argument
<tt>A</tt> passed to <tt>f</tt>,
<tt>atomic_is_lock_free(A)</tt> yields <tt>true</tt>.
</li>
</ol>
<p>-3-
An evaluation is <i>signal-safe</i> unless it includes one of the following:
</p>
<ol style="list-style-type: none">
<li>(3.1) &mdash;
a call to any standard library function, except for plain lock-free
atomic operations and functions explicitly identified as signal-safe;
<p>
[<i>Note 1</i>: This implicitly excludes the use of <tt>new</tt> and
<tt>delete</tt> expressions that rely on a library-provided memory allocator.
&mdash; <i>end note</i>]
</p>
</li>
<li>(3.2) &mdash;
an access to an object with thread storage duration;
</li>
<li>(3.3) &mdash;
a <tt>dynamic_cast</tt> expression;
</li>
<li>(3.4) &mdash;
throwing of an exception;
</li>
<li>(3.5) &mdash;
control entering a <i>try-block</i> or <i>function-try-block</i>;
</li>
<li>(3.6) &mdash;
initialization of a variable with static storage duration requiring
dynamic initialization (6.9.3.3 <a href="https://wg21.link/basic.start.dynamic">[basic.start.dynamic]</a>, 8.8 <a href="https://wg21.link/stmt.dcl">[stmt.dcl]</a>)<sup>206</sup>; or
</li>
<li>(3.7) &mdash;
waiting for the completion of the initialization of a variable with
static storage duration (8.8 <a href="https://wg21.link/stmt.dcl">[stmt.dcl]</a>).
</li>
</ol>
<p>
A signal handler invocation has undefined behavior if it includes an
evaluation that is not signal-safe.
</p>
</blockquote>
</li>
</ol>


</blockquote>

<p><i>[2022-11-11; Jonathan provides improved wording]</i></p>

<p><i>[Kona 2022-11-11; Move to Ready]</i></p>




<p id="res-3756"><b>Proposed resolution:</b></p>

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

<ol>
<li><p>Modify 17.13.5 <a href="https://wg21.link/support.signal">[support.signal]</a> as indicated:</p>
<blockquote>
<p>-1-
A call to the function <tt>signal</tt> synchronizes with any resulting
invocation of the signal handler so installed.
</p>

<p>-2-
A <i>plain lock-free atomic operation</i> is an invocation of a function
<tt>f</tt> from 33.5 <a href="https://wg21.link/atomics">[atomics]</a>, such that:
</p>
<ol style="list-style-type: none">
<li>(2.1) &mdash;
<tt>f</tt> is the function <tt>atomic_is_lock_free()</tt>, or
</li>
<li>(2.2) &mdash;
<tt>f</tt> is the member function <tt>is_lock_free()</tt>, or
</li>
<li><ins>(2.?) &mdash;
<tt>f</tt> is a non-static member function of class <tt>atomic_flag</tt>, or
</ins>
</li>
<li><ins>(2.?) &mdash;
<tt>f</tt> is a non-member function, and the first parameter of <tt>f</tt>
has type <i>cv</i> <tt>atomic_flag*</tt>, or
</ins>
</li>
<li>(2.3) &mdash;
<tt>f</tt> is a non-static member function invoked on an object <tt>A</tt>,
such that <tt>A.is_lock_free()</tt> yields <tt>true</tt>, or
</li>
<li>(2.4) &mdash;
<tt>f</tt> is a non-member function, and for every pointer-to-atomic argument
<tt>A</tt> passed to <tt>f</tt>,
<tt>atomic_is_lock_free(A)</tt> yields <tt>true</tt>.
</li>
</ol>
<p>-3-
An evaluation is <i>signal-safe</i> unless it includes one of the following:
</p>
<ol style="list-style-type: none">
<li>(3.1) &mdash;
a call to any standard library function, except for plain lock-free
atomic operations and functions explicitly identified as signal-safe;
<p>
[<i>Note 1</i>: This implicitly excludes the use of <tt>new</tt> and
<tt>delete</tt> expressions that rely on a library-provided memory allocator.
&mdash; <i>end note</i>]
</p>
</li>
<li>(3.2) &mdash;
an access to an object with thread storage duration;
</li>
<li>(3.3) &mdash;
a <tt>dynamic_cast</tt> expression;
</li>
<li>(3.4) &mdash;
throwing of an exception;
</li>
<li>(3.5) &mdash;
control entering a <i>try-block</i> or <i>function-try-block</i>;
</li>
<li>(3.6) &mdash;
initialization of a variable with static storage duration requiring
dynamic initialization (6.9.3.3 <a href="https://wg21.link/basic.start.dynamic">[basic.start.dynamic]</a>, 8.8 <a href="https://wg21.link/stmt.dcl">[stmt.dcl]</a>)<sup>206</sup>; or
</li>
<li>(3.7) &mdash;
waiting for the completion of the initialization of a variable with
static storage duration (8.8 <a href="https://wg21.link/stmt.dcl">[stmt.dcl]</a>).
</li>
</ol>
<p>
A signal handler invocation has undefined behavior if it includes an
evaluation that is not signal-safe.
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3769" href="https://cplusplus.github.io/LWG/lwg-active.html#3769">3769</a>. <tt>basic_const_iterator::operator==</tt> causes infinite constraint recursion</h3>
<p><b>Section:</b> 25.5.3 <a href="https://wg21.link/const.iterators">[const.iterators]</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-09-05 <b>Last modified:</b> 2022-11-10</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#const.iterators">active issues</a> in [const.iterators].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#const.iterators">issues</a> in [const.iterators].</p>
<p><b>Discussion:</b></p>
<p>
Currently, <tt>basic_const_iterator::operator==</tt> is defined as a <tt>friend</tt> function:
</p>
<blockquote><pre>
template&lt;sentinel_for&lt;Iterator&gt; S&gt;
  friend constexpr bool operator==(const basic_const_iterator&amp; x, const S&amp; s);
</pre></blockquote>
<p>
which only requires <tt>S</tt> to model <tt>sentinel_for&lt;Iterator&gt;</tt>, and since 
<tt>basic_const_iterator</tt> has a conversion constructor that accepts <tt>I</tt>, this will 
result in infinite constraint checks when comparing  <tt>basic_const_iterator&lt;int*&gt;</tt> 
with <tt>int*</tt> (<a href="https://godbolt.org/z/bGhccroz4">online example</a>):
</p>
<blockquote><pre>
#include &lt;iterator&gt;

template&lt;std::input_iterator I&gt;
struct basic_const_iterator {
  basic_const_iterator() = default;
  basic_const_iterator(I);
  template&lt;std::sentinel_for&lt;I&gt; S&gt;
  friend bool operator==(const basic_const_iterator&amp;, const S&amp;);
};
  
static_assert(std::sentinel_for&lt;basic_const_iterator&lt;int*&gt;, int*&gt;); // <span style="color:red;font-weight:bolder">infinite meta-recursion</span>
</pre></blockquote>    
<p>
That is, <tt>sentinel_for</tt> ends with <tt><i>weakly-equality-comparable-with</i></tt> 
and instantiates <tt>operator==</tt>, which in turn rechecks <tt>sentinel_for</tt> and 
instantiates the same <tt>operator==</tt>, making the circle closed.
<p/>
The proposed resolution is to change <tt>operator==</tt> to be a member function so that 
<tt>S</tt> is no longer accidentally instantiated as <tt>basic_const_iterator</tt>. 
The same goes for <tt>basic_const_iterator::operator-</tt>.
</p>

<p><i>[2022-09-23; Reflector poll]</i></p>

<p>
Set priority to 1 after reflector poll.
</p>
<p>
"Although I am not a big fan of member ==,  the proposed solution seems to be simple."
"prefer if we would keep <tt>operator==</tt> as non-member for consistency."
</p>

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

<ol>

<li><p>Modify 25.5.3.3 <a href="https://wg21.link/const.iterators.iterator">[const.iterators.iterator]</a>, class template <tt>basic_const_iterator</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class I&gt;
    concept <i>not-a-const-iterator</i> = <i>see below</i>;

  template&lt;input_iterator Iterator&gt;
  class basic_const_iterator {
    Iterator <i>current_</i> = Iterator();
    using <i>reference</i> = iter_const_reference_t&lt;Iterator&gt;;         // <i>exposition only</i>
  
  public:
    [&hellip;]
    template&lt;sentinel_for&lt;Iterator&gt; S&gt;
      <del>friend</del> constexpr bool operator==(<del>const basic_const_iterator&amp; x, </del>const S&amp; s) <ins>const</ins>;
    [&hellip;]
    template&lt;sized_sentinel_for&lt;Iterator&gt; S&gt;
      <del>friend</del> constexpr difference_type operator-(<del>const basic_const_iterator&amp; x, </del>const S&amp; y) <ins>const</ins>;
    template&lt;<ins><i>not-a-const-iterator</i></ins><del>sized_sentinel_for&lt;Iterator&gt;</del> S&gt;
      requires <ins>sized_sentinel_for</ins><del><i>different-from</i></del>&lt;S, <ins>Iterator</ins><del>basic_const_iterator</del>&gt;
      friend constexpr difference_type operator-(const S&amp; x, const basic_const_iterator&amp; y);
  };
}
</pre>
</blockquote>
</li>

<li><p>Modify 25.5.3.5 <a href="https://wg21.link/const.iterators.ops">[const.iterators.ops]</a> as indicated:</p>

<blockquote>
<p>
[&hellip;]
</p>
<pre>
  template&lt;sentinel_for&lt;Iterator&gt; S&gt;
    <del>friend</del> constexpr bool operator==(<del>const basic_const_iterator&amp; x, </del>const S&amp; s) <ins>const</ins>;
</pre>
<blockquote>
<p>
-16- <i>Effects</i>: Equivalent to: <tt>return <del>x.</del><i>current_</i> == s;</tt>.
</p>
</blockquote>
[&hellip;]
<pre>
  template&lt;sized_sentinel_for&lt;Iterator&gt; S&gt;
    <del>friend</del> constexpr difference_type operator-(<del>const basic_const_iterator&amp; x, </del>const S&amp; y) <ins>const</ins>;
</pre>
<blockquote>
<p>
-24- <i>Effects</i>: Equivalent to: <tt>return <del>x.</del><i>current_</i> - y;</tt>.
</p>
</blockquote>
<pre>
  template&lt;<ins><i>not-a-const-iterator</i></ins><del>sized_sentinel_for&lt;Iterator&gt;</del> S&gt;
    requires <ins>sized_sentinel_for</ins><del><i>different-from</i></del>&lt;S, <ins>Iterator</ins><del>basic_const_iterator</del>&gt;
    friend constexpr difference_type operator-(const S&amp; x, const basic_const_iterator&amp; y);
</pre>
<blockquote>
<p>
-25- <i>Effects</i>: Equivalent to: <tt>return x - y.<i>current_</i>;</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2022-11-04; Tomasz comments and improves proposed wording]</i></p>


<p>
Initially, LWG requested an investigation of alternative resolutions that would avoid using member functions for the affected operators.
Later, it was found that in addition to <tt>==</tt>/<tt>-</tt>, all comparison operators (<tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, <tt>&gt;=</tt>, <tt>&lt;=&gt;</tt>) are affected by same problem for the calls
with <tt>basic_const_iterator&lt;basic_const_iterator&lt;int*&gt;&gt;</tt> and <tt>int*</tt> as arguments, i.e. <tt>totally_ordered_with&lt;basic_const_iterator&lt;basic_const_iterator&lt;int*&gt;&gt;, int*&gt;</tt>
causes infinite recursion in constraint checking.
</p>

<p>
The new resolution, change all of the friends overloads for operators <tt>==</tt>, <tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, <tt>&gt;=</tt>, <tt>&lt;=&gt;</tt> and <tt>-</tt> that accept <tt>basic_const_iterator</tt> as lhs, to <tt>const</tt> member functions.
This change is applied to homogeneous <tt>(basic_const_iterator, basic_const_iterator)</tt> for consistency.
For the overload of <tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, <tt>&gt;=</tt> and <tt>-</tt> that accepts <tt>(I, basic_const_iterator)</tt> we declared them as friends and consistently constrain them with <tt><i>not-const-iterator</i></tt>.
Finally, its put (now member) <tt>operator<tt>&lt;=&gt;</tt>(I)</tt> in the block with other heterogeneous overloads in the synopsis.	
</p>

<p>
The use of member functions addresses issues, because:
<ul>	
<li>it disallows conversion to <tt>basic_const_iterator</tt> in the left-hand side of op, i.e. eliminates issues for <tt>(sized_)sentinel_for&lt;basic_const_iterator&lt;int*&gt;, int*&gt;</tt> and <tt>totally_ordered&lt;basic_const_iterator&lt;int*&gt;, int*&gt;</tt></li>
<li>member functions (in contrast to friends) are not found by ADL, so we do not get multiple candidates for <tt>basic_const_iterator&lt;basic_const_iterator&lt;S&gt;&gt;</tt>, so we address recursion for nested iterators</li>
</ul>
</p>

<p><i>[Kona 2022-11-08; Move to Ready]</i></p>



<p id="res-3769"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>

<li><p>Modify 25.5.3.3 <a href="https://wg21.link/const.iterators.iterator">[const.iterators.iterator]</a>, class template <tt>basic_const_iterator</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class I&gt;
    concept <i>not-a-const-iterator</i> = <i>see below</i>;

  template&lt;input_iterator Iterator&gt;
  class basic_const_iterator {
    Iterator <i>current_</i> = Iterator();
    using <i>reference</i> = iter_const_reference_t&lt;Iterator&gt;;         // <i>exposition only</i>
  
  public:
    [&hellip;]
    template&lt;sentinel_for&lt;Iterator&gt; S&gt;
      <del>friend</del> constexpr bool operator==(<del>const basic_const_iterator&amp; x, </del>const S&amp; s) <ins>const</ins>;
	  
    <del>friend</del> constexpr bool operator&lt;(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt;;
    <del>friend</del> constexpr bool operator&gt;(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt;;
    <del>friend</del> constexpr bool operator&lt;=(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt;;
    <del>friend</del> constexpr bool operator&gt;=(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt;;
    <del>friend</del> constexpr auto operator&lt;=&gt;(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; three_way_comparable&lt;Iterator&gt;;

    template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
    <del>friend</del> constexpr bool operator&lt;(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
    template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
    <del>friend</del> constexpr bool operator&gt;(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
    template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
    <del>friend</del> constexpr bool operator&lt;=(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
    template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
    <del>friend</del> constexpr bool operator&gt;=(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
    <ins>template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
    constexpr auto operator&lt;=&gt;(const I&amp; y) const
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt; &amp;&amp;
   	       three_way_comparable_with&lt;Iterator, I&gt;;</ins>
    template&lt;<i>not-a-const-iterator</i> I&gt;
    friend constexpr bool operator&lt;(const I&amp; y, const basic_const_iterator&amp; x)
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
    template&lt;<i>not-a-const-iterator</i> I&gt;
    friend constexpr bool operator&gt;(const I&amp; y, const basic_const_iterator&amp; x)
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
    template&lt;<i>not-a-const-iterator</i> I&gt;
    friend constexpr bool operator&lt;=(const I&amp; y, const basic_const_iterator&amp; x)
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
    template&lt;<i>not-a-const-iterator</i> I&gt;
    friend constexpr bool operator&gt;=(const I&amp; y, const basic_const_iterator&amp; x)
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
    <del>template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
    friend constexpr auto operator&lt;=&gt;(const basic_const_iterator&amp; x, const I&amp; y)
      requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt; &amp;&amp;
      	       three_way_comparable_with&lt;Iterator, I&gt;;</del>


    [&hellip;]
    template&lt;sized_sentinel_for&lt;Iterator&gt; S&gt;
      <del>friend</del> constexpr difference_type operator-(<del>const basic_const_iterator&amp; x, </del>const S&amp; y) <ins>const</ins>;
    template&lt;<ins><i>not-a-const-iterator</i></ins><del>sized_sentinel_for&lt;Iterator&gt;</del> S&gt;
      requires <ins>sized_sentinel_for</ins><del><i>different-from</i></del>&lt;S, <ins>Iterator</ins><del>basic_const_iterator</del>&gt;
      friend constexpr difference_type operator-(const S&amp; x, const basic_const_iterator&amp; y);
  };
}
</pre>
</blockquote>
</li>

<li><p>Modify 25.5.3.5 <a href="https://wg21.link/const.iterators.ops">[const.iterators.ops]</a> as indicated:</p>

<blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;sentinel_for&lt;Iterator&gt; S&gt;
  <del>friend</del> constexpr bool operator==(<del>const basic_const_iterator&amp; x, </del>const S&amp; s) <ins>const</ins>;
</pre>
<blockquote>
<p>
-16- <i>Effects</i>: Equivalent to: <tt>return <del>x.</del><i>current_</i> == s;</tt>
</p>
</blockquote>
<pre>
<del>friend</del> constexpr bool operator&lt;(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt;;
<del>friend</del> constexpr bool operator&gt;(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt;;
<del>friend</del> constexpr bool operator&lt;=(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt;;
<del>friend</del> constexpr bool operator&gt;=(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt;;
<del>friend</del> constexpr auto operator&lt;=&gt;(<del>const basic_const_iterator&amp; x, </del>const basic_const_iterator&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt; &amp;&amp; three_way_comparable&lt;Iterator&gt;;
</pre>
<blockquote>
<p>
-17- Let <i>op</i> be the operator.
</p>
<p>
-18- <i>Effects</i>: Equivalent to: <tt>return <del>x.</del><i>current_</i> <i>op</i> y.<i>current_</i>;</tt>
</p>
</blockquote>
<pre>
template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
<del>friend</del> constexpr bool operator&lt;(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
<del>friend</del> constexpr bool operator&gt;(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
<del>friend</del> constexpr bool operator&lt;=(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
<del>friend</del> constexpr bool operator&gt;=(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt;;
template&lt;<i>different-from</i>&lt;basic_const_iterator&gt; I&gt;
<del>friend</del> constexpr auto operator&lt;=&gt;(<del>const basic_const_iterator&amp; x, </del>const I&amp; y) <ins>const</ins>
  requires random_access_iterator&lt;Iterator&gt; &amp;&amp; totally_ordered_with&lt;Iterator, I&gt; &amp;&amp;
  	       three_way_comparable_with&lt;Iterator, I&gt;;
</pre>
<blockquote>
<p>
-19- Let <tt><i>op</i></tt> be the operator.
</p>
<p>
-20- <i><del>Returns</del><ins>Effects</ins></i>: Equivalent to: <tt>return <del>x.</del><i>current_</i> <i>op</i> y;</tt>
</p>
</blockquote>

[&hellip;]
<pre>
template&lt;sized_sentinel_for&lt;Iterator&gt; S&gt;
  <del>friend</del> constexpr difference_type operator-(<del>const basic_const_iterator&amp; x, </del>const S&amp; y) <ins>const</ins>;
</pre>
<blockquote>
<p>
-24- <i>Effects</i>: Equivalent to: <tt>return <del>x.</del><i>current_</i> - y;</tt>
</p>
</blockquote>
<pre>
template&lt;<ins><i>not-a-const-iterator</i></ins><del>sized_sentinel_for&lt;Iterator&gt;</del> S&gt;
  requires <ins>sized_sentinel_for</ins><del><i>different-from</i></del>&lt;S, <ins>Iterator</ins><del>basic_const_iterator</del>&gt;
  friend constexpr difference_type operator-(const S&amp; x, const basic_const_iterator&amp; y);
</pre>
<blockquote>
<p>
-25- <i>Effects</i>: Equivalent to: <tt>return x - y.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3807" href="https://cplusplus.github.io/LWG/lwg-active.html#3807">3807</a>. The feature test macro for <tt>ranges::find_last</tt> should be renamed</h3>
<p><b>Section:</b> 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Marshall <b>Opened:</b> 2022-11-02 <b>Last modified:</b> 2022-11-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#version.syn">active issues</a> in [version.syn].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#version.syn">issues</a> in [version.syn].</p>
<p><b>Discussion:</b></p>
<p>
The current feature test macro is <tt>__cpp_lib_find_last</tt> which is inconsistent with almost all 
other ranges algorithms which are in the form <tt>__cpp_lib_ranges_xxx</tt>.
<p/>
Proposed resolution is to rename the macro to <tt>__cpp_lib_ranges_find_last</tt>.
</p>

<p><i>[Kona 2022-11-12; Move to Ready]</i></p>




<p id="res-3807"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

<blockquote>
<pre>
[&hellip;]
#define __cpp_lib_filesystem              201703L <i>// also in &lt;filesystem&gt;</i>
#define __cpp_lib<ins>_ranges</ins>_find_last        202207L <i>// also in &lt;algorithm&gt;</i>
#define __cpp_lib_flat_map                202207L <i>// also in &lt;flat_map&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3811" href="https://cplusplus.github.io/LWG/lwg-active.html#3811">3811</a>. <tt>views::as_const</tt> on <tt>ref_view&lt;T&gt;</tt> should return <tt>ref_view&lt;const T&gt;</tt></h3>
<p><b>Section:</b> 26.7.21.1 <a href="https://wg21.link/range.as.const.overview">[range.as.const.overview]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2022-11-03 <b>Last modified:</b> 2022-11-10</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.as.const.overview">active issues</a> in [range.as.const.overview].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.as.const.overview">issues</a> in [range.as.const.overview].</p>
<p><b>Discussion:</b></p>
<p>
For <tt>v</tt> being a non-const lvalue of type <tt>std::vector&lt;int&gt;</tt>, <tt>views::as_const(v)</tt> 
produces <tt>ref_view&lt;std::vector&lt;int&gt; const&gt;</tt>. However, when <tt>v</tt> is converted to 
<tt>ref_view</tt> by using <tt>views::all</tt>, <tt>views::as_const(views::all(v))</tt> produces 
<tt>as_const_view&lt;ref_view&lt;std::vector&lt;int&gt;&gt;&gt;</tt>.
<p/>
Invoking <tt>views::as_const</tt> on <tt>ref_view&lt;T&gt;</tt> should produce <tt>ref_view&lt;const T&gt;</tt> when 
<tt>const T</tt> models a constant range. This will reduce the number of instantiations, and make a behavior 
of <tt>views::as_const</tt> consistent on references and <tt>ref_view</tt> to containers.
</p>

<p><i>[Kona 2022-11-08; Move to Ready]</i></p>




<p id="res-3811"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

<blockquote class="note">
<p>
[<i>Drafting note</i>: If we have <tt>ref_view&lt;V&gt;</tt>, when <tt>V</tt> is constant propagating view 
(<tt>single_view</tt>, <tt>owning_view</tt>), we still can (and should) produce <tt>ref_view&lt;V const&gt;</tt>. 
This wording achieves that.]
</p>
</blockquote>

<blockquote>
<p>
-2- The name <tt>views::as_const</tt> denotes a range adaptor object (26.7.2 <a href="https://wg21.link/range.adaptor.object">[range.adaptor.object]</a>). 
Let <tt>E</tt> be an expression, let <tt>T</tt> be <tt>decltype((E))</tt>, and let <tt>U</tt> be 
<tt>remove_cvref_t&lt;T&gt;</tt>. The expression <tt>views::as_const(E)</tt> is expression-equivalent
to:
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; If <tt>views::all_t&lt;T&gt;</tt> models <tt>constant_range</tt>, then <tt>views::all(E)</tt>.</p></li>
<li><p>(2.2) &mdash; Otherwise, if <tt>U</tt> denotes <tt>span&lt;X, Extent&gt;</tt> for some type <tt>X</tt> and some 
extent <tt>Extent</tt>, then <tt>span&lt;const X, Extent&gt;(E)</tt>.</p></li>
<li><p><ins>(2.?) &mdash; Otherwise, if <tt>U</tt> denotes <tt>ref_view&lt;X&gt;</tt> for some type <tt>X</tt> and 
<tt>const X</tt> models <tt>constant_range</tt>, then <tt>ref_view(static_cast&lt;const X&amp;&gt;(E.base()))</tt>.</ins></p></li>
<li><p>(2.3) &mdash; Otherwise, if <tt>E</tt> is an lvalue, <tt>const U</tt> models <tt>constant_range</tt>, and 
<tt>U</tt> does not model <tt>view</tt>, then <tt>ref_view(static_cast&lt;const U&amp;&gt;(E))</tt>.</p></li>
<li><p>(2.4) &mdash; Otherwise, <tt>as_const_view(E)</tt>.</p></li>
</ol>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3820" href="https://cplusplus.github.io/LWG/lwg-active.html#3820">3820</a>. <tt>cartesian_product_view::<i>iterator</i>::<i>prev</i></tt> is not quite right</h3>
<p><b>Section:</b> 99 [ranges.cartesian.iterator] <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-11-08 <b>Last modified:</b> 2022-11-10</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#ranges.cartesian.iterator">active issues</a> in [ranges.cartesian.iterator].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#ranges.cartesian.iterator">issues</a> in [ranges.cartesian.iterator].</p>
<p><b>Discussion:</b></p>
<p>
Currently, <tt>cartesian_product_view::<i>iterator</i>::<i>prev</i></tt> has the following <i>Effects</i>:
</p>
<blockquote><pre>
auto&amp; it = std::get&lt;N&gt;(<i>current_</i>);
if (it == ranges::begin(std::get&lt;N&gt;(<i>parent_</i>-><i>bases_</i>))) {
  it = <i>cartesian-common-arg-end</i>(std::get&lt;N&gt;(<i>parent_</i>-&gt;<i>bases_</i>));
  if constexpr (N &gt; 0) {
    <i>prev</i>&lt;N - 1&gt;();
  }
}
--it;
</pre></blockquote>
<p>
which decrements the underlying iterator one by one using recursion. 
However, when <tt>N == 0</tt>, it still detects if the first iterator has reached the beginning and assigns it to 
the end, which is not only unnecessary, but also causes <tt><i>cartesian-common-arg-end</i></tt> to be applied to 
the first range, making it ill-formed in some cases, <a href="https://godbolt.org/z/Pd6bYnP1G">for example</a>:
</p>
<blockquote><pre>
#include &lt;ranges&gt;

int main() {
  auto r = std::views::cartesian_product(std::views::iota(0));
  r.begin() += 3; // <span style="color:red;font-weight:bolder">hard error</span>
}
</pre></blockquote>
<p>
This is because, for the first range, <tt>cartesian_product_view::<i>iterator</i>::operator+=</tt> only requires 
it to model <tt>random_access_range</tt>.
However, when <tt>x</tt> is negative, this function will call <tt><i>prev</i></tt> and indirectly calls 
<tt><i>cartesian-common-arg-end</i></tt>, since the latter constrains its argument to satisfy 
<tt><i>cartesian-product-common-arg</i></tt>, that is, <tt>common_range&lt;R&gt; || (sized_range&lt;R&gt; &amp;&amp; 
random_access_range&lt;R&gt;)</tt>, which is not the case for the unbounded <tt>iota_view</tt>, resulting in a 
hard error in <tt><i>prev</i></tt>'s function body.
<p/>
The proposed resolution changes the position of the <tt>if constexpr</tt> so that we just decrement the first 
iterator and nothing else.
</p>

<p><i>[Kona 2022-11-08; Move to Ready]</i></p>




<p id="res-3820"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>
<li><p>Modify 99 [ranges.cartesian.iterator] as indicated:</p>

<blockquote>
<pre>
template&lt;size_t N = sizeof...(Vs)&gt;
  constexpr void <i>prev</i>();
</pre>
<blockquote>
<p>
-6- <i>Effects</i>: Equivalent to:
</p>
<pre>
auto&amp; it = std::get&lt;N&gt;(<i>current_</i>);
<ins>if constexpr (N > 0) {</ins>
  if (it == ranges::begin(std::get&lt;N&gt;(<i>parent_</i>-><i>bases_</i>))) {
    it = <i>cartesian-common-arg-end</i>(std::get&lt;N&gt;(<i>parent_</i>-&gt;<i>bases_</i>));
    <del>if constexpr (N &gt; 0) {</del>
      <i>prev</i>&lt;N - 1&gt;();
    <del>}</del>
  }
<ins>}</ins>
--it;
</pre>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3825" href="https://cplusplus.github.io/LWG/lwg-active.html#3825">3825</a>. Missing compile-time argument <tt>id</tt> check in <tt>basic_format_parse_context::next_arg_id</tt></h3>
<p><b>Section:</b> 22.14.6.5 <a href="https://wg21.link/format.parse.ctx">[format.parse.ctx]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Victor Zverovich <b>Opened:</b> 2022-11-09 <b>Last modified:</b> 2022-11-11</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The definition of <tt>check_arg_id</tt> in 22.14.6.5 <a href="https://wg21.link/format.parse.ctx">[format.parse.ctx]</a> includes a (compile-time) 
argument <tt>id</tt> check in the <i>Remarks</i> element:
</p>
<blockquote>
<pre>
constexpr void check_arg_id(size_t id);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
<i>Remarks</i>: Call expressions where <tt>id &gt;= num_args_</tt> are not core constant expressions (7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>).
</p>
</blockquote>
</blockquote>
<p>
However, a similar check is missing from <tt>next_arg_id</tt> which means that there is no argument id validation 
in user-defined format specification parsing code that invokes this function (e.g. when parsing automatically 
indexed dynamic width).
</p>

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

<ol>

<li><p>Modify 22.14.6.5 <a href="https://wg21.link/format.parse.ctx">[format.parse.ctx]</a> as indicated:</p>

<blockquote>
<pre>
constexpr size_t next_arg_id();
</pre>
<blockquote>
<p>
-7- <i>Effects</i>: If <tt>indexing_ != manual</tt>, equivalent to:
</p>
<blockquote><pre>
if (indexing_ == unknown)
  indexing_ = automatic;
return next_arg_id_++;
</pre></blockquote>
<p>
-8- <i>Throws</i>: <tt>format_error</tt> if <tt>indexing_ == manual</tt> which indicates mixing of automatic and manual
argument indexing.
<p/>
<ins>-?- <i>Remarks</i>: Call expressions where <tt>next_arg_id_ &gt;= num_args_</tt> are not core constant expressions 
(7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>).</ins>
</p>
</blockquote>
</blockquote>

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

<p><i>[2022-11-11; Tomasz provide improved wording; Move to Open]</i></p>


<p>
Clarify that the value of <tt>next_arg_id_</tt> is used, and add missing "is <tt>true</tt>."
</p>

<p><i>[Kona 2022-11-11; move to Ready]</i></p>



<p id="res-3825"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>

<li><p>Modify 22.14.6.5 <a href="https://wg21.link/format.parse.ctx">[format.parse.ctx]</a> as indicated:</p>

<blockquote>
<pre>
constexpr size_t next_arg_id();
</pre>
<blockquote>
<p>
-7- <i>Effects</i>: If <tt>indexing_ != manual</tt> <ins>is <tt>true</tt></ins>, equivalent to:
</p>
<blockquote><pre>
if (indexing_ == unknown)
  indexing_ = automatic;
return next_arg_id_++;
</pre></blockquote>
<p>
-8- <i>Throws</i>: <tt>format_error</tt> if <tt>indexing_ == manual</tt> <ins>is <tt>true</tt></ins> which indicates mixing
of automatic and manual argument indexing.
<p/>
<ins>-?- <i>Remarks</i>: Let <i>cur-arg-id</i> be the value of <tt>next_arg_id_</tt> prior to this call.
Call expressions where <tt><i>cur-arg-id</i> &gt;= num_args_</tt> is <tt>true</tt> are not core constant expressions 
(7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>).</ins>
</p>
</blockquote>
</blockquote>

<blockquote>
<pre>
constexpr size_t check_arg_id(size_t id);
</pre>
<blockquote>
<p>
-9- <i>Effects</i>: If <tt>indexing_ != automatic</tt> <ins>is <tt>true</tt></ins>, equivalent to:
</p>
<blockquote><pre>
if (indexing_ == unknown)
  indexing_ = manual;
</pre></blockquote>
<p>
-10- <i>Throws</i>: <tt>format_error</tt> if <tt>indexing_ == automatic</tt> <ins>is <tt>true</tt></ins> which indicates mixing 
of automatic and manual argument indexing.
<p/>
-11- <i>Remarks</i>: Call expressions where <tt>id &gt;= num_args_</tt> <ins>is <tt>true</tt></ins> are not core constant
expressions (7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>).
</p>
</blockquote>
</blockquote>


</li>
</ol>






<h2 id="tentatively_ready">Tentatively Ready Issues</h2>
<hr>
<h3><a name="3204" href="https://cplusplus.github.io/LWG/lwg-active.html#3204">3204</a>. <tt>sub_match::swap</tt> only swaps the base class</h3>
<p><b>Section:</b> 32.8 <a href="https://wg21.link/re.submatch">[re.submatch]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2019-05-07 <b>Last modified:</b> 2022-11-30</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#re.submatch">active issues</a> in [re.submatch].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#re.submatch">issues</a> in [re.submatch].</p>
<p><b>Discussion:</b></p>
<p>
<tt>sub_match&lt;I&gt;</tt> derives publicly from <tt>pair&lt;I,I&gt;</tt>, and so inherits 
<tt>pair::swap(pair&amp;)</tt>. This means that the following program fails:
</p>
<blockquote><pre>
#include &lt;regex&gt;
#include &lt;cassert&gt;

int main()
{
  std::sub_match&lt;const char*&gt; a, b;
  a.matched = true;
  a.swap(b);
  assert(b.matched);
}
</pre></blockquote>
<p>
The <tt>pair::swap(pair&amp;)</tt> member should be hidden by a <tt>sub_match::swap(sub_match&amp;)</tt> 
member that does the right thing.
</p>

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


<p><i>[2020-05-01; Daniel adjusts wording to recent working draft]</i></p>


<p><i>[2022-04-25; Daniel adjusts wording to recent working draft]</i></p>

<p>
In addition the revised wording uses the new standard phrase "The exception specification is equivalent to"
</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 32.8 <a href="https://wg21.link/re.submatch">[re.submatch]</a>, class template <tt>sub_match</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
template&lt;class BidirectionalIterator&gt;
class sub_match : public pair&lt;BidirectionalIterator, BidirectionalIterator&gt; {
public:
  [&hellip;]
  int compare(const sub_match&amp; s) const;
  int compare(const string_type&amp; s) const;
  int compare(const value_type* s) const;
  
  <ins>void swap(sub_match&amp; s) noexcept(<i>see below</i>);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 32.8.2 <a href="https://wg21.link/re.submatch.members">[re.submatch.members]</a> as indicated:</p>

<blockquote>
<pre>
int compare(const value_type* s) const;
</pre>
<blockquote>
<p>
[&hellip;]
</p>
</blockquote>
<pre>
<ins>void swap(sub_match&amp; s) noexcept(<i>see below</i>);</ins>
</pre>
<blockquote class="note">
[<i>Drafting note:</i> The swappable requirement should really be unnecessary because <i>Cpp17Iterator</i> 
requires it, but there is no wording that requires <tt>BidirectionalIterator</tt> in Clause
32 <a href="https://wg21.link/re">[re]</a> in general meets the bidirectional iterator requirements. Note that the definition found
in 27.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a> does not extend to 32 <a href="https://wg21.link/re">[re]</a> normatively. &mdash; 
<i>end drafting note</i>]
</blockquote>
<blockquote>
<p>
<ins>-?- <i>Preconditions:</i> Lvalues of type <tt>BidirectionalIterator</tt> are swappable 
(16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>).</ins>
<p/>
<ins>-?- <i>Effects:</i> Equivalent to:</ins>
</p>
<blockquote><pre>
<ins>this-&gt;pair&lt;BidirectionalIterator, BidirectionalIterator&gt;::swap(s);
std::swap(matched, s.matched);</ins>
</pre></blockquote>
<p>
<ins>-?- <i>Remarks:</i> The exception specification is equivalent to 
<tt>is_nothrow_swappable_v&lt;BidirectionalIterator&gt;</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2022-11-06; Daniel comments and improves wording]</i></p>

<p>
With the informal acceptance of <a href="https://isocpp.org/files/papers/P2696R0.html">P2696R0</a> by 
LWG during a pre-Kona telecon, we should use the new requirement set <i>Cpp17Swappable</i> instead of 
the "LValues are swappable" requirements.
</p>


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

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



<p id="res-3204"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a> <b>and assumes the acceptance of <a href="https://isocpp.org/files/papers/P2696R0.html">P2696R0</a></b>.
</p>

<ol>
<li><p>Modify 32.8 <a href="https://wg21.link/re.submatch">[re.submatch]</a>, class template <tt>sub_match</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
template&lt;class BidirectionalIterator&gt;
class sub_match : public pair&lt;BidirectionalIterator, BidirectionalIterator&gt; {
public:
  [&hellip;]
  int compare(const sub_match&amp; s) const;
  int compare(const string_type&amp; s) const;
  int compare(const value_type* s) const;
  
  <ins>void swap(sub_match&amp; s) noexcept(<i>see below</i>);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 32.8.2 <a href="https://wg21.link/re.submatch.members">[re.submatch.members]</a> as indicated:</p>

<blockquote>
<pre>
int compare(const value_type* s) const;
</pre>
<blockquote>
<p>
[&hellip;]
</p>
</blockquote>
<pre>
<ins>void swap(sub_match&amp; s) noexcept(<i>see below</i>);</ins>
</pre>
<blockquote class="note">
[<i>Drafting note:</i> The <i>Cpp17Swappable</i> requirement should really be unnecessary because <i>Cpp17Iterator</i> 
requires it, but there is no wording that requires <tt>BidirectionalIterator</tt> in Clause
32 <a href="https://wg21.link/re">[re]</a> in general meets the bidirectional iterator requirements. Note that the definition found
in 27.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a> does not extend to 32 <a href="https://wg21.link/re">[re]</a> normatively. &mdash; 
<i>end drafting note</i>]
</blockquote>
<blockquote>
<p>
<ins>-?- <i>Preconditions:</i> <tt>BidirectionalIterator</tt> meets the <i>Cpp17Swappable</i> requirements 
(16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>).</ins>
<p/>
<ins>-?- <i>Effects:</i> Equivalent to:</ins>
</p>
<blockquote><pre>
<ins>this-&gt;pair&lt;BidirectionalIterator, BidirectionalIterator&gt;::swap(s);
std::swap(matched, s.matched);</ins>
</pre></blockquote>
<p>
<ins>-?- <i>Remarks:</i> The exception specification is equivalent to 
<tt>is_nothrow_swappable_v&lt;BidirectionalIterator&gt;</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3733" href="https://cplusplus.github.io/LWG/lwg-active.html#3733">3733</a>. <tt>ranges::to</tt> misuses <tt><i>cpp17-input-iterator</i></tt></h3>
<p><b>Section:</b> 26.5.7.2 <a href="https://wg21.link/range.utility.conv.to">[range.utility.conv.to]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> S. B. Tam <b>Opened:</b> 2022-07-10 <b>Last modified:</b> 2023-01-11</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.utility.conv.to">active issues</a> in [range.utility.conv.to].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.utility.conv.to">issues</a> in [range.utility.conv.to].</p>
<p><b>Discussion:</b></p>
<p>
<tt>ranges::to</tt> uses <tt><i>cpp17-input-iterator</i>&lt;iterator_t&lt;R&gt;&gt;</tt> to check 
whether an iterator is a <i>Cpp17InputIterator</i>, which misbehaves if there is a 
<tt>std::iterator_traits</tt> specialization for that iterator (e.g. if the iterator is a 
<tt>std::common_iterator</tt>).
</p>
<blockquote><pre>
struct MyContainer {
    template&lt;class Iter&gt;
    MyContainer(Iter, Iter);

    char* begin();
    char* end();
};

auto nul_terminated = std::views::take_while([](char ch) { return ch != '\0'; });
auto c = nul_terminated("") | std::views::common | std::ranges::to&lt;MyContainer&gt;();  // <span style="color:red;font-weight:bolder">error</span>
</pre></blockquote>
<p>
I believe that <tt>ranges::to</tt> should instead use 
<tt>derived_from&lt;typename iterator_traits&lt;iterator_t&lt;R&gt;&gt;::iterator_category, input_iterator_tag&gt;</tt>, 
which correctly detects the iterator category of a <tt>std::common_iterator</tt>.
</p>

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

<p>
Set priority to 2 after reflector poll.
Set status to Tentatively Ready after five votes in favour during reflector poll.
</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 26.5.7.2 <a href="https://wg21.link/range.utility.conv.to">[range.utility.conv.to]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class C, input_range R, class... Args&gt; requires (!view&lt;C&gt;)
  constexpr C to(R&amp;&amp; r, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-1- <i>Returns</i>: An object of type <tt>C</tt> constructed from the elements of <tt>r</tt> in the following manner:
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; If <tt>convertible_to&lt;range_reference_t&lt;R&gt;, range_value_t&lt;C&gt;&gt;</tt> is <tt>true</tt>:</p></li>
<ol style="list-style-type: none">
<li><p>(1.1.1) &mdash; If <tt>constructible_from&lt;C, R, Args...&gt;</tt> is <tt>true</tt>:</p>
<blockquote><tt>C(std::forward&lt;R&gt;(r), std::forward&lt;Args&gt;(args)...)</tt></blockquote></li>
<li><p>(1.1.2) &mdash; Otherwise, if <tt>constructible_from&lt;C, from_range_t, R, Args...&gt;</tt> is <tt>true</tt>:</p>
<blockquote><tt>C(from_range, std::forward&lt;R&gt;(r), std::forward&lt;Args&gt;(args)...)</tt></blockquote></li>
<li><p>(1.1.3) &mdash; Otherwise, if</p></li>
<ol style="list-style-type: none">
<li><p>(1.1.3.1) &mdash; <tt>common_range&lt;R&gt;</tt> is <tt>true</tt>,</p></li>
<li><p>(1.1.3.2) &mdash; <tt><del><i>cpp17-input-iterator</i></del><ins>derived_from&lt;typename 
iterator_traits</ins>&lt;iterator_t&lt;R&gt;&gt;<ins>::iterator_category, input_iterator_tag&gt;</ins></tt> 
is <tt>true</tt>, and</p></li>
<li><p>(1.1.3.3) &mdash; <tt>constructible_from&lt;C, iterator_t&lt;R&gt;, sentinel_t&lt;R&gt;, Args...&gt;</tt> is <tt>true</tt>:</p>
<blockquote><tt>C(ranges::begin(r), ranges::end(r), std::forward&lt;Args&gt;(args)...)</tt></blockquote></li>
</ol>
<li><p>(1.1.4) &mdash; Otherwise, if</p></li>
<ol style="list-style-type: none">
<li><p>(1.1.4.1) &mdash; <tt>constructible_from&lt;C, Args...&gt;</tt> is <tt>true</tt>, and</p></li>
<li><p>(1.1.4.2) &mdash; <tt><i>container-insertable</i>&lt;C, range_reference_t&lt;R&gt;&gt;</tt> is <tt>true</tt>:</p>
<blockquote><pre>
[&hellip;]
</pre></blockquote></li>
</ol>
</ol>
<li><p>(1.2) &mdash; Otherwise, if <tt>input_range&lt;range_reference_t&lt;R&gt;&gt;</tt> is <tt>true</tt>:</p>
<blockquote><pre>
to&lt;C&gt;(r | views::transform([](auto&amp;&amp; elem) {
  return to&lt;range_value_t&lt;C&gt;&gt;(std::forward&lt;decltype(elem)&gt;(elem));
}), std::forward&lt;Args&gt;(args)...);
</pre></blockquote></li>
<li><p>(1.3) &mdash; Otherwise, the program is ill-formed.</p></li>
</ol>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2022-08-27; Hewill Kang reopens and suggests a different resolution]</i></p>

<p>
This issue points out that the standard misuses <tt><i>cpp17-input-iterator</i></tt> to check 
whether the iterator meets the requirements of <i>Cpp17InputIterator</i>, and proposes to use 
<tt>iterator_traits&lt;I&gt;::iterator_category</tt> to check the iterator's category directly, 
which may lead to the following potential problems:
<p/>
First, for the range types that model both <tt>common_range</tt> and <tt>input_range</tt>, 
the expression <tt>iterator_traits&lt;I&gt;::iterator_category</tt> may not be valid, consider
</p>
<blockquote><pre>
#include &lt;ranges&gt;

struct I {
  using difference_type = int;
  using value_type = int;
  int operator*() const;
  I&amp; operator++();
  void operator++(int);
  bool operator==(const I&amp;) const;
  bool operator==(std::default_sentinel_t) const;
};

int main() {
  auto r = std::ranges::subrange(I{}, I{});
  auto v = r | std::ranges::to&lt;std::vector&lt;int&gt;&gt;(0);
}
</pre></blockquote>
<p>
Although <tt>I</tt> can serve as its own sentinel, it does not model 
<tt><i>cpp17-input-iterator</i></tt> since postfix <tt>operator++</tt> returns <tt>void</tt>, 
which causes <tt>iterator_traits&lt;R&gt;</tt> to be an empty class, making the 
expression <tt>derived_from&lt;iterator_traits&lt;I&gt;::iterator_category, input_iterator_tag&gt;</tt> ill-formed.
<p/>
Second, for <tt>common_iterator</tt>, <tt>iterator_traits&lt;I&gt;::iterator_category</tt> 
does not guarantee a strictly correct iterator category in the current standard.
<p/>
For example, when the above <tt>I::operator*</tt> returns a non-<tt>copyable</tt> object that 
can be converted to <tt>int</tt>, this makes <tt>common_iterator&lt;I, default_sentinel_t&gt;</tt> 
unable to synthesize a C++17-conforming postfix <tt>operator++</tt>, however, 
<tt>iterator_traits&lt;common_iterator&lt;I, S&gt;&gt;::iterator_category</tt> will still 
give <tt>input_iterator_tag</tt> even though it's not even a C++17 iterator.
<p/>
Another example is that for <tt>input_iterator</tt>s with difference type of integer-class type, 
the difference type of the <tt>common_iterator</tt> wrapped on it is still of the integer-class type, 
but the <tt>iterator_category</tt> obtained by the <tt>iterator_traits</tt> is <tt>input_iterator_tag</tt>. 
<p/>
The proposed resolution only addresses the first issue since I believe that the problem with 
<tt>common_iterator</tt> requires a paper.
</p>

<p><i>[2023-01-11; LWG telecon]</i></p>

<p>
Set status to Tentatively Ready (poll results F6/A0/N1)
</p>



<p id="res-3733"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>
<li><p>Modify 26.5.7.2 <a href="https://wg21.link/range.utility.conv.to">[range.utility.conv.to]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class C, input_range R, class... Args&gt; requires (!view&lt;C&gt;)
  constexpr C to(R&amp;&amp; r, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-1- <i>Returns</i>: An object of type <tt>C</tt> constructed from the elements of <tt>r</tt> in the following manner:
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; If <tt>convertible_to&lt;range_reference_t&lt;R&gt;, range_value_t&lt;C&gt;&gt;</tt> is <tt>true</tt>:</p></li>
<ol style="list-style-type: none">
<li><p>(1.1.1) &mdash; If <tt>constructible_from&lt;C, R, Args...&gt;</tt> is <tt>true</tt>:</p>
<blockquote><tt>C(std::forward&lt;R&gt;(r), std::forward&lt;Args&gt;(args)...)</tt></blockquote></li>
<li><p>(1.1.2) &mdash; Otherwise, if <tt>constructible_from&lt;C, from_range_t, R, Args...&gt;</tt> is <tt>true</tt>:</p>
<blockquote><tt>C(from_range, std::forward&lt;R&gt;(r), std::forward&lt;Args&gt;(args)...)</tt></blockquote></li>
<li><p>(1.1.3) &mdash; Otherwise, if</p></li>
<ol style="list-style-type: none">
<li><p>(1.1.3.1) &mdash; <tt>common_range&lt;R&gt;</tt> is <tt>true</tt>,</p></li>
<li><p>(1.1.3.2) &mdash; <del><tt><i>cpp17-input-iterator</i></tt></del><ins>if the <i>qualified-id</i>  
<tt>iterator_traits</tt></ins><tt>&lt;iterator_t&lt;R&gt;&gt;</tt><ins><tt>::iterator_category</tt> </ins>is<ins> 
<del><tt>true</tt></del> valid and denotes a type that models <tt>derived_from&lt;input_iterator_tag&gt;</tt></ins>, and</p></li>
<li><p>(1.1.3.3) &mdash; <tt>constructible_from&lt;C, iterator_t&lt;R&gt;, sentinel_t&lt;R&gt;, Args...&gt;</tt>:</p>
<blockquote><tt>C(ranges::begin(r), ranges::end(r), std::forward&lt;Args&gt;(args)...)</tt></blockquote></li>
</ol>
<li><p>(1.1.4) &mdash; Otherwise, if</p></li>
<ol style="list-style-type: none">
<li><p>(1.1.4.1) &mdash; <tt>constructible_from&lt;C, Args...&gt;</tt> is <tt>true</tt>, and</p></li>
<li><p>(1.1.4.2) &mdash; <tt><i>container-insertable</i>&lt;C, range_reference_t&lt;R&gt;&gt;</tt> is <tt>true</tt>:</p>
<blockquote><pre>
[&hellip;]
</pre></blockquote></li>
</ol>
</ol>
<li><p>(1.2) &mdash; Otherwise, if <tt>input_range&lt;range_reference_t&lt;R&gt;&gt;</tt> is <tt>true</tt>:</p>
<blockquote><pre>
to&lt;C&gt;(r | views::transform([](auto&amp;&amp; elem) {
  return to&lt;range_value_t&lt;C&gt;&gt;(std::forward&lt;decltype(elem)&gt;(elem));
}), std::forward&lt;Args&gt;(args)...);
</pre></blockquote></li>
<li><p>(1.3) &mdash; Otherwise, the program is ill-formed.</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3742" href="https://cplusplus.github.io/LWG/lwg-active.html#3742">3742</a>. <tt>deque::prepend_range</tt> needs to permute</h3>
<p><b>Section:</b> 24.2.4 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2022-07-16 <b>Last modified:</b> 2022-11-30</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>Discussion:</b></p>
<p>
When the range to be inserted is neither bidirectional nor sized, it's simpler to prepend 
elements one at a time, and then reverse the prepended elements. When the range to be 
inserted is neither forward nor sized, I believe this approach is necessary to implement 
<tt>prepend_range</tt> at all &mdash; there is no way to determine the length of the range 
modulo the block size of the <tt>deque</tt> ahead of time so as to insert the new elements 
in the proper position.
<p/>
The container requirements do not allow <tt>prepend_range</tt> to permute elements in a 
<tt>deque</tt>. I believe we <em>must</em> allow permutation when the range is neither 
forward nor sized, and we <em>should</em> allow permutation when the range is not bidirectional 
to allow implementations the freedom to make a single pass through the range.
</p>

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

<p>
The below suggested wording follows the existing style used in the specification of <tt>insert</tt>
and <tt>insert_range</tt>, for example. Unfortunately, this existing practice violates the usual
wording style that a <i>Cpp17XXX</i> requirement shall be <em>met</em> and that we should better
say that "lvalues of type <tt>T</tt> are swappable (16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>)" to 
be clearer about the specific swappable context. A separate editorial issue will be reported to take
care of this problem.
</p>

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

<p>
Set status to Tentatively Ready after five votes in favour during reflector poll.
</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 24.2.4 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a> as indicated:</p>

<blockquote>
<pre>
a.prepend_range(rg)
</pre>
<blockquote>
<p>
-94- <i>Result:</i> <tt>void</tt>
<p/>
-95- <i>Preconditions:</i> <tt>T</tt> is <i>Cpp17EmplaceConstructible</i> into <tt>X</tt> 
from <tt>*ranges::begin(rg)</tt>. <ins>For <tt>deque</tt>, <tt>T</tt> is also 
<tt>Cpp17MoveInsertable</tt> into <tt>X</tt>, <i>Cpp17MoveConstructible</i>, 
<i>Cpp17MoveAssignable</i>, and swappable (16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>).</ins>
<p/>
-96- <i>Effects:</i> Inserts copies of elements in <tt>rg</tt> before <tt>begin()</tt>. 
Each iterator in the range <tt>rg</tt> is dereferenced exactly once.
<p/>
[<i>Note 3</i>: The order of elements in <tt>rg</tt> is not reversed. &mdash; <i>end note</i>]
<p/>
-97- <i>Remarks:</i> Required for <tt>deque</tt>, <tt>forward_list</tt>, and <tt>list</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2022-11-07; Daniel reopens and comments]</i></p>

<p>
The proposed wording has two problems:
</p>
<ol>
<li><p>It still uses "swappable" instead of "swappable lvalues", which
with the (informal) acceptance of <a href="https://isocpp.org/files/papers/P2696R0.html">P2696R0</a>
should now become <i>Cpp17Swappable</i>.</p></li>
<li><p>It uses an atypical form to say "<tt>T</tt> (is) <i>Cpp17MoveConstructible</i>,
<i>Cpp17MoveAssignable</i>" instead of the more correct form "<tt>T</tt> meets the
<i>Cpp17MoveConstructible</i> and <i>Cpp17MoveAssignable</i> requirements". This
form was also corrected by <a href="https://isocpp.org/files/papers/P2696R0.html">P2696R0</a>.</p></li>
</ol>
<p>
The revised wording uses the <a href="https://isocpp.org/files/papers/P2696R0.html">P2696R0</a>
wording approach to fix both problems.
</p>

<p><i>[Kona 2022-11-12; Set priority to 2]</i></p>



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

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



<p id="res-3742"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a> <b>assuming that <a href="https://isocpp.org/files/papers/P2696R0.html">P2696R0</a>
has been accepted</b>.
</p>

<ol>
<li><p>Modify 24.2.4 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a> as indicated:</p>

<blockquote>
<pre>
a.prepend_range(rg)
</pre>
<blockquote>
<p>
-94- <i>Result:</i> <tt>void</tt>
<p/>
-95- <i>Preconditions:</i> <tt>T</tt> is <i>Cpp17EmplaceConstructible</i> into <tt>X</tt> 
from <tt>*ranges::begin(rg)</tt>. <ins>For <tt>deque</tt>, <tt>T</tt> is also 
<tt>Cpp17MoveInsertable</tt> into <tt>X</tt>, and <tt>T</tt> meets the <i>Cpp17MoveConstructible</i>, 
<i>Cpp17MoveAssignable</i>, and <i>Cpp17Swappable</i> (16.4.4.3 <a href="https://wg21.link/swappable.requirements">[swappable.requirements]</a>) requirements.</ins>
<p/>
-96- <i>Effects:</i> Inserts copies of elements in <tt>rg</tt> before <tt>begin()</tt>. 
Each iterator in the range <tt>rg</tt> is dereferenced exactly once.
<p/>
[<i>Note 3</i>: The order of elements in <tt>rg</tt> is not reversed. &mdash; <i>end note</i>]
<p/>
-97- <i>Remarks:</i> Required for <tt>deque</tt>, <tt>forward_list</tt>, and <tt>list</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3790" href="https://cplusplus.github.io/LWG/lwg-active.html#3790">3790</a>. P1467 accidentally changed <tt>nexttoward</tt>'s signature</h3>
<p><b>Section:</b> 28.7.1 <a href="https://wg21.link/cmath.syn">[cmath.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> David Olsen <b>Opened:</b> 2022-09-30 <b>Last modified:</b> 2023-01-11</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#cmath.syn">active issues</a> in [cmath.syn].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#cmath.syn">issues</a> in [cmath.syn].</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P1467">P1467</a> (Extended floating-point types), which was adopted for C++23 at the July plenary, 
has a typo (which is entirely my fault) that no one noticed during wording review.  The changes to the 
<tt>&lt;cmath&gt;</tt> synopsis in the paper included changing this:
</p>
<blockquote><pre>
constexpr float nexttoward(float x, long double y);       // see [library.c]
constexpr double nexttoward(double x, long double y);
constexpr long double nexttoward(long double x, long double y);   // see [library.c]
</pre></blockquote>
<p>
to this:
</p>
<blockquote><pre>
constexpr <i>floating-point-type</i> nexttoward(<i>floating-point-type</i> x, <i>floating-point-type</i> y);
</pre></blockquote>
<p>
That changed the second parameter of <tt>nexttoward</tt> from always being <tt>long double</tt> to being 
<tt><i>floating-point-type</i></tt>, which matches the type of the first parameter.
<p/>
The change is obviously incorrect. The purpose of the changes to <tt>&lt;cmath&gt;</tt> was to add overloads 
of the functions for extended floating-point types, not to change any existing signatures.
</p>

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

<p>
Set priority to 1 after reflector poll. Discussion during prioritization
revolved around whether to delete <code>nexttoward</code> for new FP types
or just restore the C++20 signatures, which might accept the new types via
implicit conversions (and so return a different type, albeit with the same
representation and same set of values).
</p>
<p>
"When the first argument to <code>nexttoward</code> is an extended
floating-point type that doesn't have the same representation as a standard
floating-point type, such as <code>std::float16_t</code>,
<code>std::bfloat16_t</code>, or <code>std::float128_t</code> (on some systems),
the call to <code>nexttoward</code> is ambiguous and ill-formed,
so the unexpected return type is not an issue.
Going through the extra effort of specifying '= delete' for
<code>nexttoward</code> overloads that have extended floating-point arguments
is a solution for a problem that doesn't really exist."
</p>

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

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

<blockquote>
<pre>
[&hellip;]
constexpr <i>floating-point-type</i> nexttoward(<i>floating-point-type</i> x, <del><i>floating-point-type</i></del><ins>long double</ins> y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
[&hellip;]
</pre>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2022-10-04; David Olsen comments and provides improved wording]</i></p>

<p>
C23 specifies variants of most of the functions in <tt>&lt;math.h&gt;</tt> for the <tt>_FloatN</tt> types 
(which are C23's equivalent of C++23's <tt>std::floatN_t</tt> types). But it does not specify those variants 
for <tt>nexttoward</tt>.
<p/>
Based on what C23 is doing, I think it would be reasonable to leave <tt>nexttoward</tt>'s signature unchanged 
from C++20. There would be no requirement to provide overloads for extended floating-point types, only for 
the standard floating-point types. Instead of explicitly deleting the overloads with extended floating-point 
types, we can just never declare them in the first place.
</p>

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

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

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

<blockquote>
<pre>
[&hellip;]
<ins>constexpr float nexttoward(float x, long double y);</ins>
<ins>constexpr double nexttoward(double x, long double y);</ins>
<ins>constexpr long double nexttoward(long double x, long double y);</ins>
<del>constexpr <i>floating-point-type</i> nexttoward(<i>floating-point-type</i> x, <i>floating-point-type</i> y);</del>
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
[&hellip;]
</pre>
</blockquote>
</li>
</ol>
</blockquote>


<p><i>[2022-11-12; Tomasz comments and provides improved wording]</i></p>

<p>
During 2022-10-26 LWG telecon we decided that we want to make the calls of the <code>nexttoward</code>
to be ill-formed (equivalent of Mandates) when the first argument is extended floating-point type.
</p>


<p><i>[2023-01-11; Reflector poll]</i></p>

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



<p id="res-3790"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>
	
<li><p>Modify 28.7.1 <a href="https://wg21.link/cmath.syn">[cmath.syn]</a>, header <tt>&lt;cmath&gt;</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
[&hellip;]
constexpr <i>floating-point-type</i> nexttoward(<i>floating-point-type</i> x, <del><i>floating-point-type</i></del><ins>long double</ins> y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
[&hellip;]
</pre>
</blockquote>
</li>


<li><p>Add following paragraph at the end of 28.7.1 <a href="https://wg21.link/cmath.syn">[cmath.syn]</a>, header <tt>&lt;cmath&gt;</tt> synopsis:</p>

<blockquote>
<ins>-?- An invocation of <tt>nexttoward</tt> is ill-formed if the argument corresponding to the <i>floating-point-type</i>
parameter has extended floating-point type.</ins>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3819" href="https://cplusplus.github.io/LWG/lwg-active.html#3819">3819</a>. <tt>reference_<i>meow</i>s_from_temporary</tt> should not use <tt>is_<i>meow</i>ible</tt></h3>
<p><b>Section:</b> 21.3.5.4 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2022-11-08 <b>Last modified:</b> 2022-11-10</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>Discussion:</b></p>
<p>
The intent of <a href="https://wg21.link/P2255R2">P2255R2</a> is for the <tt>reference_<i>meow</i>s_from_temporary</tt> traits 
to fully support cases where a prvalue is used as the source. Unfortunately the wording fails 
to do so because it tries to use the <tt>is_<i>meow</i>ible</tt> traits to say 
"the initialization is well-formed", but those traits only consider initialization from xvalues, 
not prvalues. For example, given:
</p>
<blockquote>
<pre>
struct U {
  U();
  U(U&amp;&amp;) = delete;
};

struct T {
  T(U);
};
</pre>
</blockquote>
<p>
<tt>reference_constructs_from_temporary_v&lt;const T&amp;, U&gt;</tt> should be true, but is currently defined as <tt>false</tt>. 
We need to spell out the "is well-formed" condition directly.
</p>

<p><i>[Kona 2022-11-08; Move to Tentatively Ready]</i></p>




<p id="res-3819"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The note is already repeated every time we talk about "immediate context".]
</p>
</blockquote>

<ol>
<li><p>Modify 21.3.3 <a href="https://wg21.link/meta.type.synop">[meta.type.synop]</a>, Table 46 ([tab:meta.unary.prop]) &mdash; 
"Type property predicates" &mdash; as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 46: Type property predicates [tab:meta.unary.prop]</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Preconditions</th>
</tr>

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

<tr>
<td>
<tt>template&lt;class T, class U&gt;<br/>
struct reference_constructs_from_temporary;</tt>
</td>

<td>
<del><tt>conjunction_v&lt;is_reference&lt;T&gt;, is_constructible&lt;T, U&gt;&gt;</tt> is
<tt>true</tt></del><ins><tt>T</tt> is a reference type</ins>,
and the initialization <tt>T t(<i>VAL</i>&lt;U&gt;);</tt> <ins>is well-formed and</ins> binds <tt>t</tt> to a
temporary object whose lifetime is extended (6.7.7 <a href="https://wg21.link/class.temporary">[class.temporary]</a>).
<ins>Access checking is performed as if in a context unrelated to <tt>T</tt> and <tt>U</tt>. 
Only the validity of the immediate context of the variable initialization is considered. 
[<i>Note ?:</i> The initialization can result in effects such as the instantiation of class template 
specializations and function template specializations, the generation of implicitly-defined functions, 
and so on. Such effects are not in the "immediate context" and can result in the program being ill-formed.
<i>&mdash; end note]</i></ins>
</td>

<td>
<tt>T</tt> and <tt>U</tt> shall be complete types, <i>cv</i> <tt>void</tt>, or arrays of unknown bound.
</td>
</tr>

<tr>
<td>
<tt>template&lt;class T, class U&gt;<br/>
struct reference_converts_from_temporary;</tt>
</td>

<td>
<del><tt>conjunction_v&lt;is_reference&lt;T&gt;, is_convertible&lt;U, T&gt;&gt;</tt> is
<tt>true</tt></del><ins><tt>T</tt> is a reference type</ins>, and the initialization
<tt>T t = <i>VAL</i>&lt;U&gt;;</tt> <ins>is well-formed and</ins> binds <tt>t</tt> to a
temporary object whose lifetime is extended (6.7.7 <a href="https://wg21.link/class.temporary">[class.temporary]</a>).
<ins>Access checking is performed as if in a context unrelated to <tt>T</tt> and <tt>U</tt>. 
Only the validity of the immediate context of the variable initialization is considered. 
[<i>Note ?:</i> The initialization can result in effects such as the instantiation of class template 
specializations and function template specializations, the generation of implicitly-defined functions, 
and so on. Such effects are not in the "immediate context" and can result in the program being ill-formed.
<i>&mdash; end note]</i></ins>
</td>

<td>
<tt>T</tt> and <tt>U</tt> shall be complete types, <i>cv</i> <tt>void</tt>, or arrays of unknown bound.
</td>
</tr>

</table>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3821" href="https://cplusplus.github.io/LWG/lwg-active.html#3821">3821</a>. <tt>uses_allocator_construction_args</tt> should have overload for <i><tt>pair-like</tt></i></h3>
<p><b>Section:</b> 20.2.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2022-11-08 <b>Last modified:</b> 2023-01-11</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#allocator.uses.construction">active issues</a> in [allocator.uses.construction].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#allocator.uses.construction">issues</a> in [allocator.uses.construction].</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P2165R4">P2165R4</a> added a <tt><i>pair-like</i></tt> constructor to 
<tt>std::pair</tt> but didn't add a corresponding <tt>uses_allocator_construction_args</tt> overload. 
It was in <a href="https://wg21.link/P2165R3">P2165R3</a> but incorrectly removed during the small group review.
<p/>
Without LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3525">3525</a>, not having the overload would have caused emplacing a <tt><i>pair-like</i></tt> into a 
<tt>pmr::vector&lt;pair&gt;</tt> to be outright ill-formed. 
<p/>
With that issue's resolution, in cases where the constructor is not explicit we would create a temporary pair 
and then do uses-allocator construction using its pieces, and it still won't work when the constructor is explicit.
<p/>
We should just do this properly.
</p>

<p><i>[2022-11-09 Tim updates wording following LWG review]</i></p>

<p>
During review of this issue LWG noticed that neither the constructor nor the new overload should accept <tt>subrange</tt>.
<p/>
The <tt>remove_cv_t</tt> in the new paragraph is added for consistency with LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3677">3677</a>.
</p> 

<p><i>[Kona 2022-11-12; Set priority to 2]</i></p>



<p><i>[2023-01-11; LWG telecon]</i></p>

<p>
Replace <tt>P</tt> with <tt>U</tt> in p17 and
set status to Tentatively Ready (poll result: 8/0/0).
</p>



<p id="res-3821"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a> after the application of LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3677">3677</a>.
</p>
<ol>
<li><p>Edit 22.3.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class U1, class U2&gt; constexpr explicit(<i>see below</i>) pair(pair&lt;U1, U2&gt;&amp; p);
template&lt;class U1, class U2&gt; constexpr explicit(<i>see below</i>) pair(const pair&lt;U1, U2&gt;&amp; p);
template&lt;class U1, class U2&gt; constexpr explicit(<i>see below</i>) pair(pair&lt;U1, U2&gt;&amp;&amp; p);
template&lt;class U1, class U2&gt; constexpr explicit(<i>see below</i>) pair(const pair&lt;U1, U2&gt;&amp;&amp; p);
template&lt;<i>pair-like</i> P&gt; constexpr explicit(<i>see below</i>) pair(P&amp;&amp; p);
</pre>
<blockquote>
<p>
-14- Let <tt><i>FWD</i>(u)</tt> be <tt>static_cast&lt;decltype(u)&gt;(u)</tt>.
<p/>
-15- <i>Constraints:</i>
</p>
<ol style="list-style-type: none">
<li><p><ins>(15.?) &mdash; For the last overload, <tt>remove_cvref_t&lt;P&gt;</tt> is not a specialization of <tt>ranges::subrange</tt>,</ins></p></li>
<li><p>(15.1) &mdash; <tt>is_constructible_v&lt;T1, decltype(get&lt;0&gt;(<i>FWD</i>(p)))&gt;</tt> is <tt>true</tt> and</p></li>
<li><p>(15.2) &mdash; <tt>is_constructible_v&lt;T2, decltype(get&lt;1&gt;(<i>FWD</i>(p)))&gt;</tt> is <tt>true</tt>.</p></li>
</ol>
<p>
-16- <i>Effects:</i> Initializes <tt>first</tt> with <tt>get&lt;0&gt;(<i>FWD</i>(p))</tt> 
and <tt>second</tt> with <tt>get&lt;1&gt;(<i>FWD</i>(p))</tt>.
</p>
</blockquote>
</blockquote>
</li>
<li><p>Edit 20.2.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a>, header <tt>&lt;memory&gt;</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
  [&hellip;]
  <i>// 20.2.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>, uses-allocator construction</i>
  [&hellip;]
  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    pair&lt;U, V&gt;&amp; pr) noexcept;

  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    const pair&lt;U, V&gt;&amp; pr) noexcept;

  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    pair&lt;U, V&gt;&amp;&amp; pr) noexcept;

  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    const pair&lt;U, V&gt;&amp;&amp; pr) noexcept;
<ins>  template&lt;class T, class Alloc, <i>pair-like</i> P&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, P&amp;&amp; p) noexcept;</ins>
    
  template&lt;class T, class Alloc, class U&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, U&amp;&amp; u) noexcept;
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Add the following to 20.2.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>:</p>
<blockquote>
<pre>
<ins>  template&lt;class T, class Alloc, <i>pair-like</i> P&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, P&amp;&amp; p) noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>remove_cv_t&lt;T&gt;</tt> is a specialization of <tt>pair</tt> 
and <tt>remove_cvref_t&lt;P&gt;</tt> is not a specialization of <tt>ranges::subrange</tt>.</ins>
<p/>
<ins>-?- <i>Effects:</i> Equivalent to:</ins>
</p>
<blockquote><pre><ins>
return uses_allocator_construction_args&lt;T&gt;(alloc, piecewise_construct,
                                            forward_as_tuple(get&lt;0&gt;(std::forward&lt;P&gt;(p))),
                                            forward_as_tuple(get&lt;1&gt;(std::forward&lt;P&gt;(p))));
</ins></pre></blockquote>
</blockquote>
</blockquote>
</li>

<li><p>Edit 20.2.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> p17:</p>
<blockquote>
<pre>
  template&lt;class T, class Alloc, class U&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, U&amp;&amp; u) noexcept;
</pre>
<blockquote>
<p>
-16- Let <tt><i>FUN</i></tt> be the function template:
</p>
<blockquote><pre>
  template&lt;class A, class B&gt;
  void <i>FUN</i>(const pair&lt;A, B&gt;&amp;);
</pre></blockquote>
<p>
-17- <i>Constraints:</i> <tt>remove_cv_t&lt;T&gt;</tt> is a specialization of <tt>pair</tt>, <ins>and either:</ins>
</p>
<ol style="list-style-type: none">
<li><p><ins>(17.1) &mdash; <tt>remove_cvref_t&lt;U&gt;</tt> is a specialization of <tt>ranges::subrange</tt>, or</ins></p></li>
<li><p><ins>(17.2) &mdash; <tt>U</tt> does not satisfy <i><tt>pair-like</tt></i></ins>
and the expression <tt><i>FUN</i>(u)</tt> is not well-formed when considered as an unevaluated operand..</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3834" href="https://cplusplus.github.io/LWG/lwg-active.html#3834">3834</a>. Missing <tt>constexpr</tt> for <tt>std::intmax_t</tt> math functions in <tt>&lt;cinttypes&gt;</tt></h3>
<p><b>Section:</b> 31.13.2 <a href="https://wg21.link/cinttypes.syn">[cinttypes.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> George Tokmaji <b>Opened:</b> 2022-11-27 <b>Last modified:</b> 2023-01-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P0533R9">P0533R9</a> adds <tt>constexpr</tt> to math functions in <tt>&lt;cmath&gt;</tt> 
and <tt>&lt;cstdlib&gt;</tt>, which includes <tt>std::abs</tt> and <tt>std::div</tt>. This 
misses the overloads for <tt>std::intmax_t</tt> in <tt>&lt;cinttypes&gt;</tt>, as well as 
<tt>std::imaxabs</tt> and <tt>std::imaxdiv</tt>, which seems like an oversight.
</p>

<p><i>[2023-01-06; Reflector poll]</i></p>

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



<p id="res-3834"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

<blockquote>
<blockquote><pre>
[&hellip;]
namespace std {
  using imaxdiv_t = <i>see below</i>;
  
  <ins>constexpr</ins> intmax_t imaxabs(intmax_t j);
  <ins>constexpr</ins> imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
  intmax_t strtoimax(const char* nptr, char** endptr, int base);
  uintmax_t strtoumax(const char* nptr, char** endptr, int base);
  intmax_t wcstoimax(const wchar_t* nptr, wchar_t** endptr, int base);
  uintmax_t wcstoumax(const wchar_t* nptr, wchar_t** endptr, int base);

  <ins>constexpr</ins> intmax_t abs(intmax_t);            // <i>optional, see below</i>
  <ins>constexpr</ins> imaxdiv_t div(intmax_t, intmax_t); // <i>optional, see below</i>
  [&hellip;]
}
[&hellip;]
</pre></blockquote>
<p>
-1- The contents and meaning of the header <tt>&lt;cinttypes&gt;</tt> are the same as the C standard library header
<tt>&lt;inttypes.h&gt;</tt>, with the following changes:
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; The header <tt>&lt;cinttypes&gt;</tt> includes the header <tt>&lt;cstdint&gt;</tt> 
(17.4.1 <a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a>) instead of <tt>&lt;stdint.h&gt;</tt>, and</p></li>
<li><p>(1.2) &mdash; if and only if the type <tt>intmax_t</tt> designates an extended integer type 
(6.8.2 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a>), the following function signatures are added:</p>
<blockquote><pre>
<ins>constexpr</ins> intmax_t abs(intmax_t);
<ins>constexpr</ins> imaxdiv_t div(intmax_t, intmax_t);
</pre></blockquote>
<p>which shall have the same semantics as the function signatures 
<tt><ins>constexpr</ins> intmax_t imaxabs(intmax_t)</tt> and
<tt><ins>constexpr</ins> imaxdiv_t imaxdiv(intmax_t, intmax_t)</tt>, respectively.</p></li>
</ol>

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






<hr>
<h3><a name="3839" href="https://cplusplus.github.io/LWG/lwg-active.html#3839">3839</a>. <tt>range_formatter</tt>'s <tt>set_separator</tt>, <tt>set_brackets</tt>, and <tt>underlying</tt> functions should be <tt>noexcept</tt></h3>
<p><b>Section:</b> 22.14.7.2 <a href="https://wg21.link/format.range.formatter">[format.range.formatter]</a>, 22.14.7.3 <a href="https://wg21.link/format.range.fmtdef">[format.range.fmtdef]</a>, 22.14.9 <a href="https://wg21.link/format.tuple">[format.tuple]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2022-12-11 <b>Last modified:</b> 2023-01-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The <tt>set_separator</tt> and <tt>set_brackets</tt> of <tt>range_formatter</tt> only invoke 
<tt>basic_string_view</tt>'s assignment operator, which is <tt>noexcept</tt>, we should add <tt>noexcept</tt> 
specifications for them.
<p/>
In addition, its <tt>underlying</tt> function returns a reference to the underlying <tt>formatter</tt>, 
which never throws, they should also be <tt>noexcept</tt>.
<p/>
Similar rules apply to <tt><i>range-default-formatter</i></tt> and <tt>formatter</tt>'s <tt>tuple</tt> specialization.
</p>

<p><i>[2023-01-06; Reflector poll]</i></p>

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



<p id="res-3839"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;class T, class charT = char&gt;
    requires same_as&lt;remove_cvref_t&lt;T&gt;, T&gt; &amp;&amp; formattable&lt;T, charT&gt;
  class range_formatter {
    formatter&lt;T, charT&gt; <i>underlying_</i>;                                          // <i>exposition only</i>
    basic_string_view&lt;charT> <i>separator_</i> = <i>STATICALLY-WIDEN</i>&lt;charT&gt;(", ");      // <i>exposition only</i>
    basic_string_view&lt;charT> <i>opening-bracket_</i> = <i>STATICALLY-WIDEN</i>&lt;charT&gt;("["); // <i>exposition only</i>
    basic_string_view&lt;charT> <i>closing-bracket_</i> = <i>STATICALLY-WIDEN</i>&lt;charT&gt;("]"); // <i>exposition only</i>

  public:
    constexpr void set_separator(basic_string_view&lt;charT&gt; sep) <ins>noexcept</ins>;
    constexpr void set_brackets(basic_string_view&lt;charT&gt; opening,
                                basic_string_view&lt;charT&gt; closing) <ins>noexcept</ins>;
    constexpr formatter&lt;T, charT&gt;&amp; underlying() <ins>noexcept</ins> { return <i>underlying_</i>; }
    constexpr const formatter&lt;T, charT&gt;&amp; underlying() const <ins>noexcept</ins> { return <i>underlying_</i>; }

    [&hellip;]
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
constexpr void set_separator(basic_string_view&lt;charT&gt; sep) <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-7- <i>Effects:</i> Equivalent to: <tt><i>separator_</i> = sep;</tt>
</p>
</blockquote>
<pre>
constexpr void set_brackets(basic_string_view&lt;charT&gt; opening, basic_string_view&lt;charT&gt; closing) <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-8- <i>Effects:</i> Equivalent to:
<pre>
<i>opening-bracket_</i> = opening;
<i>closing-bracket_</i> = closing;
</pre>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 22.14.7.3 <a href="https://wg21.link/format.range.fmtdef">[format.range.fmtdef]</a> as indicated:</p>
  
<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;ranges::input_range R, class charT&gt;
  struct <i>range-default-formatter</i>&lt;range_format::sequence, R, charT&gt; {    // <i>exposition only</i>
  private:
    using <i>maybe-const-r</i> = <i>fmt-maybe-const</i>&lt;R, charT&gt;;                    // <i>exposition only</i>
    range_formatter&lt;remove_cvref_t&lt;ranges::range_reference_t&lt;<i>maybe-const-r</i>&gt;&gt;,
                    charT&gt; <i>underlying_</i>;                                 // <i>exposition only</i>

  public:
    constexpr void set_separator(basic_string_view&lt;charT&gt; sep) <ins>noexcept</ins>;
    constexpr void set_brackets(basic_string_view&lt;charT&gt; opening,
                                basic_string_view&lt;charT&gt; closing) <ins>noexcept</ins>;
  
    [&hellip;]
  };
}
</pre>
</blockquote>
<pre>
constexpr void set_separator(basic_string_view&lt;charT&gt; sep) <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to: <tt><i>underlying_</i>.set_separator(sep);</tt>.
</p>
</blockquote>
<pre>
constexpr void set_brackets(basic_string_view&lt;charT&gt; opening, basic_string_view&lt;charT&gt; closing) <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> Equivalent to: <tt><i>underlying_</i>.set_brackets(opening, closing);</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 22.14.9 <a href="https://wg21.link/format.tuple">[format.tuple]</a> as indicated:</p>
<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;class charT, formattable&lt;charT&gt;... Ts&gt;
  struct formatter&lt;<i>pair-or-tuple</i>&lt;Ts...&gt;, charT&gt; {
  private:
    tuple&lt;formatter&lt;remove_cvref_t&lt;Ts&gt;, charT&gt;...&gt; <i>underlying_</i>;               // <i>exposition only</i>
    basic_string_view&lt;charT> <i>separator_</i> = <i>STATICALLY-WIDEN</i>&lt;charT&gt;(", ");      // <i>exposition only</i>
    basic_string_view&lt;charT> <i>opening-bracket_</i> = <i>STATICALLY-WIDEN</i>&lt;charT&gt;("("); // <i>exposition only</i>
    basic_string_view&lt;charT> <i>closing-bracket_</i> = <i>STATICALLY-WIDEN</i>&lt;charT&gt;(")"); // <i>exposition only</i>

  public:
    constexpr void set_separator(basic_string_view&lt;charT&gt; sep) <ins>noexcept</ins>;
    constexpr void set_brackets(basic_string_view&lt;charT&gt; opening,
                                basic_string_view&lt;charT&gt; closing) <ins>noexcept</ins>;

    [&hellip;]
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
constexpr void set_separator(basic_string_view&lt;charT&gt; sep) <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Equivalent to: <tt><i>separator_</i> = sep;</tt>
</p>
</blockquote>
<pre>
constexpr void set_brackets(basic_string_view&lt;charT&gt; opening, basic_string_view&lt;charT&gt; closing) <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> Equivalent to:
<pre>
<i>opening-bracket_</i> = opening;
<i>closing-bracket_</i> = closing;
</pre>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3841" href="https://cplusplus.github.io/LWG/lwg-active.html#3841">3841</a>. <tt>&lt;version&gt;</tt> should not be "<i>all freestanding</i>"</h3>
<p><b>Section:</b> 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2022-12-14 <b>Last modified:</b> 2023-01-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#version.syn">active issues</a> in [version.syn].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#version.syn">issues</a> in [version.syn].</p>
<p><b>Discussion:</b></p>
<p>
It's reasonable for the <tt>&lt;version&gt;</tt> header to be required for freestanding, 
so that users can include it and see the "implementation-dependent information &hellip; 
(e.g. version number and release date)", and also to ask which features are present 
(which is the real intended purpose of <tt>&lt;version&gt;</tt>). 
It seems less reasonable to require every macro to be present on freestanding implementations, 
even the ones that correspond to non-freestanding features.
<p/>
<a href="https://wg21.link/P2198R7">P2198R7</a> will fix this situation for C++26, but we should also do something for 
C++23 before publishing it. 
It seems sensible not to require any of the macros to be present, and then allow implementations 
to define them for the features that they support.
</p>

<p><i>[2023-01-06; Reflector poll]</i></p>

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



<p id="res-3841"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

<blockquote>
<p>
-2- Each of the macros defined in <tt>&lt;version&gt;</tt> is also defined after inclusion of any member 
of the set of library headers indicated in the corresponding comment in this synopsis.
<p/>
[<i>Note 1</i>: Future revisions of C++ might replace the values of these macros with greater values. &mdash; <i>end note</i>]
</p>
<blockquote><pre>
<del><i>// all freestanding</i></del>
#define __cpp_lib_addressof_constexpr          201603L // also in &lt;memory&gt;
[&hellip;]
</pre></blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3842" href="https://cplusplus.github.io/LWG/lwg-active.html#3842">3842</a>. Unclear wording for <i>precision</i> in <i>chrono-format-spec</i></h3>
<p><b>Section:</b> 29.12 <a href="https://wg21.link/time.format">[time.format]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2022-12-14 <b>Last modified:</b> 2023-01-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#time.format">active issues</a> in [time.format].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#time.format">issues</a> in [time.format].</p>
<p><b>Discussion:</b></p>
<p>
29.12 <a href="https://wg21.link/time.format">[time.format]</a> says:
</p>
<blockquote><p>
[&hellip;] Giving a <i>precision</i> specification in the <i>chrono-format-spec</i> is valid only for 
<tt>std::chrono::duration</tt> types where the representation type
<tt>Rep</tt> is a floating-point type. 
For all other <tt>Rep</tt> types, an exception of type <tt>format_error</tt> is thrown if the 
<i>chrono-format-spec</i> contains a <i>precision</i> specification. [&hellip;]
</p></blockquote>
<p>
It's unclear whether the restriction in the first sentence applies to all types, or only duration types. 
The second sentence seems to restrict the exceptional case to only types with a non-floating-point <tt>Rep</tt>, 
but what about types with no <tt>Rep</tt> type at all?
<p/>
Can you use a precision with <tt>sys_time&lt;duration&lt;float&gt;&gt;</tt>? That is not a <tt>duration</tt> type at all, 
so does the restriction apply? What about <tt>hh_mm_ss&lt;duration&lt;int&gt;&gt;</tt>? That's not a 
<tt>duration</tt> type, but it uses one, and its <tt>Rep</tt> is not a floating-point type. 
What about <tt>sys_info</tt>? That's not a <tt>duration</tt> and doesn't have any associated <tt>duration</tt>, 
or <tt>Rep</tt> type.
<p/>
What is the intention here?
<p/>
Less importantly, I don't like the use of <tt>Rep</tt> here. That's the template parameter of the 
<tt>duration</tt> class template, but that name isn't in scope here. Why aren't we talking about the 
<tt>duration</tt> type's <tt>rep</tt> type, which is the public name for it? Or about a concrete 
specialization <tt>duration&lt;Rep, Period&gt;</tt>, instead of the class template?
<p/>
The suggested change below would preserve the intended meaning, but with more &hellip; <i>precision</i>.
</p>

<p><i>[2023-01-06; Reflector poll]</i></p>

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



<p id="res-3842"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

<blockquote>
<p>
-1- [&hellip;]
<p/>
The productions <i>fill-and-align</i>, <i>width</i>, and <i>precision</i> are described in 22.14.2 <a href="https://wg21.link/format.string">[format.string]</a>. 
Giving a <i>precision</i> specification in the <i>chrono-format-spec</i> is valid only for 
<ins>types that are specializations of</ins> <tt>std::chrono::duration</tt> <del>types where the representation type
<tt>Rep</tt> is</del><ins>for which the nested <i>typedef-name</i> <tt>rep</tt> denotes</ins> a floating-point type. 
For all other <del><tt>Rep</tt></del> types, an exception of type <tt>format_error</tt> is thrown if the 
<i>chrono-format-spec</i> contains a <i>precision</i> specification. [&hellip;]

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






<hr>
<h3><a name="3848" href="https://cplusplus.github.io/LWG/lwg-active.html#3848">3848</a>. <tt>adjacent_view</tt>, <tt>adjacent_transform_view</tt> and <tt>slide_view</tt> missing <tt>base</tt> accessor</h3>
<p><b>Section:</b> 26.7.25.2 <a href="https://wg21.link/range.adjacent.view">[range.adjacent.view]</a>, 26.7.26.2 <a href="https://wg21.link/range.adjacent.transform.view">[range.adjacent.transform.view]</a>, 26.7.28.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">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-01-06 <b>Last modified:</b> 2023-02-01</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
Like most range adaptors, these three views accept a single range
and store it as a member variable. 
However, they do not provide a <tt>base()</tt> member function for accessing
the underlying range, which seems like an oversight.
</p>

<p><i>[2023-02-01; Reflector poll]</i></p>

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



<p id="res-3848"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

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

    <ins>constexpr V base() const &amp; requires copy_constructible&lt;V&gt; { return <i>base_</i>; }</ins>
    <ins>constexpr V base() &amp;&amp; { return std::move(<i>base_</i>); }</ins>
    [&hellip;]
  };
}
</pre>
</blockquote>
</blockquote>
</li>
<li><p>Modify 26.7.26.2 <a href="https://wg21.link/range.adjacent.transform.view">[range.adjacent.transform.view]</a> as indicated:</p>
<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;forward_range V, move_constructible F, size_t N&gt;
    requires view&lt;V&gt; &amp;&amp; (N &gt; 0) &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
             regular_invocable&lt;F&amp;, <i>REPEAT</i>(range_reference_t&lt;V&gt;, N)...&gt; &amp;&amp;
             <i>can-reference</i>&lt;invoke_result_t&lt;F&amp;, <i>REPEAT</i>(range_reference_t&lt;V&gt;, N)...&gt;&gt;
  class adjacent_transform_view : public view_interface&lt;adjacent_transform_view&lt;V, F, N&gt;&gt; {
    <i>movable-box</i>&lt;F&gt; <i>fun_</i>;                        <i>// exposition only</i>
    adjacent_view&lt;V, N&gt; <i>inner_</i>;                 <i>// exposition only</i>

    using <i>InnerView</i> = adjacent_view&lt;V, N&gt;;      <i>// exposition only</i>
    [&hellip;]
  public:
    adjacent_transform_view() = default;
    constexpr explicit adjacent_transform_view(V base, F fun);

    <ins>constexpr V base() const &amp; requires copy_constructible&lt;<i>InnerView</i>&gt; { return <i>inner_</i>.base(); }</ins>
    <ins>constexpr V base() &amp;&amp; { return std::move(<i>inner_</i>).base(); }</ins>
    [&hellip;]
  };
}
</pre>
</blockquote>
</blockquote>
</li>
<li><p>Modify 26.7.28.2 <a href="https://wg21.link/range.slide.view">[range.slide.view]</a> as indicated:</p>

<blockquote>
<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>;                            <i>// exposition only</i>
    range_difference_t&lt;V&gt; <i>n_</i>;           <i>// exposition only</i>
    [&hellip;]
  public:
    constexpr explicit slide_view(V base, range_difference_t&lt;V&gt; n);

    <ins>constexpr V base() const &amp; requires copy_constructible&lt;V&gt; { return <i>base_</i>; }</ins>
    <ins>constexpr V base() &amp;&amp; { return std::move(<i>base_</i>); }</ins>
    [&hellip;]
  };
  [&hellip;]
}
</pre>
  </blockquote>
  </blockquote>
  </li>

</ol>





<hr>
<h3><a name="3849" href="https://cplusplus.github.io/LWG/lwg-active.html#3849">3849</a>. <tt>cartesian_product_view::<i>iterator</i></tt>'s default constructor is overconstrained</h3>
<p><b>Section:</b> 99 [ranges.cartesian.iterator] <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-01-06 <b>Last modified:</b> 2023-02-01</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#ranges.cartesian.iterator">active issues</a> in [ranges.cartesian.iterator].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#ranges.cartesian.iterator">issues</a> in [ranges.cartesian.iterator].</p>
<p><b>Discussion:</b></p>
<p>
Currently, <tt>cartesian_product_view::<i>iterator</i></tt> only provides
the default constructor when the first range models <tt>forward_range</tt>,
which seems too restrictive since several input iterators like
<tt>istream_iterator</tt> are still default-constructible.
</p>
<p>
It would be more appropriate to constrain the default constructor
only by whether the underlying iterator satisfies
<tt>default_initializable</tt>, as most other range adaptors do.
Since <tt>cartesian_product_view::<i>iterator</i></tt> contains
a <tt>tuple</tt> member that already has a constrained default constructor,
the proposed resolution simply removes the constraint.
</p>

<p><i>[2023-02-01; Reflector poll]</i></p>

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



<p id="res-3849"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>
<li><p>Modify 99 [ranges.cartesian.iterator] as indicated:</p>
<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range First, forward_range... Vs&gt;
    requires (view&lt;First&gt; &amp;&amp; ... &amp;&amp; view&lt;Vs&gt;)
  template&lt;bool Const&gt;
  class cartesian_product_view&lt;First, Vs...&gt;::<i>iterator</i> {
  public:
    [&hellip;]
    iterator() <del>requires forward_range&lt;<i>maybe-const</i>&lt;Const, First&gt;&gt;</del> = default;
    [&hellip;]
  private:
    using Parent = <i>maybe-const</i>&lt;Const, cartesian_product_view&gt;;          <i>// exposition only</i>
    Parent* <i>parent_</i> = nullptr;                                          <i>// exposition only</i>
    tuple&lt;iterator_t&lt;<i>maybe-const</i>&lt;Const, First&gt;&gt;,
      iterator_t&lt;<i>maybe-const</i>&lt;Const, Vs&gt;&gt;...&gt; <i>current_</i>;                  <i>// exposition only</i>
    [&hellip;]
  };
}
</pre>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3850" href="https://cplusplus.github.io/LWG/lwg-active.html#3850">3850</a>. <tt>views::as_const</tt> on <tt>empty_view&lt;T&gt;</tt> should return <tt>empty_view&lt;const T&gt;</tt></h3>
<p><b>Section:</b> 26.7.21.1 <a href="https://wg21.link/range.as.const.overview">[range.as.const.overview]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-01-06 <b>Last modified:</b> 2023-02-01</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.as.const.overview">active issues</a> in [range.as.const.overview].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.as.const.overview">issues</a> in [range.as.const.overview].</p>
<p><b>Discussion:</b></p>
<p>
Currently, applying <tt>views::as_const</tt> to an <tt>empty_view&lt;int&gt;</tt>
will result in an <tt>as_const_view&lt;empty_view&lt;int&gt;&gt;</tt>,
and its iterator type will be <tt>basic_const_iterator&lt;int*&gt;</tt>.
</p>
<p>
This amount of instantiation is not desirable for such a simple view,
in which case simply returning <tt>empty_view&lt;const int&gt;</tt> should be enough.
</p>

<p><i>[2023-02-01; Reflector poll]</i></p>

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



<p id="res-3850"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

<blockquote>
<p>
-2- The name <tt>views::as_const</tt> denotes a range adaptor object (26.7.2 <a href="https://wg21.link/range.adaptor.object">[range.adaptor.object]</a>). 
Let <tt>E</tt> be an expression, let <tt>T</tt> be <tt>decltype((E))</tt>, and let <tt>U</tt> be 
<tt>remove_cvref_t&lt;T&gt;</tt>. The expression <tt>views::as_const(E)</tt> is expression-equivalent
to:
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; If <tt>views::all_t&lt;T&gt;</tt> models <tt>constant_range</tt>, then <tt>views::all(E)</tt>.</p></li>
<li><p><ins>(2.?) &mdash; Otherwise, if <tt>U</tt> denotes <tt>empty_view&lt;X&gt;</tt> for some type <tt>X</tt>, then <tt>auto(views::empty&lt;const X&gt;)</tt>.</ins></p></li>
<li><p>(2.2) &mdash; Otherwise, if <tt>U</tt> denotes <tt>span&lt;X, Extent&gt;</tt> for some type <tt>X</tt> and some 
extent <tt>Extent</tt>, then <tt>span&lt;const X, Extent&gt;(E)</tt>.</p></li>
<li><p>(2.3) &mdash; Otherwise, if <tt>E</tt> is an lvalue, <tt>const U</tt> models <tt>constant_range</tt>, and 
<tt>U</tt> does not model <tt>view</tt>, then <tt>ref_view(static_cast&lt;const U&amp;&gt;(E))</tt>.</p></li>
<li><p>(2.4) &mdash; Otherwise, <tt>as_const_view(E)</tt>.</p></li>
</ol>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="3851" href="https://cplusplus.github.io/LWG/lwg-active.html#3851">3851</a>. <tt>chunk_view::<i>inner-iterator</i></tt> missing custom <tt>iter_move</tt> and <tt>iter_swap</tt></h3>
<p><b>Section:</b> 26.7.27.5 <a href="https://wg21.link/range.chunk.inner.iter">[range.chunk.inner.iter]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-01-06 <b>Last modified:</b> 2023-02-01</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
For the input version of <tt>chunk_view</tt>,
its <tt><i>inner-iterator</i>::operator*()</tt> simply 
dereferences the underlying input iterator.
However, there are no customized <tt>iter_move</tt> and <tt>iter_swap</tt>
overloads for the <tt><i>inner-iterator</i></tt>,
which prevents customized behavior when applying <tt>views::chunk</tt>
to a range whose iterator type is a proxy iterator,
<a href="https://godbolt.org/z/ETh5o6GYj">for example</a>:
</p>
<pre>
    #include &lt;algorithm&gt;
    #include &lt;cassert&gt;
    #include &lt;ranges&gt;
    #include &lt;sstream&gt;
    #include &lt;vector&gt;

    int main() {
      auto ints = std::istringstream{"0 1 2 3 4"};
      std::vector&lt;std::string&gt; vs{"the", "quick", "brown", "fox"};
      auto r = std::views::zip(vs, std::views::istream&lt;int&gt;(ints))
              | std::views::chunk(2)
              | std::views::join;
      std::vector&lt;std::tuple&lt;std::string, int&gt;&gt; res;
      std::ranges::copy(std::move_iterator(r.begin()), std::move_sentinel(r.end()), 
                        std::back_inserter(res));
      assert(vs.front().empty()); // <span style="color:red;font-weight:bolder">assertion failed</span>
    }
</pre>
<p>
<tt>zip</tt> iterator has a customized <tt>iter_move</tt> behavior,
but since there is no <tt>iter_move</tt> specialization for
<tt><i>inner-iterator</i></tt>,
when we try to move elements in <tt>chunk_view</tt>,
<tt>move_iterator</tt> will fallback to use the default implementation of
<tt>iter_move</tt>, making <tt>string</tt>s not moved as expected
from the original <tt>vector</tt> but copied instead.
</p>

<p><i>[2023-02-01; Reflector poll]</i></p>

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



<p id="res-3851"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>
<li><p>Modify 26.7.27.5 <a href="https://wg21.link/range.chunk.inner.iter">[range.chunk.inner.iter]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;view V&gt;
    requires input_range&lt;V&gt;
  class chunk_view&lt;V&gt;::<i>inner-iterator</i> {
    chunk_view* <i>parent_</i>;                                                <i>// exposition only</i>

    constexpr explicit <i>inner-iterator</i>(chunk_view&amp; parent) noexcept;     <i>// exposition only</i>

  public:
    [&hellip;]
    friend constexpr difference_type operator-(default_sentinel_t y, const <i>inner-iterator</i>&amp; x)
      requires sized_sentinel_for&lt;sentinel_t&lt;V&gt;, iterator_t&lt;V&gt;&gt;;
    friend constexpr difference_type operator-(const <i>inner-iterator</i>&amp; x, default_sentinel_t y)
      requires sized_sentinel_for&lt;sentinel_t&lt;V&gt;, iterator_t&lt;V&gt;&gt;;

<ins>    friend constexpr range_rvalue_reference_t&lt;V&gt; iter_move(const <i>inner-iterator</i>&amp; i)
      noexcept(noexcept(ranges::iter_move(*i.<i>parent_</i>-><i>current_</i>)));

    friend constexpr void iter_swap(const <i>inner-iterator</i>&amp; x, const <i>inner-iterator</i>&amp; y)
      noexcept(noexcept(ranges::iter_swap(*x.<i>parent_</i>-><i>current_</i>, *y.<i>parent_</i>-><i>current_</i>)))
      requires indirectly_swappable&lt;iterator_t&lt;V&gt;&gt;;</ins>
  };
}
</pre>
</blockquote>
[&hellip;]
<pre><ins>friend constexpr range_rvalue_reference_t&lt;V&gt; iter_move(const <i>inner-iterator</i>&amp; i)
  noexcept(noexcept(ranges::iter_move(*i.<i>parent_</i>-><i>current_</i>)));</ins>
</pre>
<blockquote>
<p>
<ins>
-?- <i>Effects:</i> Equivalent to: <tt>return ranges::iter_move(*i.<i>parent_</i>-><i>current_</i>);</tt>
</ins>
</p>
</blockquote>
<pre><ins>friend constexpr void iter_swap(const <i>inner-iterator</i>&amp; x, const <i>inner-iterator</i>&amp; y)
  noexcept(noexcept(ranges::iter_swap(*x.<i>parent_</i>-><i>current_</i>, *y.<i>parent_</i>-><i>current_</i>)))
  requires indirectly_swappable&lt;iterator_t&lt;V&gt;&gt;;</ins>
</pre>
<blockquote>
<p>
<ins>
-?- <i>Effects:</i> Equivalent to: <tt>ranges::iter_swap(*x.<i>parent_</i>-><i>current_</i>, *y.<i>parent_</i>-><i>current_</i>)</tt>.
</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3853" href="https://cplusplus.github.io/LWG/lwg-active.html#3853">3853</a>. <tt>basic_const_iterator&lt;volatile int*&gt;::operator-&gt;</tt> is ill-formed</h3>
<p><b>Section:</b> 25.5.3 <a href="https://wg21.link/const.iterators">[const.iterators]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-01-06 <b>Last modified:</b> 2023-02-01</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#const.iterators">active issues</a> in [const.iterators].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#const.iterators">issues</a> in [const.iterators].</p>
<p><b>Discussion:</b></p>
<p>
Currently, <tt>basic_const_iterator::operator-&gt;</tt> constrains the value type
of the underlying iterator to be only the <i>cv</i>-unqualified type of its reference type, 
which is true for raw pointers.
</p>
<p>
However, since it also explicitly specifies returning a pointer to a <tt>const</tt> value type,
this will cause a hard error when the value type is actually <tt>volatile</tt>-qualified:
</p>
<blockquote>
<pre>
std::basic_const_iterator&lt;volatile int*&gt; it;
auto* p = it.operator-&gt;(); // <span style="color:red;font-weight:bolder">invalid conversion from 'volatile int*' to 'const int*'</span>
</pre>
</blockquote>
<p>
The proposed resolution changes the return type from <tt>const value_type*</tt>
to <tt>const auto*</tt>,
which makes it deduce the correct type in the above example,
i.e. <tt>const volatile int*</tt>.
</p>

<p><i>[2023-02-01; Reflector poll]</i></p>

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



<p id="res-3853"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

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

<blockquote>
<pre>
namespace std {
  template&lt;class I&gt;
    concept <i>not-a-const-iterator</i> = <i>see below</i>;

  template&lt;input_iterator Iterator&gt;
  class basic_const_iterator {
    Iterator <i>current_</i> = Iterator();                             // <i>exposition only</i>
    using <i>reference</i> = iter_const_reference_t&lt;Iterator&gt;;         // <i>exposition only</i>
  
  public:
    [&hellip;]
    constexpr <i>reference</i> operator*() const;
    constexpr const <ins>auto</ins><del>value_type</del>* operator-&gt;() const
       requires is_lvalue_reference_v&lt;iter_reference_t&lt;Iterator&gt;&gt; &amp;&amp;
                same_as&lt;remove_cvref_t&lt;iter_reference_t&lt;Iterator&gt;&gt;, value_type&gt;;
    [&hellip;]
  };
}
</pre>
[&hellip;]
<pre>
constexpr const <ins>auto</ins><del>value_type</del>* operator-&gt;() const
  requires is_lvalue_reference_v&lt;iter_reference_t&lt;Iterator&gt;&gt; &amp;&amp;
           same_as&lt;remove_cvref_t&lt;iter_reference_t&lt;Iterator&gt;&gt;, value_type&gt;;
</pre>
<p>
-7- <i>Returns</i>: If <tt>Iterator</tt> models <tt>contiguous_iterator</tt>, <tt>to_address(<i>current_</i>)</tt>; otherwise, 
<tt>addressof(*<i>current_</i>)</tt>.
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3857" href="https://cplusplus.github.io/LWG/lwg-active.html#3857">3857</a>. <tt>basic_string_view</tt> should allow explicit conversion when only traits vary</h3>
<p><b>Section:</b> 23.3.3.2 <a href="https://wg21.link/string.view.cons">[string.view.cons]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2023-01-10 <b>Last modified:</b> 2023-02-01</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#string.view.cons">issues</a> in [string.view.cons].</p>
<p><b>Discussion:</b></p>
<p>
<tt>basic_string_view</tt> has a constructor that converts appropriate contiguous ranges to <tt>basic_string_view</tt>. 
This constructor accepts an argument by forwarding reference (<tt>R&amp;&amp;</tt>), and has several constraints 
including that specified in 23.3.3.2 <a href="https://wg21.link/string.view.cons">[string.view.cons]</a>/12.6: 
</p>
<blockquote><p>
if the <i>qualified-id</i> <tt>remove_reference_t&lt;R&gt;::traits_type</tt> is valid and denotes a type, 
<tt>is_same_v&lt;remove_reference_t&lt;R&gt;::traits_type, traits&gt;</tt> is <tt>true</tt>. 
</p></blockquote>
<p>
This constraint prevents conversions from <tt>basic_string_view&lt;C, T1&gt;</tt> and <tt>basic_string&lt;C, T1, A&gt;</tt> 
to <tt>basic_string_view&lt;C, T2&gt;</tt>. Preventing such seemingly semantic-affecting conversions from happening 
implicitly was a good idea, but since the constructor was changed to be explicit it no longer seems necessary to 
forbid these conversions. If a user wants to convert a <tt>basic_string_view&lt;C, T2&gt;</tt> to 
<tt>basic_string_view&lt;C, T1&gt;</tt> with <tt>static_cast&lt;basic_string_view&lt;C, T1&gt;&gt;(meow)</tt>
instead of by writing out <tt>basic_string_view&lt;C, T1&gt;{meow.data(), meow.size()}</tt> that seems fine to me.
Indeed, if we think conversions like this are so terribly dangerous we probably shouldn't be performing them ourselves 
in 22.14.8.1 <a href="https://wg21.link/format.arg">[format.arg]</a>/9 and 22.14.8.1 <a href="https://wg21.link/format.arg">[format.arg]</a>/10.
</p>

<p><i>[2023-02-01; Reflector poll]</i></p>

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



<p id="res-3857"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4917">N4917</a>.
</p>

<ol>
<li><p>Modify 23.3.3.2 <a href="https://wg21.link/string.view.cons">[string.view.cons]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class R&gt;
  constexpr explicit basic_string_view(R&amp;&amp; r);
</pre>
<blockquote>
<p>
-11- Let <tt>d</tt> be an lvalue of type <tt>remove_cvref_t&lt;R&gt;</tt>.
<p/>
-12- <i>Constraints</i>:
</p>
<ol style="list-style-type: none">
<li><p>(12.1) &mdash; <tt>remove_cvref_t&lt;R&gt;</tt> is not the same type as <tt>basic_string_view</tt>,</p></li>
<li><p>(12.2) &mdash; <tt>R</tt> models <tt>ranges::contiguous_range</tt> and <tt>ranges::sized_range</tt>,</p></li>
<li><p>(12.3) &mdash; <tt>is_same_v&lt;ranges::range_value_t&lt;R&gt;, charT&gt;</tt> is <tt>true</tt>,</p></li>
<li><p>(12.4) &mdash; <tt>is_convertible_v&lt;R, const charT*&gt;</tt> is <tt>false</tt>, <ins>and</ins></p></li>
<li><p>(12.5) &mdash; <tt>d.operator ::std::basic_string_view&lt;charT, traits&gt;()</tt> is not a valid expression<del>, and</del><ins>.</ins></p></li>
<li><p><del>(12.6) &mdash; if the <i>qualified-id</i> <tt>remove_reference_t&lt;R&gt;::traits_type</tt> is valid and denotes a type, 
<tt>is_same_v&lt;remove_reference_t&lt;R&gt;::traits_type, traits&gt;</tt> is <tt>true</tt>.</del></p></li>
</ol>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3860" href="https://cplusplus.github.io/LWG/lwg-active.html#3860">3860</a>. <tt>range_common_reference_t</tt> is missing</h3>
<p><b>Section:</b> 26.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-01-24 <b>Last modified:</b> 2023-02-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#ranges.syn">active issues</a> in [ranges.syn].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#ranges.syn">issues</a> in [ranges.syn].</p>
<p><b>Discussion:</b></p>
<p>
For the alias template <tt>iter_<i>meow</i>_t</tt> in <tt>&lt;iterator&gt;</tt>, there are almost all corresponding 
<tt>range_<i>meow</i>_t</tt> in <tt>&lt;ranges&gt;</tt>, except for <tt>iter_common_reference_t</tt>, which is used to 
calculate the common reference type shared by <tt>reference</tt> and <tt>value_type</tt> of the iterator.
<p/>
Given that it has a highly similar formula form to <tt>iter_const_reference_t</tt>, and the latter has a corresponding sibling, 
I think we should add a <tt>range_common_reference_t</tt> for <tt>&lt;ranges&gt;</tt>.
<p/>
This increases the consistency of the two libraries and simplifies the text of getting common reference from a range. 
Since C++23 brings proxy iterators and <tt>tuple</tt> enhancements, I believe such introduction can bring some value.
</p>

<p><i>[2023-02-06; Reflector poll]</i></p>

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



<p id="res-3860"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4928">N4928</a>.
</p>

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

<blockquote>
<pre>
#include &lt;compare&gt;              // <i>see 17.11.1 <a href="https://wg21.link/compare.syn">[compare.syn]</a></i>
#include &lt;initializer_list&gt;     // <i>see 17.10.2 <a href="https://wg21.link/initializer.list.syn">[initializer.list.syn]</a></i>
#include &lt;iterator&gt;             // <i>see 25.2 <a href="https://wg21.link/iterator.synopsis">[iterator.synopsis]</a></i>

namespace std::ranges {
  [&hellip;]
  template&lt;range R&gt;
    using range_reference_t = iter_reference_t&lt;iterator_t&lt;R&gt;&gt;;                      // <i>freestanding</i>
  template&lt;range R&gt;
    using range_const_reference_t = iter_const_reference_t&lt;iterator_t&lt;R&gt;&gt;;          // <i>freestanding</i>
  template&lt;range R&gt;
    using range_rvalue_reference_t = iter_rvalue_reference_t&lt;iterator_t&lt;R&gt;&gt;;        // <i>freestanding</i>
  <ins>template&lt;range R&gt;
    using range_common_reference_t = iter_common_reference_t&lt;iterator_t&lt;R&gt;&gt;;        // <i>freestanding</i></ins>
  [&hellip;]
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3866" href="https://cplusplus.github.io/LWG/lwg-active.html#3866">3866</a>. Bad <i>Mandates</i> for <tt>expected::transform_error</tt> overloads</h3>
<p><b>Section:</b> 22.8.6.7 <a href="https://wg21.link/expected.object.monadic">[expected.object.monadic]</a>, 22.8.7.7 <a href="https://wg21.link/expected.void.monadic">[expected.void.monadic]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2023-01-29 <b>Last modified:</b> 2023-02-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The overloads of <tt>expected::transform_error</tt> mandate that "[type] <tt>G</tt> is a valid value type for <tt>expected</tt>" 
(22.8.6.7 <a href="https://wg21.link/expected.object.monadic">[expected.object.monadic]</a>/27 and 31 as well as 22.8.7.7 <a href="https://wg21.link/expected.void.monadic">[expected.void.monadic]</a>/24 and 27)). 
<p/>
All of these overloads then instantiate <tt>expected&lt;T, G&gt;</tt> (for some type <tt>T</tt>) which doesn't require 
<tt>G</tt> to be a valid value type for <tt>expected</tt> (22.8.6.1 <a href="https://wg21.link/expected.object.general">[expected.object.general]</a>/2) but instead requires 
that <tt>G</tt> is "a valid template argument for <tt>unexpected</tt>" (22.8.6.1 <a href="https://wg21.link/expected.object.general">[expected.object.general]</a>/2). 
Comparing 22.8.6.1 <a href="https://wg21.link/expected.object.general">[expected.object.general]</a>/2 with 22.8.3.1 <a href="https://wg21.link/expected.un.general">[expected.un.general]</a>/2 it's clear that there are 
types &mdash; <tt>const int</tt>, for example &mdash; which are valid value types for <tt>expected</tt> but not valid 
template arguments for <tt>unexpected</tt>. Presumably this unimplementable requirement is a typo, and the subject 
paragraphs intended to require that <tt>G</tt> be a valid template argument for <tt>unexpected</tt>. 
</p>

<p><i>[2023-02-06; Reflector poll]</i></p>

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



<p id="res-3866"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4928">N4928</a>.
</p>

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

<blockquote>
<pre>
template&lt;class F&gt; constexpr auto transform_error(F&amp;&amp; f) &amp;;
template&lt;class F&gt; constexpr auto transform_error(F&amp;&amp; f) const &amp;;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-27- <i>Mandates</i>: <tt>G</tt> is a valid <del>value type for <tt>expected</tt></del><ins>template argument for 
<tt>unexpected</tt> (22.8.3.1 <a href="https://wg21.link/expected.un.general">[expected.un.general]</a>)</ins> and the declaration
</p>
<blockquote><pre>
G g(invoke(std::forward&lt;F&gt;(f), error()));
</pre></blockquote>
<p>
is well-formed.
<p/>
[&hellip;]
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class F&gt; constexpr auto transform_error(F&amp;&amp; f) &amp;&amp;;
template&lt;class F&gt; constexpr auto transform_error(F&amp;&amp; f) const &amp;&amp;;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-31- <i>Mandates</i>: <tt>G</tt> is a valid <del>value type for <tt>expected</tt></del><ins>template argument for 
<tt>unexpected</tt> (22.8.3.1 <a href="https://wg21.link/expected.un.general">[expected.un.general]</a>)</ins> and the declaration
</p>
<blockquote><pre>
G g(invoke(std::forward&lt;F&gt;(f), std::move(error())));
</pre></blockquote>
<p>
is well-formed.
<p/>
[&hellip;]
</p>
</blockquote>

</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;class F&gt; constexpr auto transform_error(F&amp;&amp; f) &amp;;
template&lt;class F&gt; constexpr auto transform_error(F&amp;&amp; f) const &amp;;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-24- <i>Mandates</i>: <tt>G</tt> is a valid <del>value type for <tt>expected</tt></del><ins>template argument for 
<tt>unexpected</tt> (22.8.3.1 <a href="https://wg21.link/expected.un.general">[expected.un.general]</a>)</ins> and the declaration
</p>
<blockquote><pre>
G g(invoke(std::forward&lt;F&gt;(f), error()));
</pre></blockquote>
<p>
is well-formed.
<p/>
[&hellip;]
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class F&gt; constexpr auto transform_error(F&amp;&amp; f) &amp;&amp;;
template&lt;class F&gt; constexpr auto transform_error(F&amp;&amp; f) const &amp;&amp;;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-27- <i>Mandates</i>: <tt>G</tt> is a valid <del>value type for <tt>expected</tt></del><ins>template argument for 
<tt>unexpected</tt> (22.8.3.1 <a href="https://wg21.link/expected.un.general">[expected.un.general]</a>)</ins> and the declaration
</p>
<blockquote><pre>
G g(invoke(std::forward&lt;F&gt;(f), std::move(error())));
</pre></blockquote>
<p>
is well-formed.
<p/>
[&hellip;]
</p>
</blockquote>

</blockquote>
</li>

</ol>




<hr>
<h3><a name="3867" href="https://cplusplus.github.io/LWG/lwg-active.html#3867">3867</a>. Should <tt>std::basic_osyncstream</tt>'s move assignment operator be <tt>noexcept</tt>?</h3>
<p><b>Section:</b> 31.11.3.1 <a href="https://wg21.link/syncstream.osyncstream.overview">[syncstream.osyncstream.overview]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jiang An <b>Opened:</b> 2023-01-29 <b>Last modified:</b> 2023-02-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#syncstream.osyncstream.overview">issues</a> in [syncstream.osyncstream.overview].</p>
<p><b>Discussion:</b></p>
<p>
The synopsis of <tt>std::basic_osyncstream</tt> (31.11.3.1 <a href="https://wg21.link/syncstream.osyncstream.overview">[syncstream.osyncstream.overview]</a>) indicates that it's 
member functions behave as if it hold a <tt>std::basic_syncbuf</tt> as its subobject, and according to 
16.3.3.4 <a href="https://wg21.link/functions.within.classes">[functions.within.classes]</a>, <tt>std::basic_osyncstream</tt>'s move assignment operator should call 
<tt>std::basic_syncbuf</tt>'s move assignment operator.
<p/>
However, currently <tt>std::basic_osyncstream</tt>'s move assignment operator is <tt>noexcept</tt>, while 
<tt>std::basic_syncbuf</tt>'s is not. So when an exception is thrown from move assignment between <tt>std::basic_syncbuf</tt> 
objects, <tt>std::terminate</tt> should be called.
<p/>
It's clarified in LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3498">3498</a> that an exception can escape from <tt>std::basic_syncbuf</tt>'s move 
assignment operator. Is there any reason that an exception shouldn't escape from <tt>std::basic_osyncstream</tt>'s 
move assignment operator? 
</p>

<p><i>[2023-02-06; Reflector poll]</i></p>

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



<p id="res-3867"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4928">N4928</a>.
</p>

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

<blockquote>
<pre>
namespace std {
  template&lt;class charT, class traits = char_traits&lt;charT&gt;, class Allocator = allocator&lt;charT&gt;&gt;
  class basic_osyncstream : public basic_ostream&lt;charT, traits&gt; {
  public:
    [&hellip;]
    using syncbuf_type = basic_syncbuf&lt;charT, traits, Allocator&gt;;
    [&hellip;]
    
    <i>// assignment</i>
    basic_osyncstream&amp; operator=(basic_osyncstream&amp;&amp;) <del>noexcept</del>;

    [&hellip;]
  
  private:
    syncbuf_type sb; <i>// exposition only</i>
  };
}
</pre>
</blockquote>
</li>

</ol>




</body>
</html>
