<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="utf-8">
<title>C++ Standard Library Issues to be moved in Tokyo, Mar. 2024</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 Tokyo, Mar. 2024</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P3180R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>2024-03-15</p>
</td>
</tr>
<tr>
<td align="left">Audience:</td>
<td align="left">WG21</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Jonathan Wakely &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<ul>
<li><a href="#ready">Ready Issues</a></li>
<li><a href="#tentatively_ready">Tentatively Ready Issues</a></li>
</ul>
<h2 id="ready">Ready Issues</h2>
<hr>
<h3 id="3767"><a href="https://cplusplus.github.io/LWG/lwg-active.html#3767">3767</a>. <code>codecvt&lt;char<i>N</i>_t, char8_t, mbstate_t&gt;</code> incorrectly added to locale</h3>
<p><b>Section:</b> 30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a>, 30.4.2.5.1 <a href="https://wg21.link/locale.codecvt.general">[locale.codecvt.general]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Victor Zverovich <b>Opened:</b> 2022-09-05 <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#locale.category">issues</a> in [locale.category].</p>
<p><b>Discussion:</b></p>
<p>
Table [tab:locale.category.facets] includes the following two facets:
</p>
<ul>
<li><p><code>codecvt&lt;char16_t, char8_t, mbstate_t&gt;</code></p></li>
<li><p><code>codecvt&lt;char32_t, char8_t, mbstate_t&gt;</code></p></li>
</ul>
<p>
However, neither of those actually has anything to do with a locale and therefore 
it doesn't make sense to dynamically register them with <code>std::locale</code>. 
Instead they provide conversions between fixed encodings (UTF-8, UTF-16, UTF-32) 
that are unrelated to locale encodings other than they may happen to coincide with 
encodings of some locales by accident.
<p/>
The issue was introduced when adding <code>codecvt&lt;char[16|32]_t, char, mbstate_t&gt;</code> in 
<a href="https://wg21.link/N2035" title=" Minimal Unicode support for the standard library">N2035</a> which gave no design rationale for using <code>codecvt</code> in the first 
place. Likely it was trying to do a minimal amount of changes and copied the wording for 
<code>codecvt&lt;wchar_t, char, mbstate_t&gt;</code> but unfortunately didn't consider encoding implications.
<p/>
<a href="https://wg21.link/P0482" title=" char8_t: A type for UTF-8 characters and strings (Revision 6)">P0482</a> changed <code>char</code> to <code>char8_t</code> in these facets which 
made the issue more glaring but unfortunately, despite the breaking change, it failed to address it.
<p/>
Apart from an obvious design mistake this also adds a small overhead for every locale 
construction because the implementation has to copy these pseudo-facets for no good 
reason violating "don't pay for what you don't use" principle.
<p/>
A simple fix is to remove the two facets from table [tab:locale.category.facets] and make them 
directly constructible.
</p>

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

<p>
Set priority to 3 after reflector poll. Send to SG16 (then maybe LEWG).
</p>

<p><i>[2022-09-28; SG16 responds]</i></p>

<p>
SG16 agrees that the codecvt facets mentioned in LWG3767
"<code>codecvt&lt;char<i>N</i>_t, char8_t, mbstate_t&gt;</code>
incorrectly added to locale" are intended to be invariant
with respect to locale. Unanimously in favor.
</p>

<p><i>[Issaquah 2023-02-10; LWG issue processing]</i></p>

<p>
Removing these breaks most code using them today, because the most obvious
way to use them is via <code>use_facet</code> on a locale, which would throw
if they're removed (and because they were guaranteed to be present, code
using them might have not bothered to check for them using <code>has_facet</code>).
Instead of removing them, deprecate the guarantee that they're always present
(so move them to D.24 <a href="https://wg21.link/depr.locale.category">[depr.locale.category]</a>).
Don't bother changing the destructor.
Victor to update wording.
</p>

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

<p>
This wording is relative to <a href="https://wg21.link/N4917" title=" Working Draft, Standard for Programming Language C++">N4917</a>.
</p>

<ol>

<li><p>Modify 30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a>, Table 105 ([tab:locale.category.facets]) &mdash; 
"Locale category facets" &mdash; as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 105: Locale category facets [tab:locale.category.facets]</caption>
<tr>
<th align="center">Category</th>
<th align="center">Includes facets</th>
</tr>

<tr>
<td colspan="2" align="center">
<code>&hellip;</code>
</td>
</tr>

<tr>
<td>
ctype
</td>

<td>
<code>ctype&lt;char&gt;, ctype&lt;wchar_t&gt;<br/>
codecvt&lt;char, char, mbstate_t&gt;<br/>
<del>codecvt&lt;char16_t, char8_t, mbstate_t&gt;</del><br/>
<del>codecvt&lt;char32_t, char8_t, mbstate_t&gt;</del><br/>
codecvt&lt;wchar_t, char, mbstate_t&gt;</code>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<code>&hellip;</code>
</td>
</tr>

</table>
</blockquote>

</li>

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

<blockquote>
<blockquote>
<pre>
namespace std {
  [&hellip;]
  template&lt;class internT, class externT, class stateT&gt;
    class codecvt : public locale::facet, public codecvt_base {
    public:
      using intern_type = internT;
      using extern_type = externT;
      using state_type = stateT;

      explicit codecvt(size_t refs = 0);
      <ins>~codecvt();</ins>

      [&hellip;]
    protected:
      <del>~codecvt();</del>
      [&hellip;]
    };
}
</pre>
</blockquote>
<p>
[&hellip;]
<p/>
-3- The specializations required in Table <del>105 [tab:locale.category.facets]</del><ins>106 [tab:locale.spec]</ins>
(30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a>) convert the implementation-defined native character set. 
<code>codecvt&lt;char, char, mbstate_t&gt;</code> implements a degenerate conversion; it does not 
convert at all. The specialization <code>codecvt&lt;char16_t, char8_t, mbstate_t&gt;</code> converts 
between the UTF-16 and UTF-8 encoding forms, and the specialization 
<code>codecvt&lt;char32_t, char8_t, mbstate_t&gt;</code> converts between the UTF-32 and UTF-8 encoding forms. 
<code>codecvt&lt;wchar_t, char, mbstate_t&gt;</code> converts between the native character sets for ordinary 
and wide characters. Specializations on <code>mbstate_t</code> perform conversion between encodings known to 
the library implementer. Other encodings can be converted by specializing on a program-defined 
<code>stateT</code> type. Objects of type <code>stateT</code> can contain any state that is useful to communicate 
to or from the specialized <code>do_in</code> or <code>do_out</code> members.
</p>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2023-02-10; Victor Zverovich comments and provides improved wording]</i></p>

<p>
Per today's LWG discussion the following changes have been implemented in revised wording:
</p>
<ul>
<li><p>Deprecated the facets instead of removing them (also <code>_byname</code> variants which were previously missed).</p></li>
<li><p>Removed the changes to facet dtor since with deprecation it's no longer critical to provide other ways to access them.</p></li>
</ul>
<p><i>[Kona 2023-11-07; move to Ready]</i></p>




<p id="res-3767"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4928" title=" Working Draft, Standard for Programming Language C++">N4928</a>.
</p>

<ol>

<li><p>Modify 30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a>, Table 105 ([tab:locale.category.facets]) &mdash; 
"Locale category facets" &mdash; and Table 106 ([tab:locale.spec]) "Required specializations" as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 105: Locale category facets [tab:locale.category.facets]</caption>
<tr>
<th align="center">Category</th>
<th align="center">Includes facets</th>
</tr>

<tr>
<td colspan="2" align="center">
<code>&hellip;</code>
</td>
</tr>

<tr>
<td>
ctype
</td>

<td>
<code>ctype&lt;char&gt;, ctype&lt;wchar_t&gt;<br/>
codecvt&lt;char, char, mbstate_t&gt;<br/>
<del>codecvt&lt;char16_t, char8_t, mbstate_t&gt;</del><br/>
<del>codecvt&lt;char32_t, char8_t, mbstate_t&gt;</del><br/>
codecvt&lt;wchar_t, char, mbstate_t&gt;</code>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<code>&hellip;</code>
</td>
</tr>

</table>
[&hellip;]
<table border="1">
<caption>Table 106: Required specializations [tab:locale.spec]</caption>
<tr>
<th align="center">Category</th>
<th align="center">Includes facets</th>
</tr>

<tr>
<td colspan="2" align="center">
<code>&hellip;</code>
</td>
</tr>

<tr>
<td>
ctype
</td>

<td>
<code>ctype_byname&lt;char&gt;, ctype_byname&lt;wchar_t&gt;<br/>
codecvt_byname&lt;char, char, mbstate_t&gt;<br/>
<del>codecvt_byname&lt;char16_t, char8_t, mbstate_t&gt;</del><br/>
<del>codecvt_byname&lt;char32_t, char8_t, mbstate_t&gt;</del><br/>
codecvt_byname&lt;wchar_t, char, mbstate_t&gt;</code>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<code>&hellip;</code>
</td>
</tr>

</table>
</blockquote>

</li>

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

<blockquote>
<p>
[&hellip;]
<p/>
-3- The specializations required in Table 105 (30.3.1.2.1 <a href="https://wg21.link/locale.category">[locale.category]</a>) 
convert the implementation-defined native character set. 
<code>codecvt&lt;char, char, mbstate_t&gt;</code> implements a degenerate conversion; it does not 
convert at all. <del>The specialization <code>codecvt&lt;char16_t, char8_t, mbstate_t&gt;</code> converts 
between the UTF-16 and UTF-8 encoding forms, and the specialization 
<code>codecvt&lt;char32_t, char8_t, mbstate_t&gt;</code> converts between the UTF-32 and UTF-8 encoding forms.</del> 
<code>codecvt&lt;wchar_t, char, mbstate_t&gt;</code> converts between the native character sets for ordinary 
and wide characters. Specializations on <code>mbstate_t</code> perform conversion between encodings known to 
the library implementer. Other encodings can be converted by specializing on a program-defined 
<code>stateT</code> type. Objects of type <code>stateT</code> can contain any state that is useful to communicate 
to or from the specialized <code>do_in</code> or <code>do_out</code> members.
</p>
</blockquote>
</li>


<li><p>Modify D.24 <a href="https://wg21.link/depr.locale.category">[depr.locale.category]</a> (Deprecated locale category facets) in Annex D as indicated:</p>

<blockquote>
<p>
-1- The <code>ctype</code> locale category includes the following facets as if they were specified in table Table 105
[tab:locale.category.facets] of 30.4.2.5.1 <a href="https://wg21.link/locale.codecvt.general">[locale.codecvt.general]</a>.
</p>
<blockquote><pre>
codecvt&lt;char16_t, char, mbstate_t&gt;
codecvt&lt;char32_t, char, mbstate_t&gt;
<ins>codecvt&lt;char16_t, char8_t, mbstate_t&gt;
codecvt&lt;char32_t, char8_t, mbstate_t&gt;</ins>
</pre></blockquote>
<p>
-1- The <code>ctype</code> locale category includes the following facets as if they were specified in table Table 106
[tab:locale.spec] of 30.4.2.5.1 <a href="https://wg21.link/locale.codecvt.general">[locale.codecvt.general]</a>.
</p>
<blockquote><pre>
codecvt_byname&lt;char16_t, char, mbstate_t&gt;
codecvt_byname&lt;char32_t, char, mbstate_t&gt;
<ins>codecvt_byname&lt;char16_t, char8_t, mbstate_t&gt;
codecvt_byname&lt;char32_t, char8_t, mbstate_t&gt;</ins>
</pre></blockquote>
<p>
-3- The following class template specializations are required in addition to those specified in 30.4.2.5 <a href="https://wg21.link/locale.codecvt">[locale.codecvt]</a>. 
The specialization<ins>s</ins> <code>codecvt&lt;char16_t, char, mbstate_t&gt;</code> <ins>and <code>codecvt&lt;char16_t, char8_t, mbstate_t&gt;</code></ins> 
convert<del>s</del> between the UTF-16 and UTF-8 encoding forms, and the specialization<ins>s</ins> 
<code>codecvt&lt;char32_t, char, mbstate_t&gt;</code> <ins>and <code>codecvt&lt;char32_t, char8_t, mbstate_t&gt;</code></ins> 
convert<del>s</del> between the UTF-32 and UTF-8 encoding forms.
</p>
</blockquote>
</li>

</ol>





<hr>
<h3 id="3919"><a href="https://cplusplus.github.io/LWG/lwg-active.html#3919">3919</a>. <code>enumerate_view</code> may invoke UB for sized common non-forward underlying ranges</h3>
<p><b>Section:</b> 26.7.23 <a href="https://wg21.link/range.enumerate">[range.enumerate]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Patrick Palka <b>Opened:</b> 2023-04-07 <b>Last modified:</b> 2023-11-10</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
For a sized common range, <code>enumerate_view::end()</code> is specified to call
<code>ranges::distance</code>. But <code>ranges::distance</code> is not necessarily well-defined
for a sized non-forward range after calling <code>ranges::begin</code> (according to
26.4.3 <a href="https://wg21.link/range.sized">[range.sized]</a>).
<p/>
So for a sized common non-forward underlying range, it seems calling
<code>enumerate_view::begin()</code> followed by <code>enumerate_view::end()</code> may invoke UB
and thus make <code>enumerate_view</code> potentially unusable for such ranges.
<p/>
I suppose we might need to instead call and cache the result of
<code>ranges::distance</code> from <code>enumerate_view::begin()</code> for such ranges.
</p>

<p><i>[2022-04-12; Patrick Palka provides wording]</i></p>

<p>
The proposed wording follows the suggestion provided by Tim Song, to simply make <code>enumerate</code> non-common for this case.
</p>

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

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

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




<p id="res-3919"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4944" title=" Working Draft, Standard for Programming Language C++">N4944</a>.
</p>

<ol>
<li>
<p>Modify 26.7.23.2 <a href="https://wg21.link/range.enumerate.view">[range.enumerate.view]</a>, class template class <code>enumerate_view</code> synopsis, as indicated:</p>

<blockquote>
<blockquote><pre>
[&hellip;]
constexpr auto end() requires (!<i>simple-view</i>&lt;V&gt;) {
  if constexpr (<ins>forward_range&lt;V&gt; &amp;&amp;</ins> common_range&lt;V&gt; &amp;&amp; sized_range&lt;V&gt;)
    return <i>iterator</i>&lt;false&gt;(ranges::end(<i>base_</i>), ranges::distance(<i>base_</i>));
  else
    return <i>sentinel</i>&lt;false&gt;(ranges::end(<i>base_</i>));
}
constexpr auto end() const requires <i>range-with-movable-references</i>&lt;const V&gt; {
  if constexpr (<ins>forward_range&lt;const V&gt; &amp;&amp;</ins> common_range&lt;const V&gt; &amp;&amp; sized_range&lt;const V&gt;)
    return <i>iterator</i>&lt;true&gt;(ranges::end(<i>base_</i>), ranges::distance(<i>base_</i>));
  else
    return <i>sentinel</i>&lt;true&gt;(ranges::end(<i>base_</i>));
}
[&hellip;]
</pre></blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3 id="3950"><a href="https://cplusplus.github.io/LWG/lwg-active.html#3950">3950</a>. <code>std::basic_string_view</code> comparison operators are overspecified</h3>
<p><b>Section:</b> 23.3.2 <a href="https://wg21.link/string.view.synop">[string.view.synop]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Giuseppe D'Angelo <b>Opened:</b> 2023-06-21 <b>Last modified:</b> 2023-11-10</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The <code>&lt;string_view&gt;</code> synopsis in 23.3.2 <a href="https://wg21.link/string.view.synop">[string.view.synop]</a> has these signatures
for <code>operator==</code> and <code>operator&lt;=&gt;</code>:
</p>
<blockquote><pre>
// <i>23.3.4 <a href="https://wg21.link/string.view.comparison">[string.view.comparison]</a>, non-member comparison functions</i>
template&lt;class charT, class traits&gt;
  constexpr bool operator==(basic_string_view&lt;charT, traits&gt; x,
                            basic_string_view&lt;charT, traits&gt; y) noexcept;
template&lt;class charT, class traits&gt;
  constexpr see below operator&lt;=&gt;(basic_string_view&lt;charT, traits&gt; x,
                                  basic_string_view&lt;charT, traits&gt; y) noexcept;

// <i>see 23.3.4 <a href="https://wg21.link/string.view.comparison">[string.view.comparison]</a>, sufficient additional overloads of comparison functions</i>
</pre></blockquote>
<p>
In 23.3.4 <a href="https://wg21.link/string.view.comparison">[string.view.comparison]</a>, paragraph 1 states that "Implementations
shall provide sufficient additional overloads" so that all comparisons
between a <code>basic_string_view&lt;C, T&gt;</code> object and an object of a type
convertible to <code>basic_string_view&lt;C, T&gt;</code> work (with the reasonable
semantics).
<p/>
The associated Example 1 proposes this implementation strategy for
<code>operator==</code>:
</p>
<blockquote><pre>
template&lt;class charT, class traits&gt;
  constexpr bool operator==(basic_string_view&lt;charT, traits&gt; lhs,
                            basic_string_view&lt;charT, traits&gt; rhs) noexcept {
    return lhs.compare(rhs) == 0;
  }
template&lt;class charT, class traits&gt;
  constexpr bool operator==(basic_string_view&lt;charT, traits&gt; lhs,
                            type_identity_t&lt;basic_string_view&lt;charT, traits&gt;&gt; rhs) noexcept {
    return lhs.compare(rhs) == 0;
  }
</pre></blockquote>
<p>
With the current semantics of rewritten candidates for the comparison
operators, it is however superfluous to actually specify both overloads
(the same applies for <code>operator&lt;=&gt;</code>).
<p/>
The second overload (using <code>type_identity_t</code>) is indeed necessary to
implement the "sufficient additional overloads" part of 23.3.4 <a href="https://wg21.link/string.view.comparison">[string.view.comparison]</a>, 
but it is also sufficient, as all the following cases
</p>
<ul>
<li><p><code>sv == sv</code></p></li>
<li><p><code>sv == <i>convertible_to_sv</i></code></p></li>
<li><p><code><i>convertible_to_sv</i> == sv</code></p></li>
</ul>
<p>
can in fact use it (directly, or after being rewritten e.g. with the
arguments swapped).
<p/>
The reason why we still do have both operators seems to be historical;
there is an explanation offered <a href="https://stackoverflow.com/a/70851101">here</a> by Barry Revzin.
<p/>
Basically, there were three overloads before a bunch of papers regarding
<code>operator&lt;=&gt;</code> and <code>operator==</code> were merged:
</p>
<ol>
<li><p><code>operator==(<i>bsv</i>, <i>bsv</i>)</code> to deal with <code>sv == sv</code>;</p></li>
<li><p><code>operator==(<i>bsv</i>, type_identity_t&lt;<i>bsv</i>&gt;)</code> and</p></li>
<li><p><code>operator==(type_identity_t&lt;<i>bsv</i>&gt;, <i>bsv</i>)</code> to deal with 
<code>sv == <i>convertible_to_sv</i></code> and vice versa.</p></li>
</ol>
<p>
Overload (1) was necessary because with only (2) and (3) a call like 
<code>sv == sv</code> would otherwise be ambiguous. With the adoption of the rewriting
rules, overload (3) has been dropped, without realizing that overload
(1) would then become redundant.
<p/>
The specification of these overloads can be greatly simplified by
adjusting the signatures to explicitly use <code>type_identity_t</code>.
</p>

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

<p>
Editorial issue <a href="https://github.com/cplusplus/draft/pull/6324">6324</a>
provides the changes as a pull request to the draft.
</p>


<p id="res-3950"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4950" title=" Working Draft, Standard for Programming Language C++">N4950</a>.
</p>

<ol>
<li><p>Modify 23.3.2 <a href="https://wg21.link/string.view.synop">[string.view.synop]</a>, header <code>&lt;string_view&gt;</code> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
// <i>23.3.4 <a href="https://wg21.link/string.view.comparison">[string.view.comparison]</a>, non-member comparison functions</i>
template&lt;class charT, class traits&gt;
  constexpr bool operator==(basic_string_view&lt;charT, traits&gt; x,
                            <ins>type_identity_t&lt;</ins>basic_string_view&lt;charT, traits&gt;<ins>&gt;</ins> y) noexcept;

template&lt;class charT, class traits&gt;
  constexpr <i>see below</i> operator&lt;=&gt;(basic_string_view&lt;charT, traits&gt; x,
                                  <ins>type_identity_t&lt;</ins>basic_string_view&lt;charT, traits&gt;<ins>&gt;</ins> y) noexcept;

<del>// <i>see 23.3.4 <a href="https://wg21.link/string.view.comparison">[string.view.comparison]</a>, sufficient additional overloads of comparison functions</i></del>
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<p>
<del>-1- Let <code>S</code> be <code>basic_string_view&lt;charT, traits&gt;</code>, and <code>sv</code> be an instance of <code>S</code>. 
Implementations shall provide sufficient additional overloads marked <code>constexpr</code> and <code>noexcept</code> so that an 
object <code>t</code> with an implicit conversion to <code>S</code> can be compared according to Table 81 
[tab:string.view.comparison.overloads].</del>
</p>

<table border="1">
<caption><del>Table 81: Additional <code>basic_string_view</code> comparison overloads [tab:string.view.comparison.overloads]</del></caption>
<tr>
<th align="center"><del>Expression</del></th>
<th align="center"><del>Equivalent to</del></th>
</tr>

<tr>
<td><del>
<code>t == sv</code>
</del></td>
<td><del>
<code>S(t) == sv</code>
</del></td>
</tr>

<tr>
<td><del>
<code>sv == t</code>
</del></td>
<td><del>
<code>sv == S(t)</code>
</del></td>
</tr>

<tr>
<td><del>
<code>t != sv</code>
</del></td>
<td><del>
<code>S(t) != sv</code>
</del></td>
</tr>

<tr>
<td><del>
<code>sv != t</code>
</del></td>
<td><del>
<code>sv != S(t)</code>
</del></td>
</tr>

<tr>
<td><del>
<code>t &lt; sv</code>
</del></td>
<td><del>
<code>S(t) &lt; sv</code>
</del></td>
</tr>

<tr>
<td><del>
<code>sv &lt; t</code>
</del></td>
<td><del>
<code>sv &lt; S(t)</code>
</del></td>
</tr>

<tr>
<td><del>
<code>t &gt; sv</code>
</del></td>
<td><del>
<code>S(t) &gt; sv</code>
</del></td>
</tr>

<tr>
<td><del>
<code>sv &gt; t</code>
</del></td>
<td><del>
<code>sv &gt; S(t)</code>
</del></td>
</tr>

<tr>
<td><del>
<code>t &lt;= sv</code>
</del></td>
<td><del>
<code>S(t) &lt;= sv</code>
</del></td>
</tr>

<tr>
<td><del>
<code>sv &lt;= t</code>
</del></td>
<td><del>
<code>sv &lt;= S(t)</code>
</del></td>
</tr>

<tr>
<td><del>
<code>t &gt;= sv</code>
</del></td>
<td><del>
<code>S(t) &gt;= sv</code>
</del></td>
</tr>

<tr>
<td><del>
<code>sv &gt;= t</code>
</del></td>
<td><del>
<code>sv &gt;= S(t)</code>
</del></td>
</tr>

<tr>
<td><del>
<code>t &lt;=&gt; sv</code>
</del></td>
<td><del>
<code>S(t) &lt;=&gt; sv</code>
</del></td>
</tr>

<tr>
<td><del>
<code>sv &lt;=&gt; t</code>
</del></td>
<td><del>
<code>sv &lt;=&gt; S(t)</code>
</del></td>
</tr>

</table>
<p>
<del>[<i>Example 1</i>: A sample conforming implementation for <code>operator==</code> would be:</del>
</p>
<blockquote><pre>
<del>template&lt;class charT, class traits&gt;
  constexpr bool operator==(basic_string_view&lt;charT, traits&gt; lhs,
                            basic_string_view&lt;charT, traits&gt; rhs) noexcept {
    return lhs.compare(rhs) == 0;
  }
template&lt;class charT, class traits&gt;
  constexpr bool operator==(basic_string_view&lt;charT, traits&gt; lhs,
                            type_identity_t&lt;basic_string_view&lt;charT, traits&gt;&gt; rhs) noexcept {
    return lhs.compare(rhs) == 0;
  }</del>
</pre></blockquote>
<p>
<del>&mdash; <i>end example</i>]</del>
</p>
<pre>
template&lt;class charT, class traits&gt;
  constexpr bool operator==(basic_string_view&lt;charT, traits&gt; lhs,
                            <ins>type_identity_t&lt;</ins>basic_string_view&lt;charT, traits&gt;<ins>&gt;</ins> rhs) noexcept;

</pre>
<blockquote>
<p>
-2- <i>Returns:</i> <code>lhs.compare(rhs) == 0</code>.
</p>
</blockquote>
<pre>
template&lt;class charT, class traits&gt;
  constexpr <i>see below</i> operator&lt;=&gt;(basic_string_view&lt;charT, traits&gt; lhs,
                                  <ins>type_identity_t&lt;</ins>basic_string_view&lt;charT, traits&gt;<ins>&gt;</ins> rhs) noexcept;
</pre>
<blockquote>
<p>
-3- Let <code>R</code> denote the type <code>traits::comparison_category</code> if that <i>qualified-id</i> is valid and denotes a
type (13.10.3 <a href="https://wg21.link/temp.deduct">[temp.deduct]</a>), otherwise <code>R</code> is <code>weak_ordering</code>.
<p/>
-4- <i>Mandates</i>: <code>R</code> denotes a comparison category type (17.11.2 <a href="https://wg21.link/cmp.categories">[cmp.categories]</a>).
<p/>
-5- <i>Returns</i>: <code>static_cast&lt;R&gt;(lhs.compare(rhs) &lt;=&gt; 0)</code>.
<p/>
<ins> [<i>Note</i>: The usage of <code>type_identity_t</code> as parameter ensures that an object of type 
<code>basic_string_view&lt;charT, traits&gt;</code> can always be compared with an object of a type <code>T</code> 
with an implicit conversion to <code>basic_string_view&lt;charT, traits&gt;</code>, and vice versa, as per 
12.2.2.3 <a href="https://wg21.link/over.match.oper">[over.match.oper]</a>. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>

</li>

</ol>





<hr>
<h3 id="3975"><a href="https://cplusplus.github.io/LWG/lwg-active.html#3975">3975</a>. Specializations of <code>basic_format_context</code> should not be permitted</h3>
<p><b>Section:</b> 22.14.6.6 <a href="https://wg21.link/format.context">[format.context]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Brian Bi <b>Opened:</b> 2023-08-13 <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#format.context">issues</a> in [format.context].</p>
<p><b>Discussion:</b></p>
<p>
The current wording allows users to specialize <code>std::basic_format_context</code>. However, an implementation is not 
likely to accept a program that uses the library in a way that would instantiate such a specialization, because 
22.14.6.6 <a href="https://wg21.link/format.context">[format.context]</a> does not provide a complete description of the interface that such a specialization 
would need to have (e.g., it does not provide a means to initialize the exposition-only <code>args_</code> member). Since the 
library was not designed to be able to work with user specializations of <code>std::basic_format_context</code>, declaring 
such specializations should be explicitly disallowed.
</p>

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

<p>
This wording is relative to <a href="https://wg21.link/N4958" title=" Working Draft, Programming Languages — C++">N4958</a>.
</p>

<ol>

<li><p>Modify the 22.14.6.6 <a href="https://wg21.link/format.context">[format.context]</a> as indicated:</p>

<blockquote>
<p>
-1- An instance of <code>basic_format_context</code> holds formatting state consisting of the formatting arguments and
the output iterator.
<p/>
<ins>-?- The behavior of a program that adds specializations of <code>basic_format_context</code> is undefined.</ins>
<p/>
-2- <code>Out</code> shall model <code>output_iterator&lt;const charT&amp;&gt;</code>.
</p>
</blockquote>

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

<p><i>[2023-09-23; Daniel comments and provides improved wording]</i></p>

<p>
During the reflector discussion, Dietmar pointed out that the constraint can in principle be checked statically (e.g. when the 
Library creates or refers to an instantiation of <code>basic_format_context</code>), so we can reduce the rather draconian consequence of
"undefined behaviour" to "ill-formed, no diagnostics required". Furthermore, the new wording also adds the same constraint to
<code>basic_format_parse_context</code> as suggested by Tim. This is needed, since only one public constructor is specified, but
that specification does not allow to construct an object a non-zero <code>num_args_</code> or with the type information necessary 
for the <code>check_dynamic_spec*</code> functions, so the library has an unspecified way to realize this.
</p>

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

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

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




<p id="res-3975"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4958" title=" Working Draft, Programming Languages — C++">N4958</a>.
</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The suggested wording form is borrowed from exactly the same wording form used for <code>allocator_traits</code>.]
</p>
</blockquote>

<ol>

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

<blockquote>
<p>
-1- An instance of <code>basic_format_context</code> holds formatting state consisting of the formatting arguments and
the output iterator.
<p/>
<ins>-?- If a program declares an explicit or partial specialization of <code>basic_format_context</code>, the program is ill-formed,
no diagnostic required.</ins>
<p/>
-2- <code>Out</code> shall model <code>output_iterator&lt;const charT&amp;&gt;</code>.
</p>
</blockquote>

</li>

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

<blockquote>
<p>
-1- An instance of <code>basic_format_parse_context</code> holds the format string parsing state consisting of the format
string range being parsed and the argument counter for automatic indexing.
<p/>
<ins>-?- If a program declares an explicit or partial specialization of <code>basic_format_parse_context</code>, the program is ill-formed,
no diagnostic required.</ins>
</p>
</blockquote>

</li>
</ol>





<hr>
<h3 id="3984"><a href="https://cplusplus.github.io/LWG/lwg-active.html#3984">3984</a>. <code>ranges::to</code>'s recursion branch may be ill-formed</h3>
<p><b>Section:</b> 26.5.7.2 <a href="https://wg21.link/range.utility.conv.to">[range.utility.conv.to]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-08-23 <b>Last modified:</b> 2023-11-07</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.utility.conv.to">active issues</a> in [range.utility.conv.to].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.utility.conv.to">issues</a> in [range.utility.conv.to].</p>
<p><b>Discussion:</b></p>
<p>
When <code>r</code> is a nested range, <code>ranges::to</code> constructs the object recursively through <code>r | views::transform(...)</code>.
<p/>
However, the expression is ill-formed when the type of lvalue <code>r</code> does not model <code>viewable_range</code> 
(<a href="https://godbolt.org/z/98rxGz73Y">demo</a>):
</p>
<blockquote><pre>
#include &lt;ranges&gt;
#include &lt;vector&gt;
#include &lt;list&gt;

int main() {
  std::vector&lt;std::vector&lt;int&gt;&gt; v;
  auto r = std::views::all(std::move(v));
  auto l = std::ranges::to&lt;std::list&lt;std::list&lt;int&gt;&gt;&gt;(r); // <span style="color:red;font-weight:bolder">hard error in MSVC-STL and libc++</span>
}
</pre></blockquote>

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

<p>
Set priority to 3 after reflector poll.
"Should be <code>std::forward&lt;R&gt;(r)</code> instead?"
</p>

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




<p id="res-3984"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4958" title=" Working Draft, Programming Languages — C++">N4958</a>.
</p>

<ol>

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

<blockquote>
<pre>
template&lt;class C, input_range R, class... Args&gt; requires (!view&lt;C&gt;)
  constexpr C to(R&amp;&amp; r, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-1- <i>Mandates</i>: <code>C</code> is a cv-unqualified class type.
</p>
<p>
-2- <i>Returns</i>: An object of type <code>C</code> constructed from the elements of <code>r</code> in the following manner:
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; If <code>C</code> does not satisfy <code>input_range</code> or 
<code>convertible_to&lt;range_reference_t&lt;R&gt;, range_value_t&lt;C&gt;&gt;</code> is <code>true</code>:</p>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
</ol></li>
<li><p>(2.2) &mdash; Otherwise, if <code>input_range&lt;range_reference_t&lt;R&gt;&gt;</code> is <code>true</code>:
</p>
<blockquote>
<pre>
to&lt;C&gt;(<ins>ref_view(</ins>r<ins>)</ins> | views::transform([](auto&amp;&amp; elem) {
  return to&lt;range_value_t&lt;C&gt;&gt;(std::forward&lt;decltype(elem)&gt;(elem));
}), std::forward&lt;Args&gt;(args)...);
</pre>
</blockquote>
</li>
<li><p>(2.3) &mdash; Otherwise, the program is ill-formed.</p></li>
</ol>
</blockquote>
</blockquote>

</li>

</ol>





<h2 id="tentatively_ready">Tentatively Ready Issues</h2>
<hr>
<h3 id="4011"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4011">4011</a>. "<i>Effects</i>: Equivalent to return" in [span.elem]</h3>
<p><b>Section:</b> 24.7.2.2.6 <a href="https://wg21.link/span.elem">[span.elem]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Arthur O'Dwyer <b>Opened:</b> 2023-11-09 <b>Last modified:</b> 2024-03-11</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
In reviewing the wording for <a href="https://wg21.link/P2821" title=" span.at()">P2821</a> <code>span.at()</code>, it had been noticed that 
24.7.2.2.6 <a href="https://wg21.link/span.elem">[span.elem]</a> uses a lot of "<i>Effects</i>: Equivalent to return [&hellip;];" which 
could be simply "<i>Returns</i>:  [&hellip;]".
<p/>
For comparison, 23.3.3.6 <a href="https://wg21.link/string.view.access">[string.view.access]</a> uses "<i>Returns</i>: ..." instead, so I 
suggest that 24.7.2.2.6 <a href="https://wg21.link/span.elem">[span.elem]</a> should be consistent with that.
</p>

<p><i>[2024-03-11; Reflector poll]</i></p>

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



<p id="res-4011"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4964" title=" Working Draft, Programming Languages — C++">N4964</a>.
</p>

<ol>

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

<pre>
constexpr reference operator[](size_type idx) const;
</pre>
<blockquote>
<p>
-1- <i>Preconditions</i>: <code>idx &lt; size()</code> is <code>true</code>.
<p/>
-2- <i><del>Effects</del><ins>Returns</ins></i>: <del>Equivalent to:</del> <code><del>return</del> *(data() + idx)<del>;</del></code><ins>.</ins>
<p/>
<ins>-?- <i>Throws</i>: Nothing.</ins>
</p>
</blockquote>
<pre>
constexpr reference front() const;
</pre>
<blockquote>
<p>
-3- <i>Preconditions</i>: <code>empty()</code> is <code>false</code>.
<p/>
-4- <i><del>Effects</del><ins>Returns</ins></i>: <del>Equivalent to:</del> <code><del>return</del> *data()<del>;</del></code><ins>.</ins>
<p/>
<ins>-?- <i>Throws</i>: Nothing.</ins>
</p>
</blockquote>
<pre>
constexpr reference back() const;
</pre>
<blockquote>
<p>
-5- <i>Preconditions</i>: <code>empty()</code> is <code>false</code>.
<p/>
-6- <i><del>Effects</del><ins>Returns</ins></i>: <del>Equivalent to:</del> <code><del>return</del> *(data() + (size() - 1))<del>;</del></code><ins>.</ins>
<p/>
<ins>-?- <i>Throws</i>: Nothing.</ins>
</p>
</blockquote>
<pre>
constexpr pointer data() const noexcept;
</pre>
<blockquote>
<p>
-7- <i><del>Effects</del><ins>Returns</ins></i>: <del>Equivalent to:</del> <code><del>return</del> <i>data_</i><del>;</del></code><ins>.</ins>
</p>
</blockquote>

</li>

</ol>





<hr>
<h3 id="4012"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4012">4012</a>. <code>common_view::begin/end</code> are missing the <code><i>simple-view</i></code> check</h3>
<p><b>Section:</b> 26.7.19.2 <a href="https://wg21.link/range.common.view">[range.common.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-11-11 <b>Last modified:</b> 2024-03-11</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.common.view">issues</a> in [range.common.view].</p>
<p><b>Discussion:</b></p>
<p>
<code>common_view::begin/end</code> have exactly the same implementation as their corresponding <code>const</code> versions, 
which implies that when the underlying <code>V</code> satisfies <code><i>simple-view</i></code>, it is sufficient to 
just provide <code>const</code>-qualified members.
</p>

<p><i>[2024-03-11; Reflector poll]</i></p>

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



<p id="res-4012"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4964" title=" Working Draft, Programming Languages — C++">N4964</a>.
</p>

<ol>

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

<blockquote><pre>
namespace std::ranges {
  template&lt;view V&gt;
    requires (!common_range&lt;V&gt; &amp;&amp; copyable&lt;iterator_t&lt;V&gt;&gt;)
  class common_view : public view_interface&lt;common_view&lt;V&gt;&gt; {
  private:
    V <i>base_</i> = V();  // <i>exposition only</i>

  public:
    [&hellip;]
    constexpr auto begin() <ins>requires (!<i>simple-view</i>&lt;V&gt;)</ins> {
      if constexpr (random_access_range&lt;V&gt; &amp;&amp; sized_range&lt;V&gt;)
        return ranges::begin(<i>base_</i>);
      else
        return common_iterator&lt;iterator_t&lt;V&gt;, sentinel_t&lt;V&gt;&gt;(ranges::begin(<i>base_</i>));
    }

    constexpr auto begin() const requires range&lt;const V&gt; {
      if constexpr (random_access_range&lt;const V&gt; &amp;&amp; sized_range&lt;const V&gt;)
        return ranges::begin(<i>base_</i>);
      else
        return common_iterator&lt;iterator_t&lt;const V&gt;, sentinel_t&lt;const V&gt;&gt;(ranges::begin(<i>base_</i>));
    }
    
    constexpr auto end() <ins>requires (!<i>simple-view</i>&lt;V&gt;)</ins> {
      if constexpr (random_access_range&lt;V&gt; &amp;&amp; sized_range&lt;V&gt;)
        return ranges::begin(<i>base_</i>) + ranges::distance(<i>base_</i>);
      else
        return common_iterator&lt;iterator_t&lt;V&gt;, sentinel_t&lt;V&gt;&gt;(ranges::end(<i>base_</i>));
    }

    constexpr auto end() const requires range&lt;const V&gt; {
      if constexpr (random_access_range&lt;const V&gt; &amp;&amp; sized_range&lt;const V&gt;)
        return ranges::begin(<i>base_</i>) + ranges::distance(<i>base_</i>);
      else
        return common_iterator&lt;iterator_t&lt;const V&gt;, sentinel_t&lt;const V&gt;&gt;(ranges::end(<i>base_</i>));
    }

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

</li>

</ol>





<hr>
<h3 id="4013"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4013">4013</a>. <code>lazy_split_view::<i>outer-iterator</i>::value_type</code> should not provide default constructor</h3>
<p><b>Section:</b> 26.7.16.4 <a href="https://wg21.link/range.lazy.split.outer.value">[range.lazy.split.outer.value]</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-11-11 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.lazy.split.outer.value">issues</a> in [range.lazy.split.outer.value].</p>
<p><b>Discussion:</b></p>
<p>
After <a href="https://wg21.link/P2325" title=" Views should not be required to be default constructible">P2325</a>, there is no reason for <code>lazy_split_view::<i>outer-iterator</i>::value_type</code> 
to provide a default constructor, which only leads to <a href="https://godbolt.org/z/rM4WdMz79">unexpected behavior</a>:
</p>
<blockquote><pre>
#include &lt;ranges&gt;

constexpr int arr[] = {42};
constexpr auto split = arr | std::views::lazy_split(0);
static_assert(!std::ranges::range_value_t&lt;decltype(split)&gt;{});  // <span style="color:red;font-weight:bolder">UB, dereferencing a null pointer</span>
</pre></blockquote>
<p>
Also, the other constructor should be private because it makes no sense for the user to construct it arbitrarily, 
which is not the intention.
</p>

<p><i>[2024-03-11; Reflector poll]</i></p>

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



<p id="res-4013"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4964" title=" Working Draft, Programming Languages — C++">N4964</a>.
</p>

<ol>

<li><p>Modify 26.7.16.4 <a href="https://wg21.link/range.lazy.split.outer.value">[range.lazy.split.outer.value]</a>, class <code>split_view::<i>outer-iterator</i>::value_type</code> synopsis, 
as indicated:</p>

<blockquote><pre>
namespace std::ranges {
  template&lt;input_range V, forward_range Pattern&gt;
    requires view&lt;V&gt; &amp;&amp; view&lt;Pattern&gt; &amp;&amp;
             indirectly_comparable&lt;iterator_t&lt;V&gt;, iterator_t&lt;Pattern&gt;, ranges::equal_to&gt; &amp;&amp;
             (forward_range&lt;V&gt; || <i>tiny-range</i>&lt;Pattern&gt;)
  template&lt;bool Const&gt;
  struct lazy_split_view&lt;V, Pattern&gt;::<i>outer-iterator</i>&lt;Const&gt;::value_type
    : view_interface&lt;value_type&gt; {
  private:
    <i>outer-iterator i_</i> = <i>outer-iterator</i>();               <i>// exposition only</i>
  
    <ins>constexpr explicit value_type(<i>outer-iterator</i> i);    <i>// exposition only</i></ins>

  public:
    <del>value_type() = default;</del>
    <del>constexpr explicit value_type(<i>outer-iterator</i> i);</del>

    constexpr <i>inner-iterator</i>&lt;Const&gt; begin() const;
    constexpr default_sentinel_t end() const noexcept;
  };
}
</pre></blockquote>

</li>

</ol>





<hr>
<h3 id="4016"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4016">4016</a>. <code><i>container-insertable</i></code> checks do not match what <code><i>container-inserter</i></code> does</h3>
<p><b>Section:</b> 26.5.7 <a href="https://wg21.link/range.utility.conv">[range.utility.conv]</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> 2023-11-24 <b>Last modified:</b> 2024-03-11</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The exposition-only helper <code><i>container-inserter</i></code> uses either
<code>std::back_inserter</code> or <code>std::inserter</code>. Both
<code>std::back_insert_iterator</code> and <code>std::insert_iterator</code>
require <code>C::value_type</code> to be a valid type, and we do not check
for that in <code><i>container-insertable</i></code>.
The insert iterators can also incur a conversion to construct a
<code>C::value_type</code> which then gets moved into the container.
Using emplace instead of insert would avoid that temporary object.
It's also possible (although arguably not worth caring about) that
<code>range_value_t&lt;C&gt;</code> is not the same type as
<code>C::value_type</code>, and that conversion to <code>C::value_type</code>
could be ill-formed (we only check that conversion from
<code>range_reference_t&lt;R&gt;</code> to <code>range_value_t&lt;C&gt;</code>
is well-formed).
</p>
<p>
It seems preferable to remove the use of insert iterators, so that we don't
need to check their requirements at all.
</p>

<p><i>[2023-1-26; Rename exposition-only concept and function after reflector discussion.]</i></p>



<p><i>[2024-03-11; Reflector poll]</i></p>

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



<p id="res-4016"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4964" title=" Working Draft, Programming Languages — C++">N4964</a>.
</p>

<ol>

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

<blockquote>
<p>-4- Let <code><i>container-<del>insertable</del><ins>appendable</ins></i></code> be defined as follows:
<blockquote>
<pre><code>template&lt;class Container, class Ref&gt;
constexpr bool <i>container-<del>insertable</del><ins>appendable</ins></i> =         <i>// exposition only</i>
  requires(Container&amp; c, Ref&amp;&amp; ref) {
           requires (<ins>requires { c.emplace_back(std::forward&lt;Ref&gt;(ref)); } ||</ins>
                     requires { c.push_back(std::forward&lt;Ref&gt;(ref)); } ||
                     <ins>requires { c.emplace(c.end(), std::forward&lt;Ref&gt;(ref)); } ||</ins>
                     requires { c.insert(c.end(), std::forward&lt;Ref&gt;(ref)); });
};
</code></pre>
</blockquote>
</p>
<p>-5- Let <code><i>container-<del>inserter</del><ins>append</ins></i></code> be defined as follows:
<blockquote>
<pre><code>template&lt;class Container<del>, class Ref</del>&gt;
constexpr auto <i>container-<del>inserter</del><ins>append</ins></i>(Container&amp; c) {     <i>// exposition only</i>
<del>  if constexpr (requires { c.push_back(declval&lt;Ref&gt;()); })
    return back_inserter(c);
  else
    return inserter(c, c.end());</del>
<ins>  return [&amp;c]&lt;class Ref&gt;(Ref&amp;&amp; ref) {
    if constexpr (requires { c.emplace_back(declval&lt;Ref&gt;()); })
      c.emplace_back(std::forward&lt;Ref&gt;(ref));
    else if constexpr (requires { c.push_back(declval&lt;Ref&gt;()); })
      c.push_back(std::forward&lt;Ref&gt;(ref));
    else if constexpr (requires { c.emplace(c.end(), declval&lt;Ref&gt;()); })
      c.emplace(c.end(), std::forward&lt;Ref&gt;(ref));
    else
      c.insert(c.end(), std::forward&lt;Ref&gt;(ref));
  };</ins>
};
</code></pre>
</blockquote>
</p>
</blockquote>
</li>
<li><p>Modify 26.5.7.2 <a href="https://wg21.link/range.utility.conv.to">[range.utility.conv.to]</a> as indicated:</p>
<blockquote>
<p>(2.1.4) Otherwise, if
<ul style="list-style-type: none">
<li>&mdash; <code>constructible_from&lt;C, Args...&gt;</code> is <code>true</code>, and</li>
<li>&mdash; <code><i>container-<del>insertable</del><ins>appendable</ins></i>&lt;C, range_reference_t&lt;R&gt;&gt;</code> is <code>true</code>:</li>
</ul>
<blockquote>
<pre><code>
C c(std::forward&lt;Args&gt;(args)...);
if constexpr (sized_range&lt;R&gt; &amp;&amp; <i>reservable-container</i>&lt;C&gt;)
c.reserve(static_cast&lt;range_size_t&lt;C&gt;&gt;(ranges::size(r)));
ranges::<del>copy</del><ins>for_each</ins>(r, <i>container-<del>inserter</del><ins>append</ins></i><del>&lt;range_reference_t&lt;R&gt;&gt;</del>(c));
</code></pre>
</blockquote>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3 id="4023"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4023">4023</a>. Preconditions of <code>std::basic_streambuf::setg/setp</code></h3>
<p><b>Section:</b> 31.6.3.4 <a href="https://wg21.link/streambuf.protected">[streambuf.protected]</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-12-08 <b>Last modified:</b> 2024-03-11</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
It seems that operations of <code>std::basic_streambuf</code> expect that
</p>
<ul>
<li><p><code>[eback(), egptr())</code> is a valid range and <code>gptr()</code> points into that range, and</p></li>
<li><p><code>[pbase(), pptr())</code> is a valid range and <code>epptr()</code> points into that range.</p></li>
</ul>
<p>
However, it is currently not specified for <code>setg/setp</code> that such invariants need to be established.
</p>

<p><i>[2024-03-11; Reflector poll]</i></p>

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



<p id="res-4023"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4964" title=" Working Draft, Programming Languages — C++">N4964</a>.
</p>

<ol>

<li><p>Modify 31.6.3.4.2 <a href="https://wg21.link/streambuf.get.area">[streambuf.get.area]</a> as indicated:</p>

<blockquote>
<pre>
void setg(char_type* gbeg, char_type* gnext, char_type* gend);
</pre>
<blockquote>
<p>
<ins>-?- <i>Preconditions</i>: <code>[gbeg,  gnext)</code>, <code>[gbeg, gend)</code>, and <code>[gnext, gend)</code> are all valid ranges.</ins>
<p/>
-5- <i>Postconditions</i>: <code>gbeg == eback()</code>, <code>gnext == gptr()</code>, and <code>gend == egptr()</code> are all <code>true</code>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 31.6.3.4.3 <a href="https://wg21.link/streambuf.put.area">[streambuf.put.area]</a> as indicated:</p>

<blockquote>
<pre>
void setp(char_type* pbeg, char_type* pend);
</pre>
<blockquote>
<p>
<ins>-?- <i>Preconditions</i>: <code>[pbeg, pend)</code> is a valid range.</ins>
<p/>
-5- <i>Postconditions</i>: <code>pbeg == pbase()</code>, <code>pbeg == pptr()</code>, and <code>pend == epptr()</code> are all <code>true</code>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3 id="4025"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4025">4025</a>. Move assignment operator of <code>std::expected&lt;<i>cv</i> void, E&gt;</code> should not be conditionally deleted</h3>
<p><b>Section:</b> 22.8.7.4 <a href="https://wg21.link/expected.void.assign">[expected.void.assign]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jiang An <b>Opened:</b> 2023-12-16 <b>Last modified:</b> 2024-03-11</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.void.assign">issues</a> in [expected.void.assign].</p>
<p><b>Discussion:</b></p>
<p>
It seems intended that copy functions of <code>std::optional</code>, <code>std::variant</code>, and <code>std::expected</code> 
are conditionally deleted, while move functions are constrained. However, the move assignment operator of 
<code>std::expected&lt;<i>cv</i> void, E&gt;</code> is currently conditionally deleted, which is inconsistent.
</p>

<p><i>[2024-03-11; Reflector poll]</i></p>

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



<p id="res-4025"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>

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

<blockquote>
<pre>
constexpr expected&amp; operator=(expected&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints</i>: <code>is_move_constructible_v&lt;E&gt;</code> is <code>true</code> and 
<code>is_move_assignable_v&lt;E&gt;</code> is <code>true</code>.</ins>
<p/>
[&hellip;]
<p/>
-6- <i>Remarks</i>: The exception specification is equivalent to <code>is_nothrow_move_constructible_v&lt;E&gt; &amp;&amp;
is_nothrow_move_assignable_v&lt;E&gt;</code>.
<p/>
<del>-7- This operator is defined as deleted unless <code>is_move_constructible_v&lt;E&gt;</code> is <code>true</code> 
and <code>is_move_assignable_v&lt;E&gt;</code> is <code>true</code>.</del>
</p>
</blockquote>
</blockquote>
</li>

</ol>







<hr>
<h3 id="4030"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4030">4030</a>. Clarify whether arithmetic expressions in [numeric.sat.func] are mathematical or C++</h3>
<p><b>Section:</b> 27.10.17.1 <a href="https://wg21.link/numeric.sat.func">[numeric.sat.func]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas K&ouml;ppe <b>Opened:</b> 2023-12-18 <b>Last modified:</b> 2024-03-11</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
During the application of <a href="https://wg21.link/P0543R0" title=" Saturation arithmetic">P0543R0</a>, "Saturation arithmetic", it was pointed out that it 
might not be entirely clear what we want something like "<code>x</code> + <code>y</code>" to mean. The paper does not 
suggest any formatting for those symbols, and a non-normative note explains that the intention is for 
the expression to be considered mathematically.
<p/>
I wonder if this is clear enough. Notes are not normative, and the document "shall be usable without notes". 
I have formatted this as <code>$\tcode{x} + \tcode{y}$</code> throughout, i.e. the variables are in code font, 
but the symbol is maths, not code. This is quite subtle. (See also 
<a href="https://github.com/cplusplus/draft/pull/6686">GitHub discussion</a>.)
<p/>
I think it would be an improvement if we simply made the note not be a note. It seems to contain entirely reasonable, mandatory content.
</p>

<p><i>[2024-03-11; Reflector poll]</i></p>

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



<p id="res-4030"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>

<li><p>Modify 27.10.17.1 <a href="https://wg21.link/numeric.sat.func">[numeric.sat.func]</a> as indicated:</p>

<blockquote>
<p>
-1- <del>[<i>Note 1</i>:</del> In the following descriptions, an arithmetic operation is performed as a mathematical 
operation with infinite range and then it is determined whether the mathematical result fits into the result type. 
<del>&mdash; <i>end note</i>]</del>
</p>
</blockquote>

</li>

</ol>







<hr>
<h3 id="4031"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4031">4031</a>. <code>bad_expected_access&lt;void&gt;</code> member functions should be <code>noexcept</code></h3>
<p><b>Section:</b> 22.8.5 <a href="https://wg21.link/expected.bad.void">[expected.bad.void]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Cassio Neri <b>Opened:</b> 2023-12-24 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
According to 17.9.3 <a href="https://wg21.link/exception">[exception]</a>/2:
</p>
<blockquote>
<p>
Each standard library class <code>T</code> that derives from class <code>exception</code> has the following 
publicly accessible member functions, each of them having a non-throwing exception specification (14.5):
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; default constructor (unless the class synopsis shows other constructors)</p></li>
<li><p>(2.2) &mdash; copy constructor</p></li>
<li><p>(2.3) &mdash; copy assignment operator</p></li>
</ol>
</blockquote>
<p>
For good reasons, <code>bad_expected_access&lt;void&gt;</code> overrules from this general rule by 
protecting its special member functions. However, there's no reason these functions should not be 
<code>noexcept</code>.
</p>

<p><i>[2024-03-12; Reflector poll]</i></p>

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



<p id="res-4031"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>

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

<blockquote>
<pre>
namespace std {
  template&lt;&gt;
  class bad_expected_access&lt;void&gt; : public exception {
  protected:
    bad_expected_access() noexcept;
    bad_expected_access(const bad_expected_access&amp;) <ins>noexcept</ins>;
    bad_expected_access(bad_expected_access&amp;&amp;) <ins>noexcept</ins>;
    bad_expected_access&amp; operator=(const bad_expected_access&amp;) <ins>noexcept</ins>;
    bad_expected_access&amp; operator=(bad_expected_access&amp;&amp;) <ins>noexcept</ins>;
    ~bad_expected_access();
  public:
    const char* what() const noexcept override;
  };
}
</pre>
</blockquote>

</li>

</ol>







<hr>
<h3 id="4035"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4035">4035</a>. <code>single_view</code> should provide <code>empty</code></h3>
<p><b>Section:</b> 26.6.3.2 <a href="https://wg21.link/range.single.view">[range.single.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hewill Kang <b>Opened:</b> 2023-12-31 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.single.view">issues</a> in [range.single.view].</p>
<p><b>Discussion:</b></p>
<p>
Although <code>single_view::empty</code> can be synthesized through <code>view_interface</code>,
it seems more worthwhile to provide a static <code>empty</code> for it which eliminates the 
need to pass in an object parameter, guarantees <code>noexcept</code>-ness, and is consistent 
with the design of <code>empty_view</code> (<a href="https://godbolt.org/z/Yr6bhM11n">demo</a>):
</p>
<blockquote>
<pre>
#include &lt;ranges&gt;
auto empty = std::views::empty&lt;int&gt;;
static_assert(noexcept(empty.empty()));
static_assert(noexcept(empty.size()));
auto single = std::views::single(0);
static_assert(noexcept(single.empty())); // <span style="color:red;font-weight:bolder">fire</span>
static_assert(noexcept(single.size()));
</pre>
</blockquote>

<p><i>[2024-03-12; Reflector poll]</i></p>

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



<p id="res-4035"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>

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

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;move_constructible T&gt;
    requires is_object_v&lt;T&gt;
  class single_view : public view_interface&lt;single_view&lt;T&gt;&gt; {
    [&hellip;]
  public:
    [&hellip;]
    constexpr T* begin() noexcept;
    constexpr const T* begin() const noexcept;
    constexpr T* end() noexcept;
    constexpr const T* end() const noexcept;
    <ins>static constexpr bool empty() noexcept;</ins>
    static constexpr size_t size() noexcept;
    constexpr T* data() noexcept;
    constexpr const T* data() const noexcept;
  };
  [&hellip;]
}
</pre>
</blockquote>
[&hellip;]
<pre>
constexpr T* end() noexcept;
constexpr const T* end() const noexcept;
</pre>
<blockquote>
<p>
-5- <i>Effects</i>: Equivalent to: <code>return data() + 1;</code>
</p>
</blockquote>
<pre>
<ins>static constexpr bool empty() noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: Equivalent to: <code>return false;</code></ins>
</p>
</blockquote>
</blockquote>

</li>

</ol>







<hr>
<h3 id="4036"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4036">4036</a>. <code>__alignof_is_defined</code> is only implicitly specified in C++ and not yet deprecated</h3>
<p><b>Section:</b> D.11 <a href="https://wg21.link/depr.c.macros">[depr.c.macros]</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> 2024-01-12 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
Currently 17.14.4 <a href="https://wg21.link/stdalign.h.syn">[stdalign.h.syn]</a> states
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
The contents of the C++ header <code>&lt;stdalign.h&gt;</code> are the same as the C standard library header 
<code>&lt;stdalign.h&gt;</code>, with the following changes: The header <code>&lt;stdalign.h&gt;</code> does not 
define a macro named <code>alignas</code>.
<p/>
<span style="font-variant: small-caps">See also</span>: ISO/IEC 9899:2018, 7.15
</p>
</blockquote>
<p>
which implicitly specifies that <code>__alignof_is_defined</code> is also provided in C++, because C17 
specified that the macro is provided in <code>&lt;stdaligh.h&gt;</code>.
<p/>
However, there's no explicit mentioning of <code>__alignof_is_defined</code> in the C++ standard wording. 
And D.11 <a href="https://wg21.link/depr.c.macros">[depr.c.macros]</a>/1 (added by LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3827" title="Deprecate &lt;stdalign.h&gt; and &lt;stdbool.h&gt; macros">3827</a>) seemingly contradicts with 
17.14.4 <a href="https://wg21.link/stdalign.h.syn">[stdalign.h.syn]</a> and only makes <code>__alignas_is_defined</code> deprecated.
<p/>
It seems that we should explicitly mention <code>__alignof_is_defined</code> in D.11 <a href="https://wg21.link/depr.c.macros">[depr.c.macros]</a> 
at this moment.
</p>

<p><i>[2024-03-12; Reflector poll]</i></p>

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



<p id="res-4036"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>

<li><p>Modify D.11 <a href="https://wg21.link/depr.c.macros">[depr.c.macros]</a> as indicated:</p>

<blockquote>
<p>
-1- The header <code>&lt;stdalign.h&gt;</code> has the following macro<ins>s</ins>:
</p>
<blockquote>
<pre>
#define __alignas_is_defined 1
<ins>#define __alignof_is_defined 1</ins>
</pre>
</blockquote>
</blockquote>

</li>

</ol>







<hr>
<h3 id="4037"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4037">4037</a>. Static data members of <code>ctype_base</code> are not yet required to be usable in constant expressions</h3>
<p><b>Section:</b> 30.4.2.1 <a href="https://wg21.link/category.ctype.general">[category.ctype.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> 2024-01-12 <b>Last modified:</b> 2024-01-14</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
It may be desired that static data members <code>ctype_base</code> are "real constants", i.e. usable in constant expressions. 
However, this is not strictly required because <code>mask</code> is only required to be a bitmask type that can be a class type, 
which makes the plain <code>const</code> potentially insufficient.
</p>

<p><i>[2024-03-12; Reflector poll]</i></p>

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



<p id="res-4037"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>

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

<blockquote>
<blockquote>
<pre>
namespace std {
  class ctype_base {
  public:
    using mask = <i>see below</i>;

    // <i>numeric values are for exposition only.</i>
    static const<ins>expr</ins> mask space  = 1 &lt;&lt; 0;
    static const<ins>expr</ins> mask print  = 1 &lt;&lt; 1;
    static const<ins>expr</ins> mask cntrl  = 1 &lt;&lt; 2;
    static const<ins>expr</ins> mask upper  = 1 &lt;&lt; 3;
    static const<ins>expr</ins> mask lower  = 1 &lt;&lt; 4;
    static const<ins>expr</ins> mask alpha  = 1 &lt;&lt; 5;
    static const<ins>expr</ins> mask digit  = 1 &lt;&lt; 6;
    static const<ins>expr</ins> mask punct  = 1 &lt;&lt; 7;
    static const<ins>expr</ins> mask xdigit = 1 &lt;&lt; 8;
    static const<ins>expr</ins> mask blank  = 1 &lt;&lt; 9;
    static const<ins>expr</ins> mask alnum  = alpha | digit;
    static const<ins>expr</ins> mask graph  = alnum | punct;
  };
}
</pre>
</blockquote>
<p>
-1- The type <code>mask</code> is a bitmask type (16.3.3.3.3 <a href="https://wg21.link/bitmask.types">[bitmask.types]</a>).
</p>
</blockquote>


</li>

</ol>







<hr>
<h3 id="4038"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4038">4038</a>. <code>std::text_encoding::aliases_view</code> should have constexpr iterators</h3>
<p><b>Section:</b> 30.6.2.5 <a href="https://wg21.link/text.encoding.aliases">[text.encoding.aliases]</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> 2024-01-16 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<code>aliases_view::begin()</code> and <code>aliases_view::end()</code>
are constexpr functions, but there is no requirement that you can use
the returned iterator and sentinel in constant expressions.
</p>

<p><i>[2024-03-12; Reflector poll]</i></p>

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



<p id="res-4038"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>
<li><p>Modify 30.6.2.5 <a href="https://wg21.link/text.encoding.aliases">[text.encoding.aliases]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
struct text_encoding::aliases_view : ranges::view_interface&lt;text_encoding::aliases_view&gt; {
  constexpr <i>implementation-defined</i> begin() const;
  constexpr <i>implementation-defined</i> end() const;
};
</pre>
</blockquote>
<p>
-1-
<code>text_encoding::aliases_view</code> models <code>copyable</code>,
<code>ranges::view</code>, <code>ranges::random_access_range</code>,
and <code>ranges::borrowed_range</code>.
</p>
<p>
-2-
Both <code>ranges::range_value_t&lt;text_encoding::aliases_view&gt;</code>
and <code>ranges::range_reference_t&lt;text_encoding::aliases_view&gt;</code>
denote <code>const char*</code>.
</p>
<p>
<ins>
-?-
<code>ranges::iterator_t&lt;text_encoding::aliases_view&gt;</code>
is a constexpr iterator (25.3.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a>).
</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3 id="4043"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4043">4043</a>. <code>"ASCII"</code> is not a registered character encoding</h3>
<p><b>Section:</b> 30.6.2.2 <a href="https://wg21.link/text.encoding.general">[text.encoding.general]</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> 2024-01-23 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The IANA Charater Sets registry does not contain "ASCII" as an alias of the
"US-ASCII" encoding. This is apparently for historical reasons, because there
used to be some ambiguity about exactly what "ASCII" meant. I don't think
those historical reasons are relevant to C++26, but the absence of "ASCII"
in the IANA registry means that it's not a registered character encoding
as defined by 30.6.2.2 <a href="https://wg21.link/text.encoding.general">[text.encoding.general]</a>.
</p>

<p>
This means that the encoding referred to by notes in the C++ standard
(31.12.6.2 <a href="https://wg21.link/fs.path.generic">[fs.path.generic]</a>, 30.4.4.1.3 <a href="https://wg21.link/facet.numpunct.virtuals">[facet.numpunct.virtuals]</a>)
and by an example in the <code>std::text_encoding</code> proposal
(<a href="https://wg21.link/P1885" title=" Naming Text Encodings to Demystify Them">P1885</a>) isn't actually usable in portable code.
So <code>std::text_encoding("ASCII")</code> creates an object with
<code>mib() == std::text_encoding::other</code>, which is not the same
encoding as <code>std::text_encoding("US-ASCII")</code>.
This seems surprising.
</p>

<p><i>[2024-03-12; Reflector poll]</i></p>

<p>
SG16 approved the proposed resolution.
Set status to Tentatively Ready after seven votes in favour during reflector poll.
</p>



<p id="res-4043"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

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

<blockquote>
<p>-1-
A <i>registered character encoding</i> is a character encoding scheme
in the IANA Character Sets registry.
</p>
<p>
[<i>Note 1</i>:
The IANA Character Sets registry uses the term “character sets” to refer to character encodings.
&mdash; <i>end note</i>]
</p>
<p>
The primary name of a registered character encoding is the name
of that encoding specified in the IANA Character Sets registry.
</p>

<p>-2-
The set of known registered character encodings contains every
registered character encoding specified in the IANA Character Sets registry
except for the following:
<ol style="list-style-type: none">
<li>(2.1) &ndash; NATS-DANO (33)</li>
<li>(2.2) &ndash; NATS-DANO-ADD (34)</li>
</ol>
</p>

<p>-3-
Each known registered character encoding is identified by an enumerator in
<code>text_encoding::id</code>, and has a set of zero or more <i>aliases</i>.
</p>

<p>-4-
The set of aliases of a known registered character encoding is an
implementation-defined superset of the aliases specified in the
IANA Character Sets registry.
<ins>The set of aliases for US-ASCII includes <code>"ASCII"</code>.</ins>
No two aliases or primary names of distinct registered character encodings
are equivalent when compared by <code>text_encoding::<i>comp-name</i></code>.
</p>

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






<hr>
<h3 id="4045"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4045">4045</a>. <code>tuple</code> can create dangling references from <code><i>tuple-like</i></code></h3>
<p><b>Section:</b> 22.4.4.2 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</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> 2024-01-24 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P2165R4" title=" Compatibility between tuple, pair and tuple-like objects">P2165R4</a>
(Compatibility between tuple, pair and tuple-like objects)
added two new constructors to <code>std::tuple</code>:
</p>
<pre><code>
  template&lt;tuple-likeUTuple&gt;
    constexpr explicit(see below ) tuple(UTuple&amp;&amp; u);
</code></pre>
<p>
and the allocator-extended equivalent.
Unlike the existing constructors taking a single parameter of tuple type,
these new constructors are not defined as deleted if they would create a
dangling reference to a temporary. The existing constructors gained that
restriction from
<a href="https://wg21.link/P2255R2" title=" A type trait to detect reference binding to temporary">P2255R2</a>
(A type trait to detect reference binding to temporary)
which was approved one meeting before
<a href="https://wg21.link/P2165R4" title=" Compatibility between tuple, pair and tuple-like objects">P2165R4</a>
so LWG seem to have missed the inconsistency.
</p>
<p>
The proposal also added a new constructor for <code>std::pair</code>:
</p>
<pre><code>
  template&lt;pair-like P&gt; constexpr explicit(<i>see below</i>) pair(P&amp;&amp; p);
</code></pre>
<p>
This <em>is</em> deleted if it would create a dangling reference,
although that seems to be an almost accidental consequence of adding
the new signature after existing ones which already have the <em>Remarks</em>:
about being deleted.
</p>

<p><i>[2024-03-12; Reflector poll]</i></p>

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



<p id="res-4045"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>
<ol>
<li><p>Modify 22.4.4.2 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a> as indicated:</p>
<blockquote>
<pre><code>
template&lt;<i>tuple-like</i> UTuple&gt;
  constexpr explicit(<i>see below</i>) tuple(UTuple&amp;&amp; u);
</code></pre>
<p>-28-
Let <code>I</code> be the pack <code>0, 1, ..., (sizeof...(Types) - 1)</code>.
</p>
<p>-29-
<i>Constraints</i>:
</p>
<ol style="list-style-type: none">
<li>(29.1) &ndash;
<code><i>different-from</i>&lt;UTuple, tuple&gt;</code>
(26.5.2 <a href="https://wg21.link/range.utility.helpers">[range.utility.helpers]</a>) is <code>true</code>,
</li>
<li>(29.2) &ndash;
<code>remove_cvref_t&lt;UTuple&gt;</code> is not a specialization of
<code>ranges::subrange</code>,
</li>
<li>(29.3) &ndash;
<code>sizeof...(Types)</code> equals
<code>tuple_size_v&lt;remove_cvref_t&lt;UTuple&gt;&gt;</code>,
</li>
<li>(29.4) &ndash;
<code>(is_constructible_v&lt;Types, decltype(get&lt;I&gt;(std::forward&lt;UTuple&gt;(u)))> &amp;&amp; ...)</code>
 is
<code>true</code>, and
</li>
<li>(29.5) &ndash;
either <code>sizeof...(Types)</code> is not 1,
or (when <code>Types...</code> expands to <code>T</code>)
<code>is_convertible_v&lt;UTuple, T&gt;</code> and <code>is_constructible_v&lt;T, UTuple&gt;</code>
are both <code>false</code>.
</li>
</ol>
<p>-30- <i>Effects</i>:
For all <i>i</i>,
initializes the <i>i</i><sup>th</sup> element of <code>*this</code>
with <code>get&lt;i&gt;(std::forward&lt;UTuple&gt;(u))</code>.
</p>
<p>-31- <i>Remarks</i>:
The expression inside <code>explicit</code> is equivalent to:
</p>
<pre><code>  !(is_convertible_v&lt;decltype(get&lt;I&gt;(std::forward&lt;UTuple&gt;(u))), Types&gt; &amp;&amp; ...)
</code></pre>
<p>
<ins>
The constructor is defined as deleted if
</ins>
</p>
<pre><code><ins>  (reference_constructs_from_temporary_v&lt;Types, decltype(get&lt;I&gt;(std::forward&lt;UTuple&gt;(u)))&gt; || ...)</ins>
</code></pre>
<p>
<ins>
is <code>true</code>.
</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3 id="4053"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4053">4053</a>. Unary call to <code>std::views::repeat</code> does not decay the argument</h3>
<p><b>Section:</b> 26.6.5.2 <a href="https://wg21.link/range.repeat.view">[range.repeat.view]</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> 2024-02-05 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.repeat.view">active issues</a> in [range.repeat.view].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.repeat.view">issues</a> in [range.repeat.view].</p>
<p><b>Discussion:</b></p>
<p>
Currently, a binary call to <code>std::views::repeat</code> decay the arguments due to the deduction guide, 
but a unary call doesn't, which is inconsistent.
<p/>
For example:
</p>
<blockquote><pre>
#include &lt;concepts&gt;
#include &lt;ranges&gt;

using RPV = std::ranges::repeat_view&lt;const char*&gt;;

static_assert(std::same_as&lt;decltype(std::views::repeat("foo", std::unreachable_sentinel)), RPV&gt;); // OK
static_assert(std::same_as&lt;decltype(std::views::repeat(+"foo", std::unreachable_sentinel)), RPV&gt;); // OK
static_assert(std::same_as&lt;decltype(std::views::repeat("foo")), RPV&gt;); // <span style="color:red;font-weight:bolder">ill-formed</span>
static_assert(std::same_as&lt;decltype(std::views::repeat(+"foo")), RPV&gt;); // OK
</pre></blockquote>
<p>
Presumably we should extend the deduction guide of <code>std::ranges::repeat_view</code> to cover the unary cases.
</p>

<p><i>[2024-03-12; Reflector poll]</i></p>

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



<p id="res-4053"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>
<li><p>Modify 26.6.5.2 <a href="https://wg21.link/range.repeat.view">[range.repeat.view]</a>, class template <code>repeat_view</code> synopsis, as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The proposed wording has been suggested by Casey Carter, see 
<a href="https://github.com/microsoft/STL/issues/3576">microsoft/STL#3576</a>]
</p>
</blockquote>

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

  template&lt;class T, class Bound <ins>= unreachable_sentinel_t</ins>&gt;
    repeat_view(T, Bound <ins>= Bound()</ins>) -&gt; repeat_view&lt;T, Bound&gt;;
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3 id="4054"><a href="https://cplusplus.github.io/LWG/lwg-active.html#4054">4054</a>. Repeating a <code>repeat_view</code> should repeat the view</h3>
<p><b>Section:</b> 26.6.5.1 <a href="https://wg21.link/range.repeat.overview">[range.repeat.overview]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2024-02-12 <b>Last modified:</b> 2024-03-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<code>views::repeat(views::repeat(5))</code> should be a view of <code>repeat_view</code>s, but it's currently a view of 
<code>ints</code> due to the use of CTAD in the specification of <code>views::repeat</code>.
</p>

<p><i>[2024-03-12; Reflector poll]</i></p>

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



<p id="res-4054"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

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

<blockquote>
<p>
-1- <code>repeat_view</code> generates a sequence of elements by repeatedly producing the same value.
<p/>
-2- The name <code>views::repeat</code> denotes a customization point object (16.3.3.3.5 <a href="https://wg21.link/customization.point.object">[customization.point.object]</a>). 
Given subexpressions <code>E</code> and <code>F</code>, the expressions <code>views::repeat(E)</code> and <code>views::repeat(E, F)</code> 
are expression-equivalent to <code>repeat_view<ins>&lt;decay_t&lt;decltype((E))&gt;&gt;</ins>(E)</code> and 
<code>repeat_view(E, F)</code>, respectively.
</p>
</blockquote>
</li>
</ol>





</body>
</html>
