<!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 Kona, Nov. 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 Kona, Nov. 2023</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P3040R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>2023-11-07</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="2392" href="https://cplusplus.github.io/LWG/lwg-active.html#2392">2392</a>. "character type" is used but not defined</h3>
<p><b>Section:</b> 3.36 <a href="https://wg21.link/defns.ntcts">[defns.ntcts]</a>, 30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a>, 31.2.3 <a href="https://wg21.link/iostreams.limits.pos">[iostreams.limits.pos]</a>, 31.7.6.3.1 <a href="https://wg21.link/ostream.formatted.reqmts">[ostream.formatted.reqmts]</a>, 31.7.6.3.4 <a href="https://wg21.link/ostream.inserters.character">[ostream.inserters.character]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2014-06-01 <b>Last modified:</b> 2023-06-26</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
The term "character type" is used in 3.36 <a href="https://wg21.link/defns.ntcts">[defns.ntcts]</a>, 30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a>,
31.2.3 <a href="https://wg21.link/iostreams.limits.pos">[iostreams.limits.pos]</a>, 31.7.6.3.1 <a href="https://wg21.link/ostream.formatted.reqmts">[ostream.formatted.reqmts]</a>, and
31.7.6.3.4 <a href="https://wg21.link/ostream.inserters.character">[ostream.inserters.character]</a>, but the core language only defines
"narrow character types" (6.8.2 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a>).
<p/>
"wide-character type" is used in D.26 <a href="https://wg21.link/depr.locale.stdcvt">[depr.locale.stdcvt]</a>, but the core
language only defines a "wide-character set" and "wide-character literal".
</p>

<p><i>[2023-06-14; Varna; Daniel comments and provides wording]</i></p>

<p>
Given the resolution of <a href="https://wg21.link/P2314">P2314</a> which had introduced to
6.8.2 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a> p11 a definition of "character type":
</p>
<blockquote><p>
The types <tt>char</tt>, <tt>wchar_t</tt>, <tt>char8_t</tt>, <tt>char16_t</tt>, <tt>char32_t</tt> are collectively
called <i>character types</i>.
</p></blockquote>
<p>
one might feel tempted to have most parts of this issue resolved here, but I think that this
actually is a red herring.
<p/>
First, as Jonathan already pointed out, for two places, 31.7.6.3.1 <a href="https://wg21.link/ostream.formatted.reqmts">[ostream.formatted.reqmts]</a> and
31.7.6.3.4 <a href="https://wg21.link/ostream.inserters.character">[ostream.inserters.character]</a>, this clearly doesn't work, instead it seems as if we 
should replace "character type of the stream" here by "<tt>char_type</tt> of the stream".
<p/>
To me "<tt>char_type</tt> of the stream" sounds a bit odd (we usually refer to <tt>char_type</tt>
in terms of a qualified name such as <tt>X::char_type</tt> instead unless we are specifying
a member of some <tt>X</tt>, where we can omit the qualification) and in the suggested
wording below I'm taking advantage of the already defined term "character container type"
(3.10 <a href="https://wg21.link/defns.character.container">[defns.character.container]</a>) instead, which seems to fit its intended purpose here.
<p/>
Second, on further inspection it turns out that actually only <em>one</em> usage of the
term "character type" seems to be intended to refer to the actual core language meaning (See
the unchanged wording for 30.4.3.3.3 <a href="https://wg21.link/facet.num.put.virtuals">[facet.num.put.virtuals]</a> in the proposed wording
below), all other places quite clearly must refer to the above mentioned
"character container type".
<p/>
For the problem related to the missing definition of "wide-character type" (used two times in
D.26 <a href="https://wg21.link/depr.locale.stdcvt">[depr.locale.stdcvt]</a>) I would like to suggest a less general and less inventive
approach to solve the definition problem here, because it only occurs in an already deprecated
component specification: My suggestion is to simply get rid of that term
by just identifying <tt>Elem</tt> with being one of <tt>wchar_t</tt>, <tt>char16_t</tt>, or, 
<tt>char32_t</tt>. (This result is identical to identifying "wide-character type" with
a "character type that is not a narrow character type (6.8.2 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a>)", but this
seemingly more general definition doesn't provide a real advantage.)
</p>

<p><i>[Varna 2023-06-14; Move to Ready]</i></p>


<p><i>[2023-06-25; Daniel comments]</i></p>

<p>
During the Varna LWG discussions of this issue it had been pointed out that the wording change applied to
D.26.3 <a href="https://wg21.link/depr.locale.stdcvt.req">[depr.locale.stdcvt.req]</a> bullet (1.1) could exclude now the previously allowed support
of narrow character types as a "wide-character" with e.g. a <tt>Maxcode</tt> value of 255. First,
I don't think that the revised wording really forbids this. Second, the originating proposal
<a href="https://wg21.link/N2401">N2401</a> doesn't indicate what the actual intend here was and it seems questionable to
assign LEWG to this issue given that the relevant wording is part of deprecated components, especially
given their current position expressed <a href="https://github.com/cplusplus/papers/issues/1527#issuecomment-1565907454">here</a>
to eliminate the specification of the affected components as suggested by <a href="https://wg21.link/P2871">P2871</a>.
</p>


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

<blockquote class="note">
<p>
[<i>Drafting note:</i> All usages of "character type" in 22.14 <a href="https://wg21.link/format">[format]</a> seem to be without problems.]
</p>
</blockquote>

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> The more general interpretation of "character container type" instead of character type by
the meaning of the core language seems safe here. It seems reasonable that an implementation allows more than
the core language character types, but still could impose additional constraints imposed on them. Even if an implementation
does never intend to support anything beyond <tt>char</tt> and <tt>wchar_t</tt>, the wording below is harmless.
One alternative could be here to use the even more general term "char-like types" from 23.1 <a href="https://wg21.link/strings.general">[strings.general]</a>, 
but I'm unconvinced that this buys us much]
</p>
</blockquote>

<blockquote>
<p>
-6- [&hellip;] A template parameter with name <tt>C</tt> represents the
set of types containing <tt>char</tt>, <tt>wchar_t</tt>, and any other implementation-defined 
character <ins>container</ins> types <ins>(3.10 <a href="https://wg21.link/defns.character.container">[defns.character.container]</a>)</ins> that meet the
requirements for a character on which any of the iostream components can be instantiated. [&hellip;]
</p>
</blockquote>

</li>

<li><p>Keep 30.4.3.3.3 <a href="https://wg21.link/facet.num.put.virtuals">[facet.num.put.virtuals]</a> of <b>Stage 1</b> following p4 <em>unchanged</em>:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The wording here seems to refer to the pure core language wording meaning of a character type.]
</p>
</blockquote>

<blockquote>
<p>
[&hellip;] For conversion from an integral type other than a character type, the function determines the
integral conversion specifier as indicated in Table 110.
</p>
</blockquote>

</li>

<li><p>Modify 31.2.3 <a href="https://wg21.link/iostreams.limits.pos">[iostreams.limits.pos]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> Similar to 30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a> above the more general interpretation of "character container type" 
instead of character type by the meaning of the core language seems safe here. ]
</p>
</blockquote>

<blockquote>
<p>
-3- In the classes of Clause 31, a template parameter with name <tt>charT</tt> represents a member of the set of types
containing <tt>char</tt>, <tt>wchar_t</tt>, and any other implementation-defined character <ins>container</ins> types 
<ins>(3.10 <a href="https://wg21.link/defns.character.container">[defns.character.container]</a>)</ins> that meet the requirements
for a character on which any of the iostream components can be instantiated.
</p>
</blockquote>

</li>

<li><p>Modify 31.7.6.3.1 <a href="https://wg21.link/ostream.formatted.reqmts">[ostream.formatted.reqmts]</a> as indicated:</p>

<blockquote>
<p>
-3- If a formatted output function of a stream <tt>os</tt> determines padding, it does so as follows. Given a <tt>charT</tt>
character sequence <tt>seq</tt> where <tt>charT</tt> is the character <ins>container</ins> type of the stream, [&hellip;]
</p>
</blockquote>

</li>

<li><p>Modify 31.7.6.3.4 <a href="https://wg21.link/ostream.inserters.character">[ostream.inserters.character]</a> as indicated:</p>

<blockquote><pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT, traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; out, charT c);
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT, traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; out, char c);
// specialization
template&lt;class traits&gt;
  basic_ostream&lt;char, traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char, traits&gt;&amp; out, char c);
// signed and unsigned
template&lt;class traits&gt;
  basic_ostream&lt;char, traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char, traits&gt;&amp; out, signed char c);
template&lt;class traits&gt;
  basic_ostream&lt;char, traits&gt;&amp; operator&lt;&lt;(basic_ostream&lt;char, traits&gt;&amp; out, unsigned char c);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Behaves as a formatted output function (31.7.6.3.1 <a href="https://wg21.link/ostream.formatted.reqmts">[ostream.formatted.reqmts]</a>) of <tt>out</tt>. 
Constructs a character sequence <tt>seq</tt>. If <tt>c</tt> has type <tt>char</tt> and the character <ins>container</ins> 
type of the stream is not <tt>char</tt>, then <tt>seq</tt> consists of <tt>out.widen(c)</tt>; otherwise <tt>seq</tt> 
consists of <tt>c</tt>. Determines padding for <tt>seq</tt> as described in 31.7.6.3.1 <a href="https://wg21.link/ostream.formatted.reqmts">[ostream.formatted.reqmts]</a>. 
Inserts <tt>seq</tt> into <tt>out</tt>. Calls <tt>os.width(0)</tt>.
</p>
</blockquote>
</blockquote>

</li>

<li><p>Modify D.26.3 <a href="https://wg21.link/depr.locale.stdcvt.req">[depr.locale.stdcvt.req]</a> as indicated:</p>

<blockquote>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <tt>Elem</tt> is <ins>one of</ins><del>the wide-character type, such as</del> 
<tt>wchar_t</tt>, <tt>char16_t</tt>, or <tt>char32_t</tt>.</p></li>
<li><p>(1.2) &mdash; <tt>Maxcode</tt> is the largest <del>wide-character code</del> 
<ins>value of <tt>Elem</tt> converted to <tt>unsigned long</tt></ins> that the facet will read or 
write without reporting a conversion error.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3203" href="https://cplusplus.github.io/LWG/lwg-active.html#3203">3203</a>. <tt>span</tt> element access invalidation</h3>
<p><b>Section:</b> 24.7.2.2.1 <a href="https://wg21.link/span.overview">[span.overview]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Johel Ernesto Guerrero Pe&ntilde;a <b>Opened:</b> 2019-05-04 <b>Last modified:</b> 2023-06-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#span.overview">active issues</a> in [span.overview].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#span.overview">issues</a> in [span.overview].</p>
<p><b>Discussion:</b></p>
<p>
<tt>span</tt> doesn't explicitly point out when its accessed elements are invalidated like <tt>string_view</tt> 
does in 23.3.3.4 <a href="https://wg21.link/string.view.iterators">[string.view.iterators]</a> p2.
</p>

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


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

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

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

<blockquote>
<p>
-4- <tt>ElementType</tt> is required to be a complete object type that is not an abstract class type.
<p/>
<ins>-?- For a <tt>span s</tt>, any operation that invalidates a pointer in the range 
<tt>[s.data(), s.data() + s.size())</tt> invalidates pointers, iterators, and references other than 
<tt>*this</tt> returned from <tt>s</tt>'s member functions.</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2023-06-13; Varna]</i></p>

<p>
The reference to <a href="https://wg21.link/N4910">N4910</a> 23.3.3.4 <a href="https://wg21.link/string.view.iterators">[string.view.iterators]</a> p2 is located now in
<a href="https://wg21.link/N4950">N4950</a> 23.3.3.1 <a href="https://wg21.link/string.view.template.general">[string.view.template.general]</a> p2 where its says:
</p>
<blockquote><p>
For a <tt>basic_string_view str</tt>, any operation that invalidates a pointer in the range
</p>
<blockquote><pre>
[str.data(), str.data() + str.size())
</pre></blockquote>
<p>
invalidates pointers, iterators, and references returned from <tt>str</tt>'s member functions.
</p></blockquote>
<p>
The group also suggested to adjust 23.3.3.1 <a href="https://wg21.link/string.view.template.general">[string.view.template.general]</a> p2 similarly.
</p>

<p><i>[2023-06-14 Varna; Move to Ready]</i></p>




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

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> The proposed wording also removes the extra code block that previously
defined the range]
</p>
</blockquote>

<blockquote>
<p>
-2- For a <tt>basic_string_view str</tt>, any operation that invalidates a pointer in the range
<tt>[str.data(), str.data() + str.size())</tt> invalidates pointers, iterators, and references 
<ins>to elements of <tt>str</tt></ins><del>returned from <tt>str</tt>'s member functions</del>.
</p>
</blockquote>
</li>

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

<blockquote>
<p>
-4- <tt>ElementType</tt> is required to be a complete object type that is not an abstract class type.
<p/>
<ins>-?- For a <tt>span s</tt>, any operation that invalidates a pointer in the range 
<tt>[s.data(), s.data() + s.size())</tt> invalidates pointers, iterators, and references to elements 
of <tt>s</tt>.</ins>
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3305" href="https://cplusplus.github.io/LWG/lwg-active.html#3305">3305</a>. <tt>any_cast&lt;void&gt;</tt></h3>
<p><b>Section:</b> 22.7.5 <a href="https://wg21.link/any.nonmembers">[any.nonmembers]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> John Shaw <b>Opened:</b> 2019-10-16 <b>Last modified:</b> 2023-06-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#any.nonmembers">active issues</a> in [any.nonmembers].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#any.nonmembers">issues</a> in [any.nonmembers].</p>
<p><b>Discussion:</b></p>
<blockquote><pre>
any foo;
void* p = any_cast&lt;void&gt;(&amp;foo);
</pre></blockquote>
<p>
Per 22.7.5 <a href="https://wg21.link/any.nonmembers">[any.nonmembers]</a>/9, since the operand isn't <tt>nullptr</tt> and 
<tt>operand-&gt;type() == typeid(T)</tt> (because <tt>T = void</tt> in this case), we should 
return a pointer to the object contained by <tt>operand</tt>. But there is no such object.
<p/>
We need to handle the <tt>T = void</tt> case, probably by just explicitly returning <tt>nullptr</tt>.
</p>

<p><i>[2019-11 Priority to 2 during Monday issue prioritization in Belfast. There is implementation divergence here.]</i></p>

<p><i>[2020-02 LWG discussion in Prague did not reach consensus. Status to Open.]</i></p>

<p>There was discussion about whether or not <tt>any_cast&lt;void&gt;(a)</tt> should be ill-formed, or return <tt>nullptr</tt>.</p>
<p>Poll "should it return nullptr" was 0-4-5-5-1.</p>
<p><i>[2022-02 Currently ill-formed in MSVC ("error C2338: std::any cannot contain void") and returns null pointer in libstdc++ and libc++.]</i></p>

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

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

<ol>
<li><p>Modify 22.7.5 <a href="https://wg21.link/any.nonmembers">[any.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt;
  const T* any_cast(const any* operand) noexcept;
template&lt;class T&gt;
  T* any_cast(any* operand) noexcept;
</pre>
<blockquote>
<p>
-9- <i>Returns:</i> If <tt>operand != nullptr &amp;&amp; operand-&gt;type() == typeid(T) <ins>&amp;&amp; 
is_object_v&lt;T&gt;</ins></tt>, a pointer to the object contained by <tt>operand</tt>; otherwise, 
<tt>nullptr</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>

</blockquote>

<p><i>[2023-06-14 Varna; Jonathan provides improved wording]</i></p>

<p><i>[2023-06-14 Varna; Move to Ready]</i></p>

<p>Poll: 7-0-1</p>



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

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

<ol>
<li><p>Modify 22.7.5 <a href="https://wg21.link/any.nonmembers">[any.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt;
  const T* any_cast(const any* operand) noexcept;
template&lt;class T&gt;
  T* any_cast(any* operand) noexcept;
</pre>
<blockquote>
<p>
<ins>
-8-
<i>Mandates</i>:
<code>is_void_v&lt;T&gt;</code> is <code>false</code>.
</ins>
</p>
<p>
-9-
<i>Returns</i>: If <tt>operand != nullptr &amp;&amp; operand-&gt;type() == typeid(T)</tt> <ins>is <code>true</code></ins>, a pointer to the object contained by <tt>operand</tt>; otherwise,
<tt>nullptr</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3431" href="https://cplusplus.github.io/LWG/lwg-active.html#3431">3431</a>. <tt>&lt;=&gt;</tt> for containers should require <tt>three_way_comparable&lt;T&gt;</tt> instead of <tt>&lt;=&gt;</tt></h3>
<p><b>Section:</b> 24.2.2.4 <a href="https://wg21.link/container.opt.reqmts">[container.opt.reqmts]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-04-17 <b>Last modified:</b> 2023-06-16</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
The precondition for <tt>&lt;=&gt;</tt> on containers is:
<p/>
"Either <tt>&lt;=&gt;</tt> is defined for values of type (possibly <tt>const</tt>) <tt>T</tt>, 
or <tt>&lt;</tt> is defined for values of type (possibly <tt>const</tt>) <tt>T</tt> and 
<tt>&lt;</tt> is a total ordering relationship."
<p/>
I don't think <tt>&lt;=&gt;</tt> is sufficient, because <tt><i>synth-three-way</i></tt> won't 
use <tt>&lt;=&gt;</tt> unless <tt>three_way_comparable&lt;T&gt;</tt> is satisfied, which requires
<tt><i>weakly-equality-comparable-with</i>&lt;T, T&gt;</tt> as well as <tt>&lt;=&gt;</tt>.
<p/>
So to use <tt>&lt;=&gt;</tt> I think the type also requires <tt>==</tt>, or more precisely, it
must satisfy <tt>three_way_comparable</tt>.
<p/>
The problem becomes clearer with the following example:
</p>
<blockquote><pre>
#include &lt;compare&gt;
#include &lt;vector&gt;

struct X
{
  friend std::strong_ordering operator&lt;=&gt;(X, X) { return std::strong_ordering::equal; }
};

std::vector&lt;X&gt; v(1);
std::strong_ordering c = v &lt;=&gt; v;
</pre></blockquote>
<p>
This doesn't compile, because despite <tt>X</tt> meeting the preconditions for <tt>&lt;=&gt;</tt> in 
[tab:container.opt], <tt><i>synth-three-way</i></tt> will return <tt>std::weak_ordering</tt>.
<p/>
Here is another example:
</p>
<blockquote><pre>
#include &lt;compare&gt;
#include &lt;vector&gt;

struct X
{
  friend bool operator&lt;(X, X) { return true; } // <i>The return value is intentional, see below</i>
  friend std::strong_ordering operator&lt;=&gt;(X, X) { return std::strong_ordering::equal; }
};

std::vector&lt;X&gt; v(1);
std::weak_ordering c = v &lt;=&gt; v;
</pre></blockquote>
<p>
This meets the precondition because it defines <tt>&lt;=&gt;</tt>, but the result of <tt>&lt;=&gt;</tt> 
on <tt>vector&lt;X&gt;</tt> will be nonsense, because <tt><i>synth-three-way</i></tt> will use 
<tt>operator&lt;</tt> not <tt>operator&lt;=&gt;</tt> and that defines a broken ordering.
<p/>
So we're stating a precondition which implies "if you do this, you don't get garbage results" and 
then we give garbage results anyway.
<p/>
The proposed resolution is one way to fix that, by tightening the precondition so that it matches 
what <tt><i>synth-three-way</i></tt> actually does.
</p>

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

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

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

<ol>
<li><p>Modify 24.2.2 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a>, Table [tab:container.opt], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 75: Optional container operations [tab:container.opt]</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Operational<br/>semantics</th>
<th align="center">Assertion/note<br/>pre-/post-condition</th>
<th align="center">Complexity</th>
</tr>

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

<tr>
<td>
<tt>a &lt;=&gt; b</tt>
</td>
<td>
<tt><i>synth-three-way-result</i>&lt;value_type&gt;</tt>
</td>
<td>
<tt>lexicographical_compare_three_way(<br/>
a.begin(), a.end(), b.begin(), b.end(),<br/>
<i>synth-three-way</i>)</tt>
</td>
<td>
<i>Preconditions:</i> Either
<del><tt>&lt;=&gt;</tt> is defined for<br/>
values of type (possibly <tt>const</tt>)</del><br/>
<tt>T</tt> <ins>satisfies <tt>three_way_comparable</tt></ins>,<br/>
or <tt>&lt;</tt> is defined for values of type<br/>
(possibly <tt>const</tt>) <tt>T</tt> and<br/> 
<tt>&lt;</tt> is a total ordering relationship.
</td>
<td>
linear
</td>
</tr>

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

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

<p><i>[2022-04-24; 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>

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

<blockquote>
<pre>
a &lt;=&gt; b
</pre>
<blockquote>
<p>
-2- <i>Result:</i> <tt><i>synth-three-way-result</i>&lt;X::value_type&gt;</tt>.
<p/>
-3- <i>Preconditions:</i> Either <del><tt>&lt;=&gt;</tt> is defined for values of type (possibly <tt>const</tt>)</del> 
<tt>T</tt> <ins>satisfies <tt>three_way_comparable</tt></ins>, or <tt>&lt;</tt> is defined for values of type 
(possibly <tt>const</tt>) <tt>T</tt> and <tt>&lt;</tt> is a total ordering relationship.
<p/>
-4- <i>Returns:</i> <tt>lexicographical_compare_three_way(a.begin(), a.end(), b.begin(), b.end(),
<i>synth-three-way</i>)</tt>
<p/>
[<i>Note 1</i>: The algorithm <tt>lexicographical_compare_three_way</tt> is defined in Clause 27. &mdash; <i>end note</i>]
<p/>
-5- <i>Complexity:</i> Linear.
</p>
</blockquote>
</blockquote>

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

<p><i>[2023-06-13; Varna]</i></p>

<p>
The group liked the previously suggested wording but would prefer to say "models" instead of "satisfies"
in preconditions.
</p>
<p><i>[2023-06-14 Varna; Move to Ready]</i></p>



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

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

<blockquote>
<pre>
a &lt;=&gt; b
</pre>
<blockquote>
<p>
-2- <i>Result:</i> <tt><i>synth-three-way-result</i>&lt;X::value_type&gt;</tt>.
<p/>
-3- <i>Preconditions:</i> Either <del><tt>&lt;=&gt;</tt> is defined for values of type (possibly <tt>const</tt>)</del> 
<tt>T</tt> <ins>models <tt>three_way_comparable</tt></ins>, or <tt>&lt;</tt> is defined for values of type 
(possibly <tt>const</tt>) <tt>T</tt> and <tt>&lt;</tt> is a total ordering relationship.
<p/>
-4- <i>Returns:</i> <tt>lexicographical_compare_three_way(a.begin(), a.end(), b.begin(), b.end(),
<i>synth-three-way</i>)</tt>
<p/>
[<i>Note 1</i>: The algorithm <tt>lexicographical_compare_three_way</tt> is defined in Clause 27. &mdash; <i>end note</i>]
<p/>
-5- <i>Complexity:</i> Linear.
</p>
</blockquote>
</blockquote>

</li>
</ol>




<hr>
<h3><a name="3749" href="https://cplusplus.github.io/LWG/lwg-active.html#3749">3749</a>. <tt>common_iterator</tt> should handle integer-class difference types</h3>
<p><b>Section:</b> 25.5.5 <a href="https://wg21.link/iterators.common">[iterators.common]</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-08-01 <b>Last modified:</b> 2023-06-14</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
The partial specialization of <tt>iterator_traits</tt> for <tt>common_iterator</tt> is defined in 
25.5.5.1 <a href="https://wg21.link/common.iterator">[common.iterator]</a> as
</p>
<pre>
template&lt;input_iterator I, class S&gt;
struct iterator_traits&lt;common_iterator&lt;I, S&gt;&gt; {
  using iterator_concept = <i>see below</i>;
  using iterator_category = <i>see below</i>;
  using value_type = iter_value_t&lt;I&gt;;
  using difference_type = iter_difference_t&lt;I&gt;;
  using pointer = <i>see below</i>;
  using reference = iter_reference_t&lt;I&gt;;
};
</pre>
<p>
where <tt>difference_type</tt> is defined as <tt>iter_difference_t&lt;I&gt;</tt> and <tt>iterator_category</tt> 
is defined as at least <tt>input_iterator_tag</tt>. However, when <tt>difference_type</tt> is an 
integer-class type, <tt>common_iterator</tt> does not satisfy <i>Cpp17InputIterator</i>, which makes 
<tt>iterator_category</tt> incorrectly defined as <tt>input_iterator_tag</tt>.
</p>
<p>
Since the main purpose of <tt>common_iterator</tt> is to be compatible with the legacy iterator system, 
which is reflected in its efforts to try to provide the operations required by C++17 iterators even if 
the underlying iterator does not support it. We should handle this case of difference type incompatibility 
as well.
<p/>
The proposed solution is to provide a C++17 conforming difference type by clamping the integer-class type 
to <tt>ptrdiff_t</tt>.
<p/>
<b>Daniel:</b>
</p>
<blockquote class="note">
<p>
The second part of this issue provides an <em>alternative</em> resolution for the first part of 
LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3748">3748</a> and solves the casting problem mentioned in LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3748">3748</a> as well.
</p>
</blockquote>

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

<p>
Set priority to 2 after reflector poll.
</p>
<p>
"I think <code>common_iterator</code> should <em>reject</em> iterators with
integer-class difference types since it can't possibly achieve the design intent
of adapting them to <i>Cpp17Iterator</i>s."
</p>
<p>
"I'm not yet convinced that we need to outright reject such uses,
but I'm pretty sure that we shouldn't mess with the difference type
and that the PR is in the wrong direction."
</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 25.5.5.1 <a href="https://wg21.link/common.iterator">[common.iterator]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> <tt>common_iterator</tt> requires iterator type <tt>I</tt> must model 
<tt>input_or_output_iterator</tt> which ensures that <tt>iter_difference_t&lt;I&gt;</tt> 
is a signed-integer-like type. The modification of <tt>common_iterator::operator-</tt> is to ensure 
that the pair of <tt>common_iterator&lt;I, S&gt;</tt> models <tt>sized_sentinel_for</tt> when 
<tt>sized_sentinel_for&lt;I, S&gt;</tt> is modeled for iterator type <tt>I</tt> with an 
integer-class difference type and its sentinel type <tt>S</tt>.]
</p>
</blockquote>

<blockquote>
<pre>
namespace std {
  <ins>template&lt;class D&gt;
    requires <i>is-signed-integer-like</i>&lt;D&gt;
  using <i>make-cpp17-diff-t</i> = conditional_t&lt;signed_integral&lt;D&gt;, D, ptrdiff_t&gt;;  <i>// exposition only</i></ins>

  template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S>
    requires (!same_as&lt;I, S&gt; &amp;&amp; copyable&lt;I&gt;)
  class common_iterator {
  public:
    [&hellip;]
    template&lt;sized_sentinel_for&lt;I&gt; I2, sized_sentinel_for&lt;I&gt; S2>
      requires sized_sentinel_for&lt;S, I2&gt;
    friend constexpr <ins><i>make-cpp17-diff-t</i>&lt;</ins>iter_difference_t&lt;I2&gt;<ins>&gt;</ins> operator-(
      const common_iterator&amp; x, const common_iterator&lt;I2, S2&gt;&amp; y);
    [&hellip;]
  };
  
  template&lt;class I, class S&gt;
  struct incrementable_traits&lt;common_iterator&lt;I, S&gt;&gt; {
    using difference_type = <ins><i>make-cpp17-diff-t</i>&lt;</ins>iter_difference_t&lt;I&gt;<ins>&gt;</ins>;
  };

  template&lt;input_iterator I, class S&gt;
  struct iterator_traits&lt;common_iterator&lt;I, S&gt;&gt; {
    using iterator_concept = <i>see below</i>;
    using iterator_category = <i>see below</i>;
    using value_type = iter_value_t&lt;I&gt;;
    using difference_type = <ins><i>make-cpp17-diff-t</i>&lt;</ins>iter_difference_t&lt;I&gt;<ins>&gt;</ins>;
    using pointer = <i>see below</i>;
    using reference = iter_reference_t&lt;I&gt;;
  };
}
</pre>
</blockquote>
</li>

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> If this issue is voted in at the same time as LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3748">3748</a>, the editor
is kindly informed that the changes indicated below supersede those of the before mentioned issues first 
part.]
</p>
</blockquote>

<blockquote>
<pre>
template&lt;sized_sentinel_for&lt;I&gt; I2, sized_sentinel_for&lt;I&gt; S2>
  requires sized_sentinel_for&lt;S, I2&gt;
friend constexpr <ins><i>make-cpp17-diff-t</i>&lt;</ins>iter_difference_t&lt;I2&gt;<ins>&gt;</ins> operator-(
  const common_iterator&amp; x, const common_iterator&lt;I2, S2&gt;&amp; y);
</pre>
<blockquote>
<p>
-5- <i>Preconditions</i>: <tt>x.v_.valueless_by_exception()</tt> and <tt>y.v_.valueless_by_exception()</tt> are 
each <tt>false</tt>.
<p/>
-6- <i>Returns</i>: <tt>0</tt> if <tt><i>i</i></tt> and <tt><i>j</i></tt> are each <tt>1</tt>, and 
otherwise <ins><tt>static_cast&lt;<i>make-cpp17-diff-t</i>&lt;iter_difference_t&lt;I2&gt;&gt;&gt;(</tt></ins><tt>get&lt;<i>i</i>&gt;(x.v_) 
- get&lt;<i>j</i>&gt;(y.v_)</tt><ins><tt>)</tt></ins>, where <tt><i>i</i></tt> is <tt>x.v_.index()</tt> 
and <tt><i>j</i></tt> is <tt>y.v_.index()</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2023-06-13; Varna; Tomasz provides wording]</i></p>

<p><i>[2023-06-14 Varna; Move to Ready]</i></p>



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

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

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

  template&lt;input_iterator I, class S&gt;
  struct iterator_traits&lt;common_iterator&lt;I, S&gt;&gt; {
    using iterator_concept = <i>see below</i>;
    using iterator_category = <i>see below</i>; <ins>// <i>not always present</i></ins>
    using value_type = iter_value_t&lt;I&gt;;
    using difference_type = iter_difference_t&lt;I&gt;;
    using pointer = <i>see below</i>;
    using reference = iter_reference_t&lt;I&gt;;
  };
}
</pre>
</blockquote>
</li>

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

<blockquote>
<p>
<ins>-?- The nested <i>typedef-name</i> <tt>iterator_category</tt> of the specialization of <tt>iterator_traits</tt> for 
<tt>common_iterator&lt;I, S&gt;</tt> is defined if and only if <tt>iter_difference_t&lt;I&gt;</tt> is an integral type. 
In that case, <tt>iterator_category</tt> denotes <tt>forward_iterator_tag</tt> if the <i>qualified-id</i> 
<tt>iterator_traits&lt;I&gt;::iterator_category</tt> is valid and denotes a type that models 
<tt>derived_from&lt;forward_iterator_tag&gt;</tt>; otherwise it denotes <tt>input_iterator_tag</tt>.</ins>
</p>
<p>
-1- The <ins>remaining</ins> nested <i>typedef-name</i>s of the specialization of <tt>iterator_traits</tt> 
for <tt>common_iterator&lt;I, S&gt;</tt> are defined as follows<del>.</del><ins>:</ins>
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <tt>iterator_concept</tt> denotes <tt>forward_iterator_tag</tt> if <tt>I</tt> models 
<tt>forward_iterator</tt>; otherwise it denotes <tt>input_iterator_tag</tt>.</p></li>
<li><p><del>(1.2) &mdash; <tt>iterator_category</tt> denotes 
<tt>forward_iterator_tag</tt> if the <i>qualified-id</i> <tt>iterator_traits&lt;I&gt;::iterator_category</tt> is valid 
and denotes a type that models <tt>derived_from&lt;forward_iterator_tag&gt;</tt>; otherwise it denotes <tt>input_iterator_tag</tt>.</del></p></li>
<li><p>(1.3) &mdash; Let <tt>a</tt> denote an lvalue of type <tt>const common_iterator&lt;I, S&gt;</tt>. 
If the expression <tt>a.operator-&gt;()</tt> is well-formed, then <tt>pointer</tt> denotes <tt>decltype(a.operator->())</tt>. 
Otherwise, <tt>pointer</tt> denotes <tt>void</tt>.</p></li>
</ol>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3892" href="https://cplusplus.github.io/LWG/lwg-active.html#3892">3892</a>. Incorrect formatting of nested ranges and tuples</h3>
<p><b>Section:</b> 22.14.7.2 <a href="https://wg21.link/format.range.formatter">[format.range.formatter]</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">Ready</a>
 <b>Submitter:</b> Victor Zverovich <b>Opened:</b> 2023-02-20 <b>Last modified:</b> 2023-06-16</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#format.range.formatter">issues</a> in [format.range.formatter].</p>
<p><b>Discussion:</b></p>
<p>
<tt>formatter</tt> specializations for ranges and tuples set debug format for underlying element formatters in their 
<tt>parse</tt> functions e.g. 22.14.7.2 <a href="https://wg21.link/format.range.formatter">[format.range.formatter]</a> p9:
</p>
<blockquote><pre>
template&lt;class ParseContext&gt;
  constexpr typename ParseContext::iterator
    parse(ParseContext&amp; ctx);
</pre>
<blockquote>
<p>
<i>Effects</i>: Parses the format specifier as a <i>range-format-spec</i> and stores the parsed specifiers in <tt>*this</tt>.
 The values of <tt><i>opening-bracket_</i></tt>, <tt><i>closing-bracket_</i></tt>, and <tt><i>separator_</i></tt> are modified 
 if and only if required by the <i>range-type</i> or the <tt>n</tt> option, if present. If:
</p>
<ol style="list-style-type: none">
<li><p>&mdash; the <i>range-type</i> is neither <tt>s</tt> nor <tt>?s</tt>,</p></li>
<li><p>&mdash; <tt><i>underlying_</i>.set_debug_format()</tt> is a valid expression, and</p></li>
<li><p>&mdash; there is no <i>range-underlying-spec</i>,</p></li>
</ol>
<p>
then calls <tt><i>underlying_</i>.set_debug_format()</tt>.
</p>
</blockquote>
</blockquote>
<p>
However, they don't say anything about calling <tt>parse</tt> functions of those formatters. As as result, 
formatting of nested ranges can be incorrect, e.g.
</p>
<blockquote><pre>
std::string s = std::format("{}", std::vector&lt;std::vector&lt;std::string&gt;&gt;{{"a, b", "c"}});
</pre></blockquote>
<p>
With the current specification <tt>s</tt> is <tt>[[a, b, c]]</tt> instead of <tt>[["a, b", "c"]]</tt>, i.e. strings 
in the output are not correctly escaped. The same is true for nested tuples and combinations of tuples and ranges.
<p/>
The fix approved by LEWG as part of <a href="https://wg21.link/P2733">P2733</a> (which was trying to address a different issue) is to 
always call <tt>parse</tt> <a href="https://github.com/cplusplus/papers/issues/1426#issuecomment-1420017182">for underlying formatter</a>. 
Additionally the standard should clarify that <i>format-spec</i> cannot start with <tt>'}'</tt> because that's the 
implicit assumption in range formatting and what happens when <i>format-spec</i> is not present.
</p>

<p><i>[2023-03-22; 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/N4928">N4928</a>.
</p>

<ol>

<li><p>Modify 22.14.2.1 <a href="https://wg21.link/format.string.general">[format.string.general]</a> p1 as indicated:</p>

<blockquote>
<dl>
<dt>[&hellip;]</dt>
<dt><i>format-specifier</i>:</dt>
<dd>: <i>format-spec</i></dd>
<dt><i>format-spec</i>:</dt>
<dd>as specified by the <tt>formatter</tt> specialization for the argument type<ins>; cannot start with <tt>}</tt></ins></dd>
</dl>
</blockquote>

</li>

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

<blockquote>
<p>
-3- Given character type <tt>charT</tt>, output iterator type <tt>Out</tt>, and formatting argument type <tt>T</tt>, in 
Table 74 [tab:formatter.basic] and Table 75 [tab:formatter]:
<p/>
[&hellip;]
<p/>
<tt>pc.begin()</tt> points to the beginning of the <i>format-spec</i> (22.14.2 <a href="https://wg21.link/format.string">[format.string]</a>) of the 
replacement field being formatted in the format string. If <i>format-spec</i> is <ins>not present or</ins> empty then 
either <tt>pc.begin() == pc.end()</tt> or <tt>*pc.begin() == '}'</tt>.
</p>
</blockquote>

</li>

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

<blockquote>
<pre>
template&lt;class ParseContext&gt;
  constexpr typename ParseContext::iterator
    parse(ParseContext&amp; ctx);
</pre>
<blockquote>
<p>
-9- <i>Effects</i>: Parses the format specifier<ins>s</ins> as a <i>range-format-spec</i> and stores the parsed specifiers in <tt>*this</tt>.
<ins>Calls <tt><i>underlying_</i>.parse(ctx)</tt> to parse <i>format-spec</i> in <i>range-format-spec</i> or, if the latter is not present, 
empty <i>format-spec</i>.</ins> The values of <tt><i>opening-bracket_</i></tt>, <tt><i>closing-bracket_</i></tt>, and <tt><i>separator_</i></tt> 
are modified if and only if required by the <i>range-type</i> or the <tt>n</tt> option, if present. If:
</p>
<ol style="list-style-type: none">
<li><p>(9.1) &mdash; the <i>range-type</i> is neither <tt>s</tt> nor <tt>?s</tt>,</p></li>
<li><p>(9.2) &mdash; <tt><i>underlying_</i>.set_debug_format()</tt> is a valid expression, and</p></li>
<li><p>(9.3) &mdash; there is no <i>range-underlying-spec</i>,</p></li>
</ol>
<p>
then calls <tt><i>underlying_</i>.set_debug_format()</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>
<pre>
template&lt;class ParseContext&gt;
  constexpr typename ParseContext::iterator
    parse(ParseContext&amp; ctx);
</pre>
<blockquote>
<p>
-7- <i>Effects</i>: Parses the format specifier<ins>s</ins> as a <i>tuple-format-spec</i> and stores the parsed specifiers 
in <tt>*this</tt>. The values of <tt><i>opening-bracket_</i></tt>, <tt><i>closing-bracket_</i></tt>, and <tt><i>separator_</i></tt> 
are modified if and only if required by the <i>tuple-type</i>, if present. For each element <tt><i>e</i></tt> in 
<tt><i>underlying_</i></tt>, <ins>calls <tt><i>e</i>.parse(ctx)</tt> to parse empty <i>format-spec</i> and,</ins> 
if <tt><i>e</i>.set_debug_format()</tt> is a valid expression, calls <tt><i>e</i>.set_debug_format()</tt>.
</p>
</blockquote>
</blockquote>


</li>


</ol>
</blockquote>

<p><i>[Varna 2023-06-16; Jonathan provides tweaked wording]</i></p>

<p>
Add "an" in two places.
</p>

<p><i>[Varna 2023-06-16; Move to Ready]</i></p>

<p>
This would allow resolving LWG <a href="https://cplusplus.github.io/LWG/lwg-closed.html#3776">3776</a> as NAD.
</p>



<p id="res-3892"><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.14.2.1 <a href="https://wg21.link/format.string.general">[format.string.general]</a> p1 as indicated:</p>

<blockquote>
<dl>
<dt>[&hellip;]</dt>
<dt><i>format-specifier</i>:</dt>
<dd>: <i>format-spec</i></dd>
<dt><i>format-spec</i>:</dt>
<dd>as specified by the <tt>formatter</tt> specialization for the argument type<ins>; cannot start with <tt>}</tt></ins></dd>
</dl>
</blockquote>

</li>

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

<blockquote>
<p>
-3- Given character type <tt>charT</tt>, output iterator type <tt>Out</tt>, and formatting argument type <tt>T</tt>, in 
Table 74 [tab:formatter.basic] and Table 75 [tab:formatter]:
<p/>
[&hellip;]
<p/>
<tt>pc.begin()</tt> points to the beginning of the <i>format-spec</i> (22.14.2 <a href="https://wg21.link/format.string">[format.string]</a>) of the 
replacement field being formatted in the format string. If <i>format-spec</i> is <ins>not present or</ins> empty then 
either <tt>pc.begin() == pc.end()</tt> or <tt>*pc.begin() == '}'</tt>.
</p>
</blockquote>

</li>

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

<blockquote>
<pre>
template&lt;class ParseContext&gt;
  constexpr typename ParseContext::iterator
    parse(ParseContext&amp; ctx);
</pre>
<blockquote>
<p>
-9- <i>Effects</i>: Parses the format specifier<ins>s</ins> as a <i>range-format-spec</i> and stores the parsed specifiers in <tt>*this</tt>.
<ins>Calls <tt><i>underlying_</i>.parse(ctx)</tt> to parse <i>format-spec</i> in <i>range-format-spec</i> or, if the latter is not present, 
an empty <i>format-spec</i>.</ins> The values of <tt><i>opening-bracket_</i></tt>, <tt><i>closing-bracket_</i></tt>, and <tt><i>separator_</i></tt> 
are modified if and only if required by the <i>range-type</i> or the <tt>n</tt> option, if present. If:
</p>
<ol style="list-style-type: none">
<li><p>(9.1) &mdash; the <i>range-type</i> is neither <tt>s</tt> nor <tt>?s</tt>,</p></li>
<li><p>(9.2) &mdash; <tt><i>underlying_</i>.set_debug_format()</tt> is a valid expression, and</p></li>
<li><p>(9.3) &mdash; there is no <i>range-underlying-spec</i>,</p></li>
</ol>
<p>
then calls <tt><i>underlying_</i>.set_debug_format()</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>
<pre>
template&lt;class ParseContext&gt;
  constexpr typename ParseContext::iterator
    parse(ParseContext&amp; ctx);
</pre>
<blockquote>
<p>
-7- <i>Effects</i>: Parses the format specifier<ins>s</ins> as a <i>tuple-format-spec</i> and stores the parsed specifiers 
in <tt>*this</tt>. The values of <tt><i>opening-bracket_</i></tt>, <tt><i>closing-bracket_</i></tt>, and <tt><i>separator_</i></tt> 
are modified if and only if required by the <i>tuple-type</i>, if present. For each element <tt><i>e</i></tt> in 
<tt><i>underlying_</i></tt>, <ins>calls <tt><i>e</i>.parse(ctx)</tt> to parse an empty <i>format-spec</i> and,</ins> 
if <tt><i>e</i>.set_debug_format()</tt> is a valid expression, calls <tt><i>e</i>.set_debug_format()</tt>.
</p>
</blockquote>
</blockquote>


</li>


</ol>





<hr>
<h3><a name="3897" href="https://cplusplus.github.io/LWG/lwg-active.html#3897">3897</a>. <tt>inout_ptr</tt> will not update raw pointer to 0</h3>
<p><b>Section:</b> 20.3.4.3 <a href="https://wg21.link/inout.ptr.t">[inout.ptr.t]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Doug Cook <b>Opened:</b> 2023-02-27 <b>Last modified:</b> 2023-06-16</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#inout.ptr.t">issues</a> in [inout.ptr.t].</p>
<p><b>Discussion:</b></p>
<p>
<tt>inout_ptr</tt> seems useful for two purposes:
</p>
<ol>
<li><p>Using smart pointers with C-style APIs.</p></li>
<li><p>Annotating raw pointers for use with C-style APIs.</p></li>
</ol>
<p>
Unfortunately, as presently specified, it is not safe for developers to use <tt>inout_ptr</tt> for the second purpose. 
It is not safe to change code from
</p>
<blockquote><pre>
void* raw_ptr1;
InitSomething(&amp;raw_ptr1);
UpdateSomething(&amp;raw_ptr1); // In some cases may set raw_ptr1 = nullptr.
CleanupSomething(raw_ptr1);
</pre></blockquote>
<p>
to
</p>
<blockquote><pre>
void* raw_ptr2;
InitSomething(std::out_ptr(raw_ptr2));
UpdateSomething(std::inout_ptr(raw_ptr2)); // <span style="color:red;font-weight:bolder">May leave dangling pointer</span>
CleanupSomething(raw_ptr2);                // <span style="color:red;font-weight:bolder">Possible double-delete</span>
</pre></blockquote>
<p>
In the case where <tt>UpdateSomething</tt> would set <tt>raw_ptr1 = nullptr</tt>, the currently-specified <tt>inout_ptr</tt> 
implementation will leave <tt>raw_ptr2</tt> at its old value. This would likely lead to a double-delete in <tt>CleanupSomething</tt>.
<p/>
The issue occurs because <tt>inout_ptr</tt> is specified as follows:
</p> 
<ol>
<li><p>Constructor: <em>If the user's pointer is a smart pointer</em>, perform a "<tt>release</tt>" operation.</p></li>
<li><p>(C-style API executes)</p></li>
<li><p><em>If the C-style API returns a non-<tt>NULL</tt> pointer</em>, propagate the returned value to the user's pointer.</p></li>
</ol>
<p>
If the user's pointer is not a smart pointer, no "<tt>release</tt>" operation occurs, and if the C-style API returns a 
<tt>NULL</tt> pointer, no propagation of the <tt>NULL</tt> occurs. We're left with a dangling raw pointer which is 
different from the original behavior using <tt>&amp;</tt>.
<p/>
I see two potential solutions:
</p>
<ol>
<li><p>Make the "<tt>release</tt>" operation unconditional (i.e. it applies to both smart and raw pointers). For raw pointers, 
define the "<tt>release</tt>" operation as setting the raw pointer to <tt>nullptr</tt>.</p></li>
<li><p>Make the return value propagation unconditional for raw pointers.</p></li>
</ol>
<p>
Solution #2 seems likely to lead to more optimal code as it avoids an unnecessary branch.
</p>

<p><i>[2023-03-22; Reflector poll]</i></p>

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

<p><i>[Varna 2023-06-16; Move to Ready]</i></p>




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

<ol>

<li><p>Modify 20.3.4.3 <a href="https://wg21.link/inout.ptr.t">[inout.ptr.t]</a> as indicated:</p>

<blockquote>
<pre>
~inout_ptr_t();
</pre>
<blockquote>
<p>
-9- Let <tt>SP</tt> be <tt><i>POINTER_OF_OR</i>(Smart, Pointer)</tt> (20.2.1 <a href="https://wg21.link/memory.general">[memory.general]</a>).
<p/>
-10- Let <i>release-statement</i> be <tt>s.release();</tt> if an implementation does not call <tt>s.release()</tt> in the
constructor. Otherwise, it is empty.
<p/>
-11- <i>Effects</i>: Equivalent to:
</p>
<ol style="list-style-type: none">
<li><p>(11.1) &mdash; </p>
<blockquote><pre>
<del>if (p) {</del>
  apply([&amp;](auto&amp;&amp;... args) {
    s = Smart( static_cast&lt;SP&gt;(p), std::forward&lt;Args&gt;(args)...); }, std::move(a));
<del>}</del>
</pre></blockquote>
<p>
if <tt>is_pointer_v&lt;Smart&gt;</tt> is <tt>true</tt>;
</p></li>
<li><p>(11.2) &mdash; otherwise,</p>
<blockquote><pre>
<i>release-statement</i>;
if (p) {
  apply([&amp;](auto&amp;&amp;... args) {
    s.reset(static_cast&lt;SP&gt;(p), std::forward&lt;Args&gt;(args)...); }, std::move(a));
}
</pre></blockquote>
<p>
if the expression <tt>s.reset(static_cast&lt;SP&gt;(p), std::forward&lt;Args&gt;(args)...)</tt> is well-formed;
</p>
</li>
<li><p>(11.3) &mdash; otherwise,</p>
<blockquote><pre>
<i>release-statement</i>;
if (p) {
  apply([&amp;](auto&amp;&amp;... args) {
    s = Smart(static_cast&lt;SP&gt;(p), std::forward&lt;Args&gt;(args)...); }, std::move(a));
}
</pre></blockquote>
<p>
if <tt>is_constructible_v&lt;Smart, SP, Args...&gt;</tt> is <tt>true</tt>;
</p>
</li>
<li><p>(11.4) &mdash; otherwise, the program is ill-formed.</p></li>
</ol>

</blockquote>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="3946" href="https://cplusplus.github.io/LWG/lwg-active.html#3946">3946</a>. The definition of <tt>const_iterator_t</tt> should be reworked</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">Ready</a>
 <b>Submitter:</b> Christopher Di Bella <b>Opened:</b> 2023-06-13 <b>Last modified:</b> 2023-06-26</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>
During the reflector discussion of <a href="https://wg21.link/P2836">P2836</a>, consensus was reached that <tt>const_iterator_t&lt;R&gt;</tt> 
doesn't necessarily provide the same type as <tt>decltype(ranges::cbegin(r))</tt>, and that it should be changed to 
the proposed resolution below so that they're consistent.
</p>

<p><i>[Varna 2023-06-14; Move to Ready]</i></p>



<p id="res-3946"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4950">N4950</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>
[&hellip;]
template&lt;range R&gt;
  using const_iterator_t = <ins>decltype(ranges::cbegin(declval&lt;R&amp;&gt;()))</ins><del>const_iterator&lt;iterator_t&lt;R&gt;&gt;</del>; // <i>freestanding</i>
template&lt;range R&gt;
  using const_sentinel_t = <ins>decltype(ranges::cend(declval&lt;R&amp;&gt;()))</ins><del>const_sentinel&lt;sentinel_t&lt;R&gt;&gt;</del>;   // <i>freestanding</i>
[&hellip;]
</pre>
</blockquote>
</li>

</ol>





<h2 id="tentatively_ready">Tentatively Ready Issues</h2>
<hr>
<h3><a name="3809" href="https://cplusplus.github.io/LWG/lwg-active.html#3809">3809</a>. Is <tt>std::subtract_with_carry_engine&lt;uint16_t&gt;</tt> supposed to work?</h3>
<p><b>Section:</b> 28.5.4.4 <a href="https://wg21.link/rand.eng.sub">[rand.eng.sub]</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-11-02 <b>Last modified:</b> 2023-11-07</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#rand.eng.sub">issues</a> in [rand.eng.sub].</p>
<p><b>Discussion:</b></p>
<p>
The standard requires <tt>subtract_with_carry_engine&lt;T&gt;</tt> to use:
</p>
<blockquote><pre>
linear_congruential_engine&lt;T, 40014u, 0u, 2147483563u&gt;
</pre></blockquote>
<p>
where each of those values is converted to <tt>T</tt>.
<p/>
This appears to mean <tt>subtract_with_carry_engine</tt> cannot be used with <tt>uint16_t</tt>, because 
<tt>2147483563u</tt> cannot be converted to <tt>uint16_t</tt> without narrowing.
<p/>
What is the intention here? Should it be ill-formed? Should the seed engine be 
<tt>linear_congruential_engine&lt;uint_least32_t, &hellip;&gt;</tt> instead? The values from the 
<tt>linear_congruential_engine</tt> are used modulo 2^32 so getting 64-bit values from it is pointless, 
and getting 16-bit values from it doesn't compile.
</p>

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


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


<p><i>[2023-05; reflector poll]</i></p>

<p>Status to Tentatively Ready after six votes in favour.</p>



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

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

<ol>
<li>
<p>Modify the class synopsis in 28.5.4.4 <a href="https://wg21.link/rand.eng.sub">[rand.eng.sub]</a> as indicated:</p>
<blockquote><pre>
namespace std {
  template&lt;class UIntType, size_t w, size_t s, size_t r&gt;
  class subtract_with_carry_engine {
  public:
    // types
    using result_type = UIntType;
    // engine characteristics
    static constexpr size_t word_size = w;
    static constexpr size_t short_lag = s;
    static constexpr size_t long_lag = r;
    static constexpr result_type min() { return 0; }
    static constexpr result_type max() { return m − 1; }
    static constexpr <del>result_type</del><ins>uint_least32_t</ins> default_seed = 19780503u;
    // constructors and seeding functions
    subtract_with_carry_engine() : subtract_with_carry_engine(<del>default_seed</del><ins>0u</ins>) {}
    explicit subtract_with_carry_engine(result_type value);
    template&lt;class Sseq&gt; explicit subtract_with_carry_engine(Sseq&amp; q);
    void seed(result_type value = <del>default_seed</del><ins>0u</ins>);
    template&lt;class Sseq&gt; void seed(Sseq&amp; q);
</pre></blockquote>
</li>
<li>
<p>Modify 28.5.4.4 <a href="https://wg21.link/rand.eng.sub">[rand.eng.sub]</a> p7 as indicated:</p>
<blockquote>
<pre>explicit subtract_with_carry_engine(result_type value);</pre>
<p>-7- <i>Effects</i>:
Sets the values of
<math>
  <mrow>
    <msub> <mi>X</mi> <mrow> <mo>−</mo> <mi>r</mi> </mrow> </msub>
    <mo separator="true">,</mo>
    <mo>…</mo>
    <mo separator="true">,</mo>
    <msub> <mi>X</mi> <mrow> <mo>−</mo> <mn>1</mn> </mrow> </msub>
  </mrow>
</math>,
in that order, as specified below. If
<math>
  <mrow>
    <msub> <mi>X</mi> <mrow> <mo>−</mo> <mn>1</mn> </mrow> </msub>
  </mrow>
</math>
is then <math> <mn>0</mn> </math>,
sets <math> <mi>c</mi> </math> to <math> <mn>1</mn> </math>;
otherwise sets <math> <mi>c</mi> </math> to <math> <mn>0</mn> </math>.
</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;
To set the values
<math> <mrow> <msub> <mi>X</mi> <mi>k</mi> </msub> </mrow> </math>,
first construct <tt>e</tt>, a <tt>linear_congruential_engine</tt> object,
as if by the following definition:
</p>
<blockquote><pre>
linear_congruential_engine&lt;<del>result_type</del><ins>uint_least32_t</ins>,
                           40014u,0u,2147483563u&gt; e(value == 0u ? default_seed : value);
</pre></blockquote>
<p>&nbsp;&nbsp;&nbsp;&nbsp;
Then, to set each
<math> <mrow> <msub> <mi>X</mi> <mi>k</mi> </msub> </mrow> </math>,
obtain new values
<math>
  <mrow>
    <msub> <mi>z</mi> <mn>0</mn> </msub>
    <mo separator="true">,</mo>
    <mo>…</mo>
    <mo separator="true">,</mo>
    <msub> <mi>z</mi> <mrow> <mi>n</mi> <mo>−</mo> <mn>1</mn> </mrow> </msub>
  </mrow>
</math>
from
<math>
  <mrow>
    <mi>n</mi> <mo>=</mo>
    <mo form="prefix" stretchy="false">⌈</mo>
    <mi>w</mi> <mo lspace="0em" rspace="0em">⁄</mo> <mn>32</mn>
    <mo form="postfix" stretchy="false">⌉</mo>
  </mrow>
</math>
successive invocations of <tt>e</tt>.
Set
<math> <mrow> <msub> <mi>X</mi> <mi>k</mi> </msub> </mrow> </math>
to
<math>
  <mrow>
    <mrow>
      <mo fence="true" form="prefix">(</mo>
      <msubsup>
        <mo movablelimits="false">∑</mo>
        <mrow> <mi>j</mi> <mo>=</mo> <mn>0</mn> </mrow>
        <mrow> <mi>n</mi> <mo>−</mo> <mn>1</mn> </mrow>
      </msubsup>
      <msub> <mi>z</mi> <mi>j</mi> </msub>
      <mo>⋅</mo>
      <msup> <mn>2</mn> <mrow> <mn>32</mn> <mi>j</mi> </mrow> </msup>
      <mo fence="true" form="postfix">)</mo>
    </mrow>
    <mo lspace="0.2222em" rspace="0.2222em">mod</mo>
    <mi>m</mi>
  </mrow>
</math>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3947" href="https://cplusplus.github.io/LWG/lwg-active.html#3947">3947</a>. Unexpected constraints on <tt>adjacent_transform_view::base()</tt></h3>
<p><b>Section:</b> 26.7.27.2 <a href="https://wg21.link/range.adjacent.transform.view">[range.adjacent.transform.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2023-06-17 <b>Last modified:</b> 2023-10-27</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
In section 26.7.27.2 <a href="https://wg21.link/range.adjacent.transform.view">[range.adjacent.transform.view]</a> the class
<tt>ranges::adjacent_transform_view</tt> got two new <tt>base()</tt> members from
<a href="https://cplusplus.github.io/LWG/lwg-defects.html#3848">3848</a>.
<p/>
The first one looks like
</p>
<blockquote><pre>
constexpr V base() const &amp; requires copy_constructible&lt;<i>InnerView</i>&gt;
{ return <i>inner_</i>.base(); }
</pre></blockquote>
<p>
Here the requirement is that <tt><i>InnerView</i></tt> is copy constructible, when it in
fact returns an object of type <tt>V</tt>. That seems odd.
<p/>
I would expect the constraint to instead be <tt>copy_constructible&lt;V&gt;</tt>.
</p>

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

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



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

<ol>
<li><p>Modify 26.7.27.2 <a href="https://wg21.link/range.adjacent.transform.view">[range.adjacent.transform.view]</a>, class template 
<tt>adjacent_transform_view</tt> synopsis, as indicated:</p>

<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; {
    [&hellip;]
    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:
    [&hellip;]
    constexpr V base() const &amp; requires copy_constructible&lt;<ins>V</ins><del><i>InnerView</i></del>&gt; { return <i>inner_</i>.base(); }
    constexpr V base() &amp;&amp; { return std::move(<i>inner_</i>).base(); }
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3948" href="https://cplusplus.github.io/LWG/lwg-active.html#3948">3948</a>. <tt><i>possibly-const-range</i></tt> and <tt><i>as-const-pointer</i></tt> should be <tt>noexcept</tt></h3>
<p><b>Section:</b> 26.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>, 26.3.14 <a href="https://wg21.link/range.prim.cdata">[range.prim.cdata]</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-06-20 <b>Last modified:</b> 2023-10-27</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>
As of <a href="https://wg21.link/P2278R4">P2278R4</a>, several range access CPOs are specified with <tt><i>possibly-const-range</i></tt> 
and <tt><i>as-const-pointer</i></tt>. These helper functions never throw exceptions, but are not marked with 
<tt>noexcept</tt>. As a result, implementations are currently allowed to make a call to 
<tt>ranges::c<i>cpo</i></tt> potentially throwing while the underlying <tt>ranges::<i>cpo</i></tt> call is 
non-throwing, which doesn't seem to be intended.
</p>

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

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



<p id="res-3948"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4950">N4950</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>
[&hellip;]
// <i>26.7.21 <a href="https://wg21.link/range.as.const">[range.as.const]</a>, as const view</i>
template&lt;input_range R&gt;
  constexpr auto&amp; <i>possibly-const-range</i>(R&amp; r) <ins>noexcept</ins> {      // <i>exposition only</i>
    if constexpr (constant_range&lt;const R&gt; &amp;&amp; !constant_range&lt;R&gt;) {
      return const_cast&lt;const R&amp;&gt;(r);
    } else {
      return r;
    }
  }
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 26.3.14 <a href="https://wg21.link/range.prim.cdata">[range.prim.cdata]</a> before p1 as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt;
constexpr auto <i>as-const-pointer</i>(const T* p) <ins>noexcept</ins> { return p; }    // <i>exposition only</i>
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3949" href="https://cplusplus.github.io/LWG/lwg-active.html#3949">3949</a>. <tt>std::atomic&lt;bool&gt;</tt>'s trivial destructor dropped in C++17 spec wording</h3>
<p><b>Section:</b> 33.5.8.1 <a href="https://wg21.link/atomics.types.generic.general">[atomics.types.generic.general]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jeremy Hurwitz <b>Opened:</b> 2023-06-20 <b>Last modified:</b> 2023-10-27</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::atomic&lt;bool&gt;</tt> was originally required to have a trivial default constructor and a trivial destructor 
[C++11 <a href="https://wg21.link/N3337#page=1118">N3337</a>: Section [atomics.types.generic], Paragraph 5], 
the same as the integral [C++11 <a href="https://wg21.link/N3337#page=1118">N3337</a>: Section [atomics.types.generic], 
Paragraph 5] and pointer specializations [C++11 <a href="https://wg21.link/N3337#page=1119">N3337</a>: 
Section [atomics.types.generic], Paragraph 6]. <a href="https://wg21.link/P0558">P0558</a> rearranged the text, 
accidentally (as far as we can tell) removing the constructor and destructor requirements from <tt>std::atomic&lt;bool&gt;</tt>,
which has the surprising effect that <tt>std::atomic&lt;bool&gt;</tt> has no longer the same constructor/destructor 
guarantees as <tt>std::atomic&lt;int&gt;</tt>.
<p/>
C++20 removed the "trivial default constructor" requirement from all specializations. A specialization for floating-point 
types was added with a trivial destructor [<a href="https://wg21.link/N4861#page=1548">N4861</a>: Section [atomics.types.float], 
Paragraph 2)].
</p>

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

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



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

<ol>
<li><p>Modify 33.5.8.1 <a href="https://wg21.link/atomics.types.generic.general">[atomics.types.generic.general]</a> as indicated:</p>

<blockquote>
<p>
-1- [&hellip;]
<p/>
-2- The specialization <tt>atomic&lt;bool&gt;</tt> is a standard-layout struct. <ins>It has a trivial destructor.</ins>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3951" href="https://cplusplus.github.io/LWG/lwg-active.html#3951">3951</a>. &sect;[expected.object.swap]: Using <tt>value()</tt> instead of <tt>has_value()</tt></h3>
<p><b>Section:</b> 22.8.6.5 <a href="https://wg21.link/expected.object.swap">[expected.object.swap]</a>, 22.8.7.5 <a href="https://wg21.link/expected.void.swap">[expected.void.swap]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ben Craig <b>Opened:</b> 2023-06-25 <b>Last modified:</b> 2023-10-27</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
22.8.6.5 <a href="https://wg21.link/expected.object.swap">[expected.object.swap]</a> p2 has the following text in it:
</p>
<blockquote><p>
For the case where <tt>rhs.value()</tt> is <tt>false</tt> and <tt>this-&gt;has_value()</tt> is <tt>true</tt>, equivalent to: [&hellip;]
</p></blockquote>
<p>
The table preceding that text is a table of <tt>this-&gt;has_value()</tt> vs. <tt>rhs.has_value()</tt>. The <tt>rhs.value()</tt> 
in the text is almost certainly a typo, as a <tt>.value()</tt> call here doesn't make any sense, especially if this is an 
<tt>expected&lt;<i>non-bool</i>, E&gt;</tt>.
<p/>
The same issue is there for 22.8.7.5 <a href="https://wg21.link/expected.void.swap">[expected.void.swap]</a> p2.
</p>

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

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



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

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


<blockquote>
<pre>
constexpr void swap(expected&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
-1- [&hellip;]
<p/>
-2- <i>Effects</i>: See Table 63 [tab:expected.object.swap].
<p/>
For the case where <tt>rhs.<ins>has_</ins>value()</tt> is <tt>false</tt> and <tt>this-&gt;has_value()</tt> is <tt>true</tt>, equivalent to: [&hellip;]
</p>
</blockquote>
</blockquote>

</li>

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


<blockquote>
<pre>
constexpr void swap(expected&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
-1- [&hellip;]
<p/>
-2- <i>Effects</i>: See Table 64 [tab:expected.void.swap].
<p/>
For the case where <tt>rhs.<ins>has_</ins>value()</tt> is <tt>false</tt> and <tt>this-&gt;has_value()</tt> is <tt>true</tt>, equivalent to: [&hellip;]
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3953" href="https://cplusplus.github.io/LWG/lwg-active.html#3953">3953</a>. <tt>iter_move</tt> for <tt>common_iterator</tt> and <tt>counted_iterator</tt> should return <tt>decltype(auto)</tt></h3>
<p><b>Section:</b> 25.5.5.7 <a href="https://wg21.link/common.iter.cust">[common.iter.cust]</a>, 25.5.7.7 <a href="https://wg21.link/counted.iter.cust">[counted.iter.cust]</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-06-30 <b>Last modified:</b> 2023-11-07</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
Although the customized <tt>iter_move</tt> of both requires the underlying iterator <tt>I</tt> to be <tt>input_iterator</tt>, 
they still explicitly specify the return type as <tt>iter_rvalue_reference_t&lt;I&gt;</tt>,
which makes it always instantiated.
</p>
<p>
From the point of view that its validity is only specified in the <tt>input_iterator</tt> concept, it would be better to remove such 
unnecessary type instantiation, which does not make much sense for an <tt>output_iterator</tt> even if it is still valid.
</p>

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

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



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

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


<blockquote>
<pre>
namespace std {
  template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
    requires (!same_as&lt;I, S&gt; &amp;&amp; copyable&lt;I&gt;)
  class common_iterator {
  public:
    [&hellip;]
    friend constexpr <del>iter_rvalue_reference_t&lt;I&gt;</del><ins>decltype(auto)</ins> iter_move(const common_iterator&amp; i)
      noexcept(noexcept(ranges::iter_move(declval&lt;const I&amp;&gt;())))
        requires input_iterator&lt;I&gt;;
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>

</li>

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

<blockquote>
<pre>
friend constexpr <del>iter_rvalue_reference_t&lt;I&gt;</del><ins>decltype(auto)</ins> iter_move(const common_iterator&amp; i)
  noexcept(noexcept(ranges::iter_move(declval&lt;const I&amp;&gt;())))
    requires input_iterator&lt;I&gt;;
</pre>
<blockquote>
<p>
-1- <i>Preconditions</i>: [&hellip;]
<p/>
-2- <i>Effects</i>: Equivalent to: <tt>return ranges::iter_move(get&lt;I&gt;(i.v_));</tt>
</p>
</blockquote>
</blockquote>

</li>

<li><p>Modify 25.5.7.1 <a href="https://wg21.link/counted.iterator">[counted.iterator]</a>, class template <tt>counted_iterator</tt> synopsis, as indicated:</p>


<blockquote>
<pre>
namespace std {
  template&lt;input_or_output_iterator I&gt;
  class counted_iterator {
  public:
    [&hellip;]
    friend constexpr <del>iter_rvalue_reference_t&lt;I&gt;</del><ins>decltype(auto)</ins> iter_move(const counted_iterator&amp; i)
      noexcept(noexcept(ranges::iter_move(i.current)))
        requires input_iterator&lt;I&gt;;
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>

</li>

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

<blockquote>
<pre>
friend constexpr <del>iter_rvalue_reference_t&lt;I&gt;</del><ins>decltype(auto)</ins> 
  iter_move(const counted_iterator&amp; i)
    noexcept(noexcept(ranges::iter_move(i.current)))
    requires input_iterator&lt;I&gt;;
</pre>
<blockquote>
<p>
-1- <i>Preconditions</i>: [&hellip;]
<p/>
-2- <i>Effects</i>: Equivalent to: <tt>return ranges::iter_move(i.current);</tt>
</p>
</blockquote>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="3957" href="https://cplusplus.github.io/LWG/lwg-active.html#3957">3957</a>. &sect;[container.alloc.reqmts] The value category of <tt>v</tt> should be claimed</h3>
<p><b>Section:</b> 24.2.2.5 <a href="https://wg21.link/container.alloc.reqmts">[container.alloc.reqmts]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> jim x <b>Opened:</b> 2023-07-10 <b>Last modified:</b> 2023-10-27</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#container.alloc.reqmts">active issues</a> in [container.alloc.reqmts].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#container.alloc.reqmts">issues</a> in [container.alloc.reqmts].</p>
<p><b>Discussion:</b></p>
<p>
24.2.2.5 <a href="https://wg21.link/container.alloc.reqmts">[container.alloc.reqmts]</a> p2 says:
</p>
<blockquote><p>
[&hellip;] an expression <tt>v</tt> of type <tt>T</tt> or <tt>const T</tt>, [&hellip;]
</p></blockquote>
<p>
Then 24.2.2.5 <a href="https://wg21.link/container.alloc.reqmts">[container.alloc.reqmts]</a> bullet (2.4) says:
</p>
<blockquote><p>
<tt>T</tt> is <i>Cpp17CopyInsertable into <tt>X</tt></i> means that, in addition to <tt>T</tt> being 
<i>Cpp17MoveInsertable</i> into <tt>X</tt>, the following expression is well-formed:
</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p, v)
</pre></blockquote>
</blockquote>
<p>
So, what is the value category of the expression <tt>v</tt>? We didn't explicitly phrase the wording. 
The intent may be that the value category of <tt>v</tt> is any defined value category in 7.2.1 <a href="https://wg21.link/basic.lval">[basic.lval]</a>, 
however, the intent is not clear in the current wording. Maybe, we can say:
</p>
<blockquote><p>
[&hellip;] the following expression is well-formed:
</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p, v)
</pre></blockquote>
<p>
for <tt>v</tt> of any value category.
</p>
</blockquote>
<p>
which can make the intent meaning clearer.
</p>

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

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



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

<ol>

<li><p>Modify 24.2.2.5 <a href="https://wg21.link/container.alloc.reqmts">[container.alloc.reqmts]</a> as indicated:</p>

<blockquote>
<p>
-2- Given an allocator type <tt>A</tt> and given a container type <tt>X</tt> having a <tt>value_type</tt> 
identical to <tt>T</tt> and an <tt>allocator_type</tt> identical to <tt>allocator_traits&lt;A&gt;::rebind_alloc&lt;T&gt;</tt> 
and given an lvalue <tt>m</tt> of type <tt>A</tt>, a pointer <tt>p</tt> of type <tt>T*</tt>, an expression 
<tt>v</tt> <ins>that denotes an lvalue</ins> of type <tt>T</tt> or <tt>const T</tt> <ins>or an rvalue of type <tt>const T</tt></ins>, 
and an rvalue <tt>rv</tt> of type <tt>T</tt>, the following terms are defined. [&hellip;]
</p>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(2.3) &mdash; <tt>T</tt> is <i>Cpp17MoveInsertable into <tt>X</tt></i> means that the following expression is well-formed:</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p, rv)
</pre></blockquote>
<p>and its evaluation causes the following postcondition to hold: The value of <tt>*p</tt> is equivalent to the value
of <tt>rv</tt> before the evaluation.
<p/>
[<i>Note 1</i>: <tt>rv</tt> remains a valid object. Its state is unspecified &mdash; <i>end note</i>]</p></li>
<li><p>(2.4) &mdash; <tt>T</tt> is <i>Cpp17CopyInsertable into <tt>X</tt></i> means that, in addition to <tt>T</tt> being 
<i>Cpp17MoveInsertable</i> into <tt>X</tt>, the following expression is well-formed:</p>
<blockquote><pre>
allocator_traits&lt;A&gt;::construct(m, p, v)
</pre></blockquote>
<p>and its evaluation causes the following postcondition to hold: The value of <tt>v</tt> is unchanged and is
equivalent to <tt>*p</tt>.</p>
</li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="3965" href="https://cplusplus.github.io/LWG/lwg-active.html#3965">3965</a>. Incorrect example in [format.string.escaped] p3 for formatting of combining characters</h3>
<p><b>Section:</b> 22.14.6.4 <a href="https://wg21.link/format.string.escaped">[format.string.escaped]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tom Honermann <b>Opened:</b> 2023-07-31 <b>Last modified:</b> 2023-10-27</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The C++23 DIS contains the following example in 22.14.6.4 <a href="https://wg21.link/format.string.escaped">[format.string.escaped]</a> p3. (This example does 
not appear in the most recent <a href="https://wg21.link/N4950">N4950</a> WP or on <a href="https://eel.is/c++draft">https://eel.is/c++draft</a> 
because the project editor has not yet merged changes needed to support rendering of some of the characters involved).
</p>
<blockquote><pre>
string s6 = format("[{:?}]", "&#x1F937;&#x200D;&#x2642;&#xFE0F;"); // s6 has value: ["&#x1F937;\u{200d}&#x2642;\u{fe0f}"]
</pre></blockquote>
<p>
The character to be formatted (&#x1F937;&#x200D;&#x2642;&#xFE0F;) consists of the following sequence of code points 
in the order presented:
</p>
<ul>
<li><p>U+1F937 (SHRUG)</p></li>
<li><p>U+200D (ZERO WIDTH JOINER)</p></li>
<li><p>U+2642 (MALE SIGN)</p></li>
<li><p>U+FE0F (VARIATION SELECTOR-16)</p></li>
</ul>
<p>
22.14.6.4 <a href="https://wg21.link/format.string.escaped">[format.string.escaped]</a> bullet 2.2.1 specifies which code points are to be formatted as a 
<tt>\u{<i>hex-digit-sequence</i>}</tt> escape sequence:
</p>
<ol style="list-style-type: none">
<li><p>(2.2.1) &mdash; If <i>X</i> encodes a single character <i>C</i>, then:</p>
<ol style="list-style-type: none">
<li><p>(2.2.1.1) &mdash; If <i>C</i> is one of the characters in Table 75 [tab:format.escape.sequences], then the two characters shown 
as the corresponding escape sequence are appended to <i>E</i>.</p></li>
<li><p>(2.2.1.2) &mdash; Otherwise, if <i>C</i> is not U+0020 SPACE and</p>
<ol style="list-style-type: none">
<li><p>(2.2.1.2.1) &mdash; <i>CE</i> is UTF-8, UTF-16, or UTF-32 and <i>C</i> corresponds to a Unicode scalar value whose
Unicode property <tt>General_Category</tt> has a value in the groups <tt>Separator</tt> (<tt>Z</tt>) or <tt>Other</tt>
(<tt>C</tt>), as described by UAX #44 of the Unicode Standard, or</p></li>
<li><p>(2.2.1.2.2) &mdash; <i>CE</i> is UTF-8, UTF-16, or UTF-32 and <i>C</i> corresponds to a Unicode scalar value with
the Unicode property <tt>Grapheme_Extend=Yes</tt> as described by UAX #44 of the Unicode
Standard and <i>C</i> is not immediately preceded in <i>S</i> by a character <i>P</i> appended to <i>E</i> without
translation to an escape sequence, or</p></li>
<li><p>(2.2.1.2.3) &mdash; <i>CE</i> is neither UTF-8, UTF-16, nor UTF-32 and <i>C</i> is one of an implementation-defined
set of separator or non-printable characters</p></li>
</ol>
<p>
then the sequence <tt>\u{<i>hex-digit-sequence</i>}</tt> is appended to <i>E</i>, where <tt><i>hex-digit-sequence</i></tt>
is the shortest hexadecimal representation of <i>C</i> using lower-case hexadecimal digits.
</p>
</li>
<li><p>(2.2.1.3) &mdash; Otherwise, <i>C</i> is appended to <i>E</i>.</p></li>
</ol>
</li>
</ol>
<p>
The example is not consistent with the above specification for the final code point. 
<a href="https://util.unicode.org/UnicodeJsps/character.jsp?a=FE0F">U+FE0F</a> is a single character, 
is not one of the characters in Table 75, is not U+0020, has a <tt>General_Category</tt> of <tt>Nonspacing Mark (Mn)</tt> 
which is neither <tt>Z</tt> nor <tt>C</tt>, has <tt>Grapheme_Extend=Yes</tt> but the prior character (U+2642) is not 
formatted as an escape sequence, and is not one of an implementation-defined set of separator or non-printable characters 
(for the purposes of this example; the example assumes a UTF-8 encoding). Thus, formatting for this character falls to 
the last bullet point and the character should be appended as is (without translation to an escape sequence). 
Since this character is a combining character, it should  combine with the previous character and thus alter the 
appearance of U+2642 (thus producing <tt>"&#x2642;&#xFE0F;"</tt> instead of <tt>"&#x2642;\u{fe0f}"</tt>).
</p>

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

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



<p id="res-3965"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4950">N4950</a> plus missing editorial pieces from <a href="https://wg21.link/P2286R8">P2286R8</a>.
</p>

<ol>

<li><p>Modify the example following 22.14.6.4 <a href="https://wg21.link/format.string.escaped">[format.string.escaped]</a> p3 as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note</i>: The presented example was voted in as part of <a href="https://wg21.link/P2286R8">P2286R8</a> during the July 2022 
Virtual Meeting but is not yet accessible in the most recent working draft <a href="https://wg21.link/N4950">N4950</a>.
<p/>
Note that the final character (&#x2642;&#xFE0F;) is composed from the two code points U+2642 and U+FE0F.
]
</p>
</blockquote>


<blockquote>
<p>
</p>
<blockquote><pre>
string s6 = format("[{:?}]", "&#x1F937;&#x200D;&#x2642;&#xFE0F;"); // s6 has value: <del>["&#x1F937;\u{200d}&#x2642;\u{fe0f}"]</del><ins>["&#x1F937;\u{200d}&#x2642;&#xFE0F;"]</ins>
</pre></blockquote>

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





<hr>
<h3><a name="3970" href="https://cplusplus.github.io/LWG/lwg-active.html#3970">3970</a>. &sect;[mdspan.syn] Missing definition of <tt>full_extent_t</tt> and <tt>full_extent</tt></h3>
<p><b>Section:</b> 24.7.3.2 <a href="https://wg21.link/mdspan.syn">[mdspan.syn]</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> 2023-08-16 <b>Last modified:</b> 2023-10-27</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<tt>submdspan</tt> uses a type called <tt>full_extent_t</tt>, but there isn't a definition for that type.
<p/>
It appears that <tt>full_extent_t</tt> (along with <tt>full_extent</tt>) was proposed in <a href="https://wg21.link/P0009">P0009</a> 
before <tt>submdspan</tt> was moved into its own paper, and its definition failed to be included in 
<a href="https://wg21.link/P2630">P2630</a> Submdspan.
</p>

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

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



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

<ol>

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

<blockquote>
<pre>
[&hellip;]
<i>// 24.7.3.7 <a href="https://wg21.link/mdspan.submdspan">[mdspan.submdspan]</a>, submdspan creation</i>
template&lt;class OffsetType, class LengthType, class StrideType&gt;
  struct strided_slice;

template&lt;class LayoutMapping&gt;
  struct submdspan_mapping_result;
  
<ins>struct full_extent_t { explicit full_extent_t() = default; };
inline constexpr full_extent_t full_extent{};</ins>
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3973" href="https://cplusplus.github.io/LWG/lwg-active.html#3973">3973</a>. Monadic operations should be ADL-proof</h3>
<p><b>Section:</b> 22.8.6.7 <a href="https://wg21.link/expected.object.monadic">[expected.object.monadic]</a>, 22.5.3.7 <a href="https://wg21.link/optional.monadic">[optional.monadic]</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-08-10 <b>Last modified:</b> 2023-09-24</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#expected.object.monadic">issues</a> in [expected.object.monadic].</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3938">3938</a> switched to use <tt>**this</tt> to access the value stored in <tt>std::expected</tt>. 
However, as shown in LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3969">3969</a>, <tt>**this</tt> can trigger ADL and find an unwanted overload, 
and thus may caused unintended behavior.
<p/>
Current implementations behave correctly (<a href="https://godbolt.org/z/3b1Tbs1jd">Godbolt link</a>): they 
don't direct use <tt>**this</tt>, but use the name of the union member instead.
<p/>
Moreover, <a href="https://wg21.link/P2407R5">P2407R5</a> will change the monadic operations of <tt>std::optional</tt> to use <tt>**this</tt>, 
which is also problematic.
</p>

<p><i>[2023-09-19; Wording update]</i></p>

<p>
Several people preferred to replace <tt>operator*()</tt> by the corresponding union members, so this part of the proposed wording 
has been adjusted, which is a rather mechanical replacement.
</p>

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

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



<p id="res-3973"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4958">N4958</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 class="note">
<p>
[<i>Drafting note:</i> Effectively replace all occurrences of <tt>**this</tt> by <tt><i>val</i></tt>, except for <tt>decltype</tt>.]
</p>
</blockquote>

<blockquote>
<pre>
template&lt;class F&gt; constexpr auto and_then(F&amp;&amp; f) &amp;;
template&lt;class F&gt; constexpr auto and_then(F&amp;&amp; f) const &amp;;
</pre>
<blockquote>
<p>
-1- Let <tt>U</tt> be <tt>remove_cvref_t&lt;invoke_result_t&lt;F, decltype(<del>**this</del><ins>(<i>val</i>)</ins>)&gt;&gt;</tt>.
<p/>
-2- [&hellip;]
<p/>
-3- [&hellip;]
<p/>
-4- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
if (has_value())
  return invoke(std::forward&lt;F&gt;(f), <del>**this</del><ins><i>val</i></ins>);
else
  return U(unexpect, error());
</pre></blockquote>
</blockquote>
<pre>
template&lt;class F&gt; constexpr auto and_then(F&amp;&amp; f) &amp;&amp;;
template&lt;class F&gt; constexpr auto and_then(F&amp;&amp; f) const &amp;&amp;;
</pre>
<blockquote>
<p>
-5- Let <tt>U</tt> be <tt>remove_cvref_t&lt;invoke_result_t&lt;F, decltype((std::move(<del>**this</del><ins><i>val</i></ins>))&gt;&gt;</tt>.
<p/>
-6- [&hellip;]
<p/>
-7- [&hellip;]
<p/>
-8- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
if (has_value())
  return invoke(std::forward&lt;F&gt;(f), std::move(<del>**this</del><ins><i>val</i></ins>));
else
  return U(unexpect, std::move(error()));
</pre></blockquote>
</blockquote>
<pre>
template&lt;class F&gt; constexpr auto or_else(F&amp;&amp; f) &amp;;
template&lt;class F&gt; constexpr auto or_else(F&amp;&amp; f) const &amp;;
</pre>
<blockquote>
<p>
-9- Let <tt>G</tt> be <tt>remove_cvref_t&lt;invoke_result_t&lt;F, decltype(error())&gt;&gt;</tt>.
<p/>
-10- <i>Constraints</i>: <tt>is_constructible_v&lt;T, decltype(<del>**this</del><ins>(<i>val</i>)</ins>)&gt;</tt> is <tt>true</tt>.
<p/>
-11- [&hellip;]
<p/>
-12- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
if (has_value())
  return G(in_place, <del>**this</del><ins><i>val</i></ins>);
else
  return invoke(std::forward&lt;F&gt;(f), error());
</pre></blockquote>
</blockquote>
<pre>
template&lt;class F&gt; constexpr auto or_else(F&amp;&amp; f) &amp;&amp;;
template&lt;class F&gt; constexpr auto or_else(F&amp;&amp; f) const &amp;&amp;;
</pre>
<blockquote>
<p>
-13- Let <tt>G</tt> be <tt>remove_cvref_t&lt;invoke_result_t&lt;F, decltype(std::move(error()))&gt;&gt;</tt>.
<p/>
-14- <i>Constraints</i>: <tt>is_constructible_v&lt;T, decltype(std::move(<del>**this</del><ins><i>val</i></ins>))&gt;</tt> is <tt>true</tt>.
<p/>
-15- [&hellip;]
<p/>
-16- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
if (has_value())
  return G(in_place, std::move(<del>**this</del><ins><i>val</i></ins>));
else
  return invoke(std::forward&lt;F&gt;(f), std::move(error()));
</pre></blockquote>
</blockquote>
<pre>
template&lt;class F&gt; constexpr auto transform(F&amp;&amp; f) &amp;;
template&lt;class F&gt; constexpr auto transform(F&amp;&amp; f) const &amp;;
</pre>
<blockquote>
<p>
-17- Let <tt>U</tt> be <tt>remove_cvref_t&lt;invoke_result_t&lt;F, decltype(<del>**this</del><ins>(<i>val</i>)</ins>)&gt;&gt;</tt>.
<p/>
-18- [&hellip;]
<p/>
-19- <i>Mandates</i>: <tt>U</tt> is a valid value type for <tt>expected</tt>. If <tt>is_void_v&lt;U&gt;</tt> is <tt>false</tt>, 
the declaration
</p>
<blockquote><pre>
U u(invoke(std::forward&lt;F&gt;(f), <del>**this</del><ins><i>val</i></ins>));
</pre></blockquote>
<p>
is well-formed.
<p/>
-20- <i>Effects</i>:
</p>
<ol style="list-style-type: none">
<li><p>(20.1) &mdash; [&hellip;]</p></li>
<li><p>(20.2) &mdash; Otherwise, if <tt>is_void_v&lt;U&gt;</tt> is <tt>false</tt>, returns an <tt>expected&lt;U, E&gt;</tt> 
object whose <tt><i>has_val</i></tt> member is <tt>true</tt> and <tt><i>val</i></tt> member is direct-non-list-initialized 
with <tt>invoke(std::forward&lt;F&gt;(f), <del>**this</del><ins><i>val</i></ins>)</tt>.</p></li>
<li><p>(20.3) &mdash; Otherwise, evaluates <tt>invoke(std::forward&lt;F&gt;(f), <del>**this</del><ins><i>val</i></ins>)</tt> 
and then returns <tt>expected&lt;U, E&gt;()</tt>.</p></li>
</ol>
</blockquote>
<pre>
template&lt;class F&gt; constexpr auto transform(F&amp;&amp; f) &amp;&amp;;
template&lt;class F&gt; constexpr auto transform(F&amp;&amp; f) const &amp;&amp;;
</pre>
<blockquote>
<p>
-21- Let <tt>U</tt> be <tt>remove_cvref_t&lt;invoke_result_t&lt;F, decltype(std::move(<del>**this</del><ins><i>val</i></ins>))&gt;&gt;</tt>.
<p/>
-22- [&hellip;]
<p/>
-23- <i>Mandates</i>: <tt>U</tt> is a valid value type for <tt>expected</tt>. If <tt>is_void_v&lt;U&gt;</tt> is <tt>false</tt>, 
the declaration
</p>
<blockquote><pre>
U u(invoke(std::forward&lt;F&gt;(f), std::move(<del>**this</del><ins><i>val</i></ins>)));
</pre></blockquote>
<p>
is well-formed.
<p/>
-24- <i>Effects</i>:
</p>
<ol style="list-style-type: none">
<li><p>(24.1) &mdash; [&hellip;]</p></li>
<li><p>(24.2) &mdash; Otherwise, if <tt>is_void_v&lt;U&gt;</tt> is <tt>false</tt>, returns an <tt>expected&lt;U, E&gt;</tt> 
object whose <tt><i>has_val</i></tt> member is <tt>true</tt> and <tt><i>val</i></tt> member is direct-non-list-initialized 
with <tt>invoke(std::forward&lt;F&gt;(f), std::move(<del>**this</del><ins><i>val</i></ins>))</tt>.</p></li>
<li><p>(24.3) &mdash; Otherwise, evaluates <tt>invoke(std::forward&lt;F&gt;(f), std::move(<del>**this</del><ins><i>val</i></ins>))</tt> 
and then returns <tt>expected&lt;U, E&gt;()</tt>.</p></li>
</ol>
</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>
-25- Let <tt>G</tt> be <tt>remove_cvref_t&lt;invoke_result_t&lt;F, decltype(error())&gt;&gt;</tt>.
<p/>
-26- <i>Constraints</i>: <tt>is_constructible_v&lt;T, decltype(<del>**this</del><ins>(<i>val</i>)</ins>)&gt;</tt> is <tt>true</tt>.
<p/>
-27- <i>Mandates</i>: [&hellip;]
<p/>
-28- <i>Returns</i>: If <tt>has_value()</tt> is <tt>true</tt>, <tt>expected&lt;T, G&gt;(in_place, <del>**this</del><ins><i>val</i></ins>)</tt>; 
otherwise, an <tt>expected&lt;T, G&gt;</tt> object whose <tt><i>has_val</i></tt> member is <tt>false</tt> and 
<tt><i>unex</i></tt> member is direct-non-list-initialized with <tt>invoke(std::forward&lt;F&gt;(f), error())</tt>.
</p>
</blockquote>
<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>
-29- Let <tt>G</tt> be <tt>remove_cvref_t&lt;invoke_result_t&lt;F, decltype(std::move(error()))&gt;&gt;</tt>.
<p/>
-30- <i>Constraints</i>: <tt>is_constructible_v&lt;T, decltype(std::move(<del>**this</del><ins><i>val</i></ins>))&gt;</tt> is <tt>true</tt>.
<p/>
-31- <i>Mandates</i>: [&hellip;]
<p/>
-32- <i>Returns</i>: If <tt>has_value()</tt> is <tt>true</tt>, <tt>expected&lt;T, G&gt;(in_place, std::move(<del>**this</del><ins><i>val</i></ins>))</tt>; 
otherwise, an <tt>expected&lt;T, G&gt;</tt> object whose <tt><i>has_val</i></tt> member is <tt>false</tt> and 
<tt><i>unex</i></tt> member is direct-non-list-initialized with <tt>invoke(std::forward&lt;F&gt;(f), std::move(error()))</tt>.
</p>
</blockquote>
</blockquote>
</li>

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


<blockquote class="note">
<p>
[<i>Drafting note:</i> Effectively replace all occurrences of <tt>value()</tt> by <tt>*val</tt>.]
</p>
</blockquote>

<blockquote>
<pre>
template&lt;class F&gt; constexpr auto and_then(F&amp;&amp; f) &amp;;
template&lt;class F&gt; constexpr auto and_then(F&amp;&amp; f) const &amp;;
</pre>
<blockquote>
<p>
-1- Let <tt>U</tt> be <tt>invoke_result_t&lt;F, decltype(<del>value()</del><ins>*val</ins>)&gt;</tt>.
<p/>
-2- [&hellip;]
<p/>
-3- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
if (*this) {
  return invoke(std::forward&lt;F&gt;(f), <del>value()</del><ins>*val</ins>);
} else {
  return remove_cvref_t&lt;U&gt;();
}
</pre></blockquote>
</blockquote>
<pre>
template&lt;class F&gt; constexpr auto and_then(F&amp;&amp; f) &amp;&amp;;
template&lt;class F&gt; constexpr auto and_then(F&amp;&amp; f) const &amp;&amp;;
</pre>
<blockquote>
<p>
-4- Let <tt>U</tt> be <tt>invoke_result_t&lt;F, decltype(std::move(<del>value()</del><ins>*val</ins>))&gt;</tt>.
<p/>
-5- [&hellip;]
<p/>
-6- <i>Effects</i>: Equivalent to:
</p>
<blockquote><pre>
if (*this) {
  return invoke(std::forward&lt;F&gt;(f), std::move(<del>value()</del><ins>*val</ins>));
} else {
  return remove_cvref_t&lt;U&gt;();
}
</pre></blockquote>
</blockquote>
<pre>
template&lt;class F&gt; constexpr auto transform(F&amp;&amp; f) &amp;;
template&lt;class F&gt; constexpr auto transform(F&amp;&amp; f) const &amp;;
</pre>
<blockquote>
<p>
-7- Let <tt>U</tt> be <tt>remove_cv_t&lt;invoke_result_t&lt;F, decltype(<del>value()</del><ins>*val</ins>)&gt;&gt;</tt>.
<p/>
-8- <i>Mandates</i>: <tt>U</tt> is a non-array object type other than <tt>in_place_t</tt> or <tt>nullopt_t</tt>. The declaration
</p>
<blockquote><pre>
U u(invoke(std::forward&lt;F&gt;(f), <del>value()</del><ins>*val</ins>));
</pre></blockquote>
<p>
is well-formed for some invented variable <tt>u</tt>.
<p/>
[&hellip;]
<p/>
-9- <i>Returns</i>: If <tt>*this</tt> contains a value, an <tt>optional&lt;U&gt;</tt> object whose contained value is 
direct-non-list-initialized with <tt>invoke(std::forward&lt;F&gt;(f), <del>value()</del><ins>*val</ins>)</tt>; otherwise, 
<tt>optional&lt;U&gt;()</tt>.
</p>
</blockquote>
<pre>
template&lt;class F&gt; constexpr auto transform(F&amp;&amp; f) &amp;&amp;;
template&lt;class F&gt; constexpr auto transform(F&amp;&amp; f) const &amp;&amp;;
</pre>
<blockquote>
<p>
-10- Let <tt>U</tt> be <tt>remove_cv_t&lt;invoke_result_t&lt;F, decltype(std::move(<del>value()</del><ins>*val</ins>))&gt;&gt;</tt>.
<p/>
-11- <i>Mandates</i>: <tt>U</tt> is a non-array object type other than <tt>in_place_t</tt> or <tt>nullopt_t</tt>. The declaration
</p>
<blockquote><pre>
U u(invoke(std::forward&lt;F&gt;(f), std::move(<del>value()</del><ins>*val</ins>)));
</pre></blockquote>
<p>
is well-formed for some invented variable <tt>u</tt>.
<p/>
[&hellip;]
<p/>
-12- <i>Returns</i>: If <tt>*this</tt> contains a value, an <tt>optional&lt;U&gt;</tt> object whose contained value is 
direct-non-list-initialized with <tt>invoke(std::forward&lt;F&gt;(f), std::move(<del>value()</del><ins>*val</ins>))</tt>; otherwise, 
<tt>optional&lt;U&gt;()</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3974" href="https://cplusplus.github.io/LWG/lwg-active.html#3974">3974</a>. <tt>mdspan::operator[]</tt> should not copy <tt>OtherIndexTypes</tt></h3>
<p><b>Section:</b> 24.7.3.6.3 <a href="https://wg21.link/mdspan.mdspan.members">[mdspan.mdspan.members]</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-08-12 <b>Last modified:</b> 2023-11-03</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The wording for <tt>mdspan</tt>'s <tt>operator[]</tt> overloads that accept <tt>span</tt> and <tt>array</tt> is in 
24.7.3.6.3 <a href="https://wg21.link/mdspan.mdspan.members">[mdspan.mdspan.members]</a> paragraphs 5 and 6:
</p>
<blockquote><pre>
template&lt;class OtherIndexType&gt;
  constexpr reference operator[](span&lt;OtherIndexType, rank()&gt; indices) const;
template&lt;class OtherIndexType&gt;
  constexpr reference operator[](const array&lt;OtherIndexType, rank()&gt;&amp; indices) const;
</pre>
<p>
-5- <i>Constraints</i>:
</p>
<ol style="list-style-type: none">
<li><p>(5.1) &mdash; <tt>is_convertible_v&lt;const OtherIndexType&amp;, index_type&gt;</tt> is <tt>true</tt>, and</p></li>
<li><p>(5.2) &mdash; <tt>is_nothrow_constructible_v&lt;index_type, const OtherIndexType&amp;&gt;</tt> is <tt>true</tt>.</p></li>
</ol>
<p>
-6- <i>Effects</i>: Let <tt>P</tt> be a parameter pack such that
</p>
<blockquote><pre>
is_same_v&lt;make_index_sequence&lt;rank()&gt;, index_sequence&lt;P...&gt;&gt;
</pre></blockquote>
<p>
is <tt>true</tt>. Equivalent to:
</p>
<blockquote><pre>
return operator[](as_const(indices[P])...);
</pre></blockquote>
</blockquote>
<p>
The equivalent code calls the other <tt>operator[]</tt> overload:
</p>
<blockquote><pre>
template&lt;class... OtherIndexTypes&gt;
  constexpr reference operator[](OtherIndexTypes... indices) const;
</pre></blockquote>
<p>
with a pack of <tt>const OtherIndexType</tt> lvalues, but we notably haven't required <tt>OtherIndexTypes</tt> to be copyable &mdash; 
we only require that we can convert them to <tt>index_type</tt>. While one could argue that the use in "<i>Effects</i>: equivalent to" 
implies a requirement of copyability, it's odd that this implicit requirement would be the only requirement for copyable 
<tt>OtherIndexTypes</tt> in the spec. We could fix this by changing the <tt>operator[]</tt> overload accepting <tt>OtherIndexTypes</tt> 
to take them by <tt>const&amp;</tt>, but that would be inconsistent with virtually every other place in the spec where types 
convertible to <tt>index_type</tt> are taken by-value. I think the best localized fix is to perform the conversion to <tt>index_type</tt> 
in the "<i>Effects</i>: equivalent to" code so the actual arguments have type <tt>index_type</tt> which we know is copyable.
</p>

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

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



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

<ol>

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

<blockquote>
<pre>
template&lt;class OtherIndexType&gt;
  constexpr reference operator[](span&lt;OtherIndexType, rank()&gt; indices) const;
template&lt;class OtherIndexType&gt;
  constexpr reference operator[](const array&lt;OtherIndexType, rank()&gt;&amp; indices) const;
</pre>
<blockquote>
<p>
-5- <i>Constraints</i>:
</p>
<ol style="list-style-type: none">
<li><p>(5.1) &mdash; <tt>is_convertible_v&lt;const OtherIndexType&amp;, index_type&gt;</tt> is <tt>true</tt>, and</p></li>
<li><p>(5.2) &mdash; <tt>is_nothrow_constructible_v&lt;index_type, const OtherIndexType&amp;&gt;</tt> is <tt>true</tt>.</p></li>
</ol>
<p>
-6- <i>Effects</i>: Let <tt>P</tt> be a parameter pack such that
</p>
<blockquote><pre>
is_same_v&lt;make_index_sequence&lt;rank()&gt;, index_sequence&lt;P...&gt;&gt;
</pre></blockquote>
<p>
is <tt>true</tt>. Equivalent to:
</p>
<blockquote><pre>
return operator[](<ins>extents_type::<i>index-cast</i>(</ins>as_const(indices[P])<ins>)</ins>...);
</pre></blockquote>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3987" href="https://cplusplus.github.io/LWG/lwg-active.html#3987">3987</a>. Including <tt>&lt;flat_<i>foo</i>&gt;</tt> doesn't provide <tt>std::begin/end</tt></h3>
<p><b>Section:</b> 25.7 <a href="https://wg21.link/iterator.range">[iterator.range]</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-08-27 <b>Last modified:</b> 2023-11-03</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#iterator.range">active issues</a> in [iterator.range].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#iterator.range">issues</a> in [iterator.range].</p>
<p><b>Discussion:</b></p>
<p>
It seems that 25.7 <a href="https://wg21.link/iterator.range">[iterator.range]</a> should also add <tt>&lt;flat_<i>foo</i>&gt;</tt> to the list as the 
latter provides a series of range access member functions such as <tt>begin/end</tt>.
</p>

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

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



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

<ol>

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

<blockquote>
<p>
-1- In addition to being available via inclusion of the <tt>&lt;iterator&gt;</tt> header, the function templates in
[iterator.range] are available when any of the following headers are included: <tt>&lt;array&gt;</tt>,
<tt>&lt;deque&gt;</tt>, <ins><tt>&lt;flat_map&gt;</tt>, <tt>&lt;flat_set&gt;</tt>,</ins> <tt>&lt;forward_list&gt;</tt>, 
<tt>&lt;list&gt;</tt>, <tt>&lt;map&gt;</tt>, <tt>&lt;regex&gt;</tt>, <tt>&lt;set&gt;</tt>, <tt>&lt;span&gt;</tt>, 
<tt>&lt;string&gt;</tt>, <tt>&lt;string_view&gt;</tt>, <tt>&lt;unordered_map&gt;</tt>, <tt>&lt;unordered_set&gt;</tt>, 
and <tt>&lt;vector&gt;</tt>.
</p>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="3990" href="https://cplusplus.github.io/LWG/lwg-active.html#3990">3990</a>. Program-defined specializations of <tt>std::tuple</tt> and <tt>std::variant</tt> can't be properly supported</h3>
<p><b>Section:</b> 22.4.4 <a href="https://wg21.link/tuple.tuple">[tuple.tuple]</a>, 22.6.3.1 <a href="https://wg21.link/variant.variant.general">[variant.variant.general]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jiang An <b>Opened:</b> 2023-08-29 <b>Last modified:</b> 2023-11-03</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
<p><b>Discussion:</b></p>
<p>
Currently, program-defined specializations of <tt>std::tuple</tt> and <tt>std::variant</tt> are not explicitly disallowed. 
However, they can't be properly supported by standard library implementations, because the corresponding <tt>std::get</tt> 
function templates have to inspect the implementation details of these types, and users have no way to make <tt>std::get</tt> 
behave correctly for a program-defined specializations.
<p/>
Perhaps we should explicitly disallow specializing <tt>std::tuple</tt> and <tt>std::variant</tt>.
</p>

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

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



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

<ol>

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

<blockquote>
<pre>
namespace std {
  template&lt;class... Types&gt;
  class tuple {
    [&hellip;]
  };

  [&hellip;]
}
</pre>
</blockquote>
<blockquote>
<p>
<ins>-?- If a program declares an explicit or partial specialization of <tt>tuple</tt>, 
the program is ill-formed, no diagnostic required.</ins>
</p>
</blockquote>

</li>

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

<blockquote>
<p>
[&hellip;]
<p/>
-3- A program that instantiates the definition of <tt>variant</tt> with no template arguments is ill-formed.
<p/>
<ins>-?- If a program declares an explicit or partial specialization of <tt>variant</tt>, 
the program is ill-formed, no diagnostic required.</ins>
</p>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="4001" href="https://cplusplus.github.io/LWG/lwg-active.html#4001">4001</a>. <tt>iota_view</tt> should provide <tt>empty</tt></h3>
<p><b>Section:</b> 26.6.4.2 <a href="https://wg21.link/range.iota.view">[range.iota.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-10-27 <b>Last modified:</b> 2023-11-03</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.iota.view">active issues</a> in [range.iota.view].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.iota.view">issues</a> in [range.iota.view].</p>
<p><b>Discussion:</b></p>
<p>
When <tt>iota_view</tt>'s template parameter is not an integer type and does not model <tt><i>advanceable</i></tt>, 
its <tt>size</tt> member will not be provided as constraints are not satisfied.
<p/>
If the type further fails to model the <tt>incrementable</tt>, this results in its <tt>view_interface</tt> base being 
unable to synthesize a valid <tt>empty</tt> member as <tt>iota_view</tt> will just be an <tt>input_range</tt> 
(<a href="https://godbolt.org/z/hG9GWvv97">demo</a>):
</p>
<blockquote><pre>
#include &lt;ranges&gt;
#include &lt;vector&gt;
#include &lt;iostream&gt;

int main() {
  std::vector&lt;int&gt; v;
  auto it = std::back_inserter(v);
  auto s = std::ranges::subrange(it, std::unreachable_sentinel);
  auto r = std::views::iota(it);
  std::cout &lt;&lt; s.empty() &lt;&lt; "\n"; // 0
  std::cout &lt;&lt; r.empty() &lt;&lt; "\n"; // <span style="color:red;font-weight:bolder">ill-formed</span>
}
</pre></blockquote>
<p>
This seems to be an oversight. I don't see a reason why <tt>iota_view</tt> doesn't provide <tt>empty</tt> 
as it does store the start and end like <tt>subrange</tt>, in which case it's easy to tell if it's empty 
just by comparing the two.
</p>

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

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



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

<ol>

<li><p>Modify 26.6.4.2 <a href="https://wg21.link/range.iota.view">[range.iota.view]</a>, class template <tt>iota_view</tt> synopsis, as indicated:</p>

<blockquote>
<blockquote><pre>
namespace std::ranges {
  [&hellip;]
  template&lt;weakly_incrementable W, semiregular Bound = unreachable_sentinel_t&gt;
    requires <i>weakly-equality-comparable-with</i>&lt;W, Bound&gt; &amp;&amp; copyable&lt;W&gt;
  class iota_view : public view_interface&lt;iota_view&lt;W, Bound&gt;&gt; {
  private:
    [&hellip;]
    W <i>value_</i> = W();                     // <i>exposition only</i>
    Bound <i>bound_</i> = Bound();             // <i>exposition only</i>
  public:
    [&hellip;]
    constexpr <i>iterator</i> begin() const;
    constexpr auto end() const;
    constexpr <i>iterator</i> end() const requires same_as&lt;W, Bound&gt;;

    <ins>constexpr bool empty() const;</ins>
    constexpr auto size() const requires <i>see below</i>;
  };
  [&hellip;]
}
</pre></blockquote>
<p>
[&hellip;]
</p>
<pre>
constexpr <i>iterator</i> end() const requires same_as&lt;W, Bound&gt;;
</pre>
<blockquote>
<p>
-14- <i>Effects</i>: Equivalent to: <tt>return <i>iterator</i>{<i>bound_</i>};</tt> 
</p>
</blockquote>
<pre>
<ins>constexpr bool empty() const;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: Equivalent to: <tt>return <i>value_</i> == <i>bound_</i>;</tt></ins>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>

</li>

</ol>





</body>
</html>
