<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta charset="utf-8">
<title>C++ Standard Library Issues to be moved in Virtual Plenary, June 2021</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table {border-collapse: collapse;}
</style>
</head>
<body>
<h1>C++ Standard Library Issues to be moved in Virtual Plenary, June 2021</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P2385R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>2021-05-26</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>

<h2 id="tentatively_ready">Tentatively Ready Issues</h2>

<p>
There are 36 issues moved to Tentatively Ready status since the last meeting.
</p>

<hr>
<h3><a name="2774" href="https://cplusplus.github.io/LWG/lwg-active.html#2774">2774</a>. <tt>std::function</tt> construction vs assignment</h3>
<p><b>Section:</b> 20.14.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2016-09-14 <b>Last modified:</b> 2021-05-20</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#func.wrap.func.con">active issues</a> in [func.wrap.func.con].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>Discussion:</b></p>
<p>
I think there's a minor defect in the <tt>std::function</tt> interface. The constructor template is:
</p>
<blockquote><pre>
template &lt;class F&gt; function(F f);
</pre></blockquote>
<p>
while the assignment operator template is
</p>
<blockquote><pre>
template &lt;class F&gt; function&amp; operator=(F&amp;&amp; f);
</pre></blockquote>
<p>
The latter came about as a result of LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#1288">1288</a>, but that one was dealing with a specific issue that
wouldn't have affected the constructor. I think the constructor should also take <tt>f</tt> by forwarding reference,
this saves a move in the lvalue/xvalue cases and is also just generally more consistent. Should just make sure
that it's stored as <tt>std::decay_t&lt;F&gt;</tt> instead of <tt>F</tt>.
<p/>
Is there any reason to favor a by-value constructor over a forwarding-reference constructor?
</p>

<p><i>[2019-07-26 Tim provides PR.]</i></p>


<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to <a href="https://wg21.link/N4820">N4820</a>.</p>
<ol>
<li><p>Edit 20.14.17.3 <a href="https://wg21.link/func.wrap.func">[func.wrap.func]</a>, class template <tt>function</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
  template&lt;class&gt; class function; // not defined
  template&lt;class R, class... ArgTypes&gt; {
  public:
    using result_type = R;

    // 20.14.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a>, construct/copy/destroy
    function() noexcept;
    function(nullptr_t) noexcept;
    function(const function&amp;);
    function(function&amp;&amp;) noexcept;
    template&lt;class F&gt; function(F<ins>&amp;&amp;</ins>);

    [&hellip;]
  };

  [&hellip;]
}
</pre>
</blockquote>
</li>
<li><p>Edit 20.14.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> p7-11 as indicated:</p>
<blockquote>
<pre>
template&lt;class F&gt; function(F<ins>&amp;&amp;</ins> f);
</pre>
<blockquote>
<p><del>-7- <i>Requires:</i> <tt>F</tt> shall be <i>Cpp17CopyConstructible</i></del><ins>Let
<tt>FD</tt> be <tt>decay_t&lt;F&gt;</tt></ins>.</p>
<p>-8- <del><i>Remarks:</i> This constructor template shall not participate in overload resolution unless
<tt>F</tt></del> <ins><i>Constraints:</i></ins></p>
<ol style="list-style-type:none">
<li><p><ins>(8.1) &mdash; <tt>is_same_v&lt;FD, function&gt;</tt> is <tt>false</tt>; and</ins></p></li>
<li><p><ins>(8.2) &mdash; <tt>FD</tt></ins> is Lvalue-Callable
(20.14.17.3 <a href="https://wg21.link/func.wrap.func">[func.wrap.func]</a>) for argument types <tt>ArgTypes...</tt>
and return type <tt>R</tt>.</p>
</li>
</ol>
<p><ins>-?- <i>Expects:</i> <tt>FD</tt> meets the
<i>Cpp17CopyConstructible</i> requirements.</ins></p>
<p> -9- <i>Ensures:</i> <tt>!*this</tt> if any of the following hold:</p>
<ol style="list-style-type:none">
<li><p>(9.1) &mdash; <tt>f</tt> is a null function pointer value.</p></li>
<li><p>(9.2) &mdash; <tt>f</tt> is a null member pointer value.</p></li>
<li><p>(9.3) &mdash; <del><tt>F</tt> is an instance</del> <ins><tt>remove_cvref_t&lt;F&gt;</tt> is
a specialization</ins> of the <tt>function</tt> class template, and <tt>!f</tt> <ins>is <tt>true</tt></ins>.
</p></li>
</ol>
<p> -10- Otherwise, <tt>*this</tt> targets
<del>a copy of <tt>f</tt></del><ins>an object of type <tt>FD</tt>
direct-non-list-</ins>initialized with <del><tt>std::move(f)</tt></del>
<ins><tt>std::forward&lt;F&gt;(f)</tt></ins>. [<i>Note:</i> Implementations should
avoid the use of dynamically allocated memory for small callable objects, for example, where <tt>f</tt>
<del>is</del> <ins>refers to</ins> an object holding only a pointer or reference to an object
and a member function pointer. &mdash; <i>end note</i>]</p>
<p> -11- <i>Throws:</i> <del>Shall</del> <ins>Does</ins> not throw exceptions when <del><tt>f</tt></del>
<ins><tt>FD</tt></ins> is a function pointer <ins>type</ins> or
a <ins>specialization of</ins> <tt>reference_wrapper</tt><del><tt>&lt;T&gt;</tt> for some <tt>T</tt></del>.
Otherwise, may throw <tt>bad_alloc</tt> or any exception thrown by <del><tt>F</tt>’s copy or move constructor</del>
<ins>the initialization of the target object</ins>.</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-11-01; Daniel comments and improves the wording]</i></p>

<p>
The proposed wording should &mdash; following the line of Marshall's "Mandating" papers &mdash;
extract from the <i>Cpp17CopyConstructible</i> precondition a corresponding <i>Constraints:</i>
element and in addition to that the wording should replace old-style elements such as <i>Expects:</i>
by the recently agreed on elements.
<p/>
See also the related issue LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3493">3493</a>.
</p>


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

<ol>
<li><p>Edit 20.14.17.3 <a href="https://wg21.link/func.wrap.func">[func.wrap.func]</a>, class template <tt>function</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class&gt; class function; <i>// not defined</i>

  template&lt;class R, class... ArgTypes&gt; {
  public:
    using result_type = R;

    // 20.14.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a>, construct/copy/destroy
    function() noexcept;
    function(nullptr_t) noexcept;
    function(const function&amp;);
    function(function&amp;&amp;) noexcept;
    template&lt;class F&gt; function(F<ins>&amp;&amp;</ins>);

    [&hellip;]
  };

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

<li><p>Edit 20.14.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class F&gt; function(F<ins>&amp;&amp;</ins> f);
</pre>
<blockquote>
<p>
<ins>Let <tt>FD</tt> be <tt>decay_t&lt;F&gt;</tt>.</ins>
</p>
-8- <i>Constraints:</i>
<ol style="list-style-type:none">
<li><p><ins>(8.1) &mdash; <tt>is_same_v&lt;remove_cvref_t&lt;F&gt;, function&gt;</tt> is <tt>false</tt>,</ins></p></li>
<li><p><ins>(8.2) &mdash; <tt>FD</tt></ins><del><tt>F</tt></del> is Lvalue-Callable (20.14.17.3.1 <a href="https://wg21.link/func.wrap.func.general">[func.wrap.func.general]</a>)
for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt><ins>,</ins></p></li>
<li><p><ins>(8.3) &mdash; <tt>is_copy_constructible_v&lt;FD&gt;</tt> is <tt>true</tt>, and</ins></p></li>
<li><p><ins>(8.4) &mdash; <tt>is_constructible_v&lt;FD, F&gt;</tt> is <tt>true</tt></ins>.</p></li>
</ol>
<p>
-9- <i>Preconditions:</i> <tt><del>F</del><ins>FD</ins></tt> meets the <i>Cpp17CopyConstructible</i> requirements.
<p/>
-10- <i>Postconditions:</i> <tt>!*this</tt> if any of the following hold:
</p>
<ol style="list-style-type:none">
<li><p>(10.1) &mdash; <tt>f</tt> is a null function pointer value.</p></li>
<li><p>(10.2) &mdash; <tt>f</tt> is a null member pointer value.</p></li>
<li><p>(10.3) &mdash; <del><tt>F</tt> is an instance</del><ins><tt>remove_cvref_t&lt;F&gt;</tt> is
a specialization</ins> of the function class template, and <tt>!f</tt> <ins>is <tt>true</tt></ins>.</p></li>
</ol>
<p>
-11- Otherwise, <tt>*this</tt> targets <del>a copy of <tt>f</tt></del><ins>an object of type <tt>FD</tt>
direct-non-list-</ins>initialized with <tt><del>std::move(f)</del><ins>std::forward&lt;F&gt;(f)</ins></tt>.
<p/>
-12- <i>Throws:</i> Nothing if <tt><del>f</del><ins>FD</ins></tt> is a specialization of <tt>reference_wrapper</tt>
or a function pointer <ins>type</ins>. Otherwise, may throw <tt>bad_alloc</tt> or any exception thrown by
<del><tt>F</tt>'s copy or move constructor</del><ins>the initialization of the target object</ins>.
<p/>
-13- <i>Recommended practice:</i> Implementations should avoid the use of dynamically allocated memory for
small callable objects, for example, where <tt>f</tt> <del>is</del><ins>refers to</ins> an object holding
only a pointer or reference to an object and a member function pointer.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2021-05-17; Tim comments and revises the wording]</i></p>

<p>
The additional constraints added in the previous wording can induce
constraint recursion, as noted in the discussion of LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3493">3493</a>.
The wording below changes them to <i>Mandates:</i> instead to allow this issue
to make progress independently of that issue.
<p/>
The proposed resolution below has been implemented and tested on top of
libstdc++.
</p>

<p><i>[2021-05-20; Reflector poll]</i></p>

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



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

<ol>
<li><p>Edit 20.14.17.3.1 <a href="https://wg21.link/func.wrap.func.general">[func.wrap.func.general]</a>, class template <tt>function</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class&gt; class function; <i>// not defined</i>

  template&lt;class R, class... ArgTypes&gt; {
  public:
    using result_type = R;

    // 20.14.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a>, construct/copy/destroy
    function() noexcept;
    function(nullptr_t) noexcept;
    function(const function&amp;);
    function(function&amp;&amp;) noexcept;
    template&lt;class F&gt; function(F<ins>&amp;&amp;</ins>);

    [&hellip;]
  };

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

<li><p>Edit 20.14.17.3.2 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class F&gt; function(F<ins>&amp;&amp;</ins> f);
</pre>
<blockquote>
<p>
<ins>Let <tt>FD</tt> be <tt>decay_t&lt;F&gt;</tt>.</ins>
</p>
-8- <i>Constraints:</i>
<ol style="list-style-type:none">
<li><p><ins>(8.1) &mdash; <tt>is_same_v&lt;remove_cvref_t&lt;F&gt;, function&gt;</tt> is <tt>false</tt>, and</ins></p></li>
<li><p><ins>(8.2) &mdash; <tt>FD</tt></ins><del><tt>F</tt></del> is Lvalue-Callable (20.14.17.3.1 <a href="https://wg21.link/func.wrap.func.general">[func.wrap.func.general]</a>)
for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.</p></li>
</ol>
<p>
<ins>-?- <i>Mandates:</i></ins>
</p>
<ol style="list-style-type:none">
<li><p><ins>(?.1) &mdash; <tt>is_copy_constructible_v&lt;FD&gt;</tt> is <tt>true</tt>, and</ins></p></li>
<li><p><ins>(?.2) &mdash; <tt>is_constructible_v&lt;FD, F&gt;</tt> is <tt>true</tt>.</ins></p></li>
</ol>
<p>
-9- <i>Preconditions:</i> <tt><del>F</del><ins>FD</ins></tt> meets the <i>Cpp17CopyConstructible</i> requirements.
<p/>
-10- <i>Postconditions:</i> <tt>!*this</tt> <ins>is <tt>true</tt></ins> if any of the following hold:
</p>
<ol style="list-style-type:none">
<li><p>(10.1) &mdash; <tt>f</tt> is a null function pointer value.</p></li>
<li><p>(10.2) &mdash; <tt>f</tt> is a null member pointer value.</p></li>
<li><p>(10.3) &mdash; <del><tt>F</tt> is an instance</del><ins><tt>remove_cvref_t&lt;F&gt;</tt> is
a specialization</ins> of the <tt>function</tt> class template, and <tt>!f</tt> <ins>is <tt>true</tt></ins>.</p></li>
</ol>
<p>
-11- Otherwise, <tt>*this</tt> targets <del>a copy of <tt>f</tt></del><ins>an object of type <tt>FD</tt>
direct-non-list-</ins>initialized with <tt><del>std::move(f)</del><ins>std::forward&lt;F&gt;(f)</ins></tt>.
<p/>
-12- <i>Throws:</i> Nothing if <tt><del>f</del><ins>FD</ins></tt> is a specialization of <tt>reference_wrapper</tt>
or a function pointer <ins>type</ins>. Otherwise, may throw <tt>bad_alloc</tt> or any exception thrown by
<del><tt>F</tt>'s copy or move constructor</del><ins>the initialization of the target object</ins>.
<p/>
-13- <i>Recommended practice:</i> Implementations should avoid the use of dynamically allocated memory for
small callable objects, for example, where <tt>f</tt> <del>is</del><ins>refers to</ins> an object holding
only a pointer or reference to an object and a member function pointer.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2818" href="https://cplusplus.github.io/LWG/lwg-active.html#2818">2818</a>. <tt>"::std::"</tt> everywhere rule needs tweaking</h3>
<p><b>Section:</b> 16.4.2.2 <a href="https://wg21.link/contents">[contents]</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> 2016-11-11 <b>Last modified:</b> 2021-05-24</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#contents">issues</a> in [contents].</p>
<p><b>Discussion:</b></p>
<p>
[contents]/3 says
</p>
<blockquote><p>
Whenever a name <tt>x</tt> defined in the standard library is mentioned, the name <tt>x</tt> is assumed to be fully 
qualified as <tt>::std::x</tt>, unless explicitly described otherwise. For example, if the <i>Effects</i> section 
for library function <tt>F</tt> is described as calling library function <tt>G</tt>, the function <tt>::std::G</tt> is meant.
</p></blockquote>
<p>
With the introduction of nested namespaces inside <tt>std</tt>, this rule needs tweaking. For instance, 
<tt>time_point_cast</tt>'s <i>Returns</i> clause says "<tt>time_point&lt;Clock, 
ToDuration&gt;(duration_cast&lt;ToDuration&gt;(t.time_since_epoch()))</tt>"; that reference to <tt>duration_cast</tt> 
obviously means <tt>::std::chrono::duration_cast</tt>, not <tt>::std::duration_cast</tt>, which doesn't exist.
</p>

<p><i>[Issues Telecon 16-Dec-2016]</i></p>

<p>Priority 2; Jonathan to provide wording</p>

<p><i>[2019 Cologne Wednesday night]</i></p>

<p>Geoffrey suggested editing 16.4.2.2 <a href="https://wg21.link/contents">[contents]</a>/2 to mention the case when we're defining things in a sub-namespace.</p>
<p>Jonathan to word this.</p>

<p><i>[2020-02-14, Prague; Walter provides wording]</i></p>

<p>
</p>

<p><i>[2020-10-02; Issue processing telecon: new wording from Jens]</i></p>

<p>Use "Simplified suggestion" in 13 June 2020 email from Jens.</p>

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

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

<blockquote>
<p>
-3- <del>Whenever a name <tt>x</tt> defined in the standard library is mentioned, the name <tt>x</tt> is assumed to be fully qualified
as <tt>::std::x</tt>, unless explicitly described otherwise. For example, if the <i>Effects:</i> element for library function <tt>F</tt>
is described as calling library function <tt>G</tt>, the function <tt>::std::G</tt> is meant.</del><ins>Let <tt>x</tt> be a name
specified by the standard library via a declaration in namespace <tt>std</tt> or in a subnamespace of namespace <tt>std</tt>.
Whenever <tt>x</tt> is used as an unqualified name in a further specification, it is assumed to correspond
to the same <tt>x</tt> that would be found via unqualified name lookup (6.5.3 <a href="https://wg21.link/basic.lookup.unqual">[basic.lookup.unqual]</a>) performed at that point 
of use. Similarly, whenever <tt>x</tt> is used as a qualified name in a further specification, it is assumed to correspond
to the same <tt>x</tt> that would be found via qualified name lookup (6.5.5 <a href="https://wg21.link/basic.lookup.qual">[basic.lookup.qual]</a>) performed at that point 
of use. [<i>Note:</i> Such lookups can never fail in a well-formed program. &mdash; <i>end note</i>] 
[<i>Example:</i> If an <i>Effects:</i> element for a library function <tt>F</tt> specifies that library function <tt>G</tt>
is to be used, the function <tt>::std::G</tt> is intended. &mdash; <i>end example</i>]</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

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

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

<blockquote>
<p><i>[Drafting note:
Consider adding a note clarifying that the unqualified lookup
does not perform ADL.
]</i></p>

<p>
-3- <del>Whenever a name <tt>x</tt> defined in the standard library is mentioned, the name <tt>x</tt> is assumed to be fully qualified
as <tt>::std::x</tt>, unless explicitly described otherwise. For example, if the <i>Effects:</i> element for library function <tt>F</tt>
is described as calling library function <tt>G</tt>, the function <tt>::std::G</tt> is meant.</del>
<ins>
Whenever an unqualified name <tt>x</tt> is used
in the specification of a declaration <tt>D</tt>
in clauses 16-32,
its meaning is established as-if by performing unqualified name lookup
(6.5.3 <a href="https://wg21.link/basic.lookup.unqual">[basic.lookup.unqual]</a>) in the context of <tt>D</tt>.
Similarly, the meaning of a qualified-id is established as-if by
performing qualified name lookup (6.5.5 <a href="https://wg21.link/basic.lookup.qual">[basic.lookup.qual]</a>)
in the context of <tt>D</tt>.
<i>[Example:</i>
The reference to <tt>is_array_v</tt> in the
specification of <tt>std::to_array</tt> (22.3.7.6 <a href="https://wg21.link/array.creation">[array.creation]</a>)
refers to <tt>::std::is_array_v</tt>.
-- <i>end example]</i>
<i>[Note:</i>
Operators in expressions 12.2.2.3 <a href="https://wg21.link/over.match.oper">[over.match.oper]</a>
are not so constrained; see 16.4.6.4 <a href="https://wg21.link/global.functions">[global.functions]</a>.
-- <i>end note]</i>
</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-11-04; Jens provides improved wording]</i></p>


<p><i>[2020-11-06; Reflector discussion]</i></p>

<p>
Casey suggests to insert "or Annex D" after "in clauses 16-32". This insertion has been performed during
reflector discussions immediately because it seemed editorial.
</p>

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

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

<p><i>[2020-11-22, Tim Song reopens]</i></p>

<p>
The references to get in 24.5.4.1 <a href="https://wg21.link/range.subrange.general">[range.subrange.general]</a> and
24.7.16.2 <a href="https://wg21.link/range.elements.view">[range.elements.view]</a> need to be qualified as they would otherwise
refer to <tt>std::ranges::get</tt> instead of <tt>std::get</tt>. Additionally,
16.3.3.2 <a href="https://wg21.link/expos.only.func">[expos.only.func]</a> needs to clarify that the lookup there also takes
place from within namespace <tt>std</tt>.
</p>

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

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

<blockquote>
<p>
-3- <del>Whenever a name <tt>x</tt> defined in the standard library is mentioned, the name <tt>x</tt> 
is assumed to be fully qualified as <tt>::std::x</tt>, unless explicitly described otherwise. For example, 
if the <i>Effects:</i> element for library function <tt>F</tt> is described as calling library function 
<tt>G</tt>, the function <tt>::std::G</tt> is meant.</del>
<ins>Whenever an unqualified name <tt>x</tt> is used in the specification of a declaration <tt>D</tt>
in clauses 16-32 or Annex D, its meaning is established as-if by performing unqualified name lookup
(6.5.3 <a href="https://wg21.link/basic.lookup.unqual">[basic.lookup.unqual]</a>) in the context of <tt>D</tt>. [<i>Note ?:</i> Argument-dependent lookup 
is not performed. &mdash; <i>end note</i>] Similarly, the meaning of a qualified-id is established as-if by 
performing qualified name lookup (6.5.5 <a href="https://wg21.link/basic.lookup.qual">[basic.lookup.qual]</a>) in the context of <tt>D</tt>.
[<i>Example:</i> The reference to <tt>is_array_v</tt> in the specification of <tt>std::to_array</tt> 
(22.3.7.6 <a href="https://wg21.link/array.creation">[array.creation]</a>) refers to <tt>::std::is_array_v</tt>. &mdash; <i>end example</i>]
[<i>Note ?:</i> Operators in expressions (12.2.2.3 <a href="https://wg21.link/over.match.oper">[over.match.oper]</a>) are not so constrained; see 
16.4.6.4 <a href="https://wg21.link/global.functions">[global.functions]</a>. &mdash; <i>end note</i>]
</ins>
</p>
</blockquote>
</li>

<li><p>Remove 29.11.3.2 <a href="https://wg21.link/fs.req.namespace">[fs.req.namespace]</a> in its entirety:</p>

<blockquote>
<p>
<del><b>29.11.3.2 Namespaces and headers [fs.req.namespace]</b></del>
<p/>
<del>-1- Unless otherwise specified, references to entities described in subclause 29.11 <a href="https://wg21.link/filesystems">[filesystems]</a> 
are assumed to be qualified with <tt>::std::filesystem::</tt>.</del>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2021-05-20; Jens Maurer provides an updated proposed resolution]</i></p>


<p><i>[2021-05-23; Daniel provides some additional tweaks to the updated proposed resolution]</i></p>


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

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



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

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

<blockquote>
<p>
-2- The following are defined for exposition only to aid in the specification of the library:
</p>
<blockquote>
<pre>
<ins>namespace std {</ins>
  template&lt;class T&gt; constexpr decay_t&lt;T&gt; <i>decay-copy</i>(T&amp;&amp; v)
      noexcept(is_nothrow_convertible_v&lt;T, decay_t&lt;T&gt;&gt;) <i>// exposition only</i>
    { return std::forward&lt;T&gt;(v); }
    
  constexpr auto <i>synth-three-way</i> =
    []&lt;class T, class U&gt;(const T&amp; t, const U&amp; u)
      requires requires {
      { t &lt; u } -&gt; <i>boolean-testable</i>;
      { u &lt; t } -&gt; <i>boolean-testable</i>;
      }
    {
      if constexpr (three_way_comparable_with&lt;T, U&gt;) {
        return t &lt;=&gt; u;
      } else {
        if (t &lt; u) return weak_ordering::less;
        if (u &lt; t) return weak_ordering::greater;
        return weak_ordering::equivalent;
      }
    };

  template&lt;class T, class U=T&gt;
  using <i>synth-three-way-result</i> = decltype(<i>synth-three-way</i>(declval&lt;T&amp;&gt;(), declval&lt;U&amp;&gt;()));
<ins>}</ins>
</pre>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<p>
-3- <del>Whenever a name <tt>x</tt> defined in the standard library is mentioned, the name <tt>x</tt> 
is assumed to be fully qualified as <tt>::std::x</tt>, unless explicitly described otherwise. For example, 
if the <i>Effects:</i> element for library function <tt>F</tt> is described as calling library function 
<tt>G</tt>, the function <tt>::std::G</tt> is meant.</del>
<ins>Whenever an unqualified name <tt>x</tt> is used in the specification of a declaration <tt>D</tt>
in clauses 16-32 or Annex D, its meaning is established as-if by performing unqualified name lookup
(6.5.3 <a href="https://wg21.link/basic.lookup.unqual">[basic.lookup.unqual]</a>) in the context of <tt>D</tt>. [<i>Note ?:</i> Argument-dependent lookup 
is not performed. &mdash; <i>end note</i>] Similarly, the meaning of a <i>qualified-id</i> is established as-if by 
performing qualified name lookup (6.5.5 <a href="https://wg21.link/basic.lookup.qual">[basic.lookup.qual]</a>) in the context of <tt>D</tt>.
[<i>Example:</i> The reference to <tt>is_array_v</tt> in the specification of <tt>std::to_array</tt> 
(22.3.7.6 <a href="https://wg21.link/array.creation">[array.creation]</a>) refers to <tt>::std::is_array_v</tt>. &mdash; <i>end example</i>]
[<i>Note ?:</i> Operators in expressions (12.2.2.3 <a href="https://wg21.link/over.match.oper">[over.match.oper]</a>) are not so constrained; see 
16.4.6.4 <a href="https://wg21.link/global.functions">[global.functions]</a>. &mdash; <i>end note</i>]
</ins>
</p>
</blockquote>
</li>

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

<blockquote><pre>
template&lt;class T&gt;
  concept <i>pair-like</i> =              <i>// exposition only</i>
    !is_reference_v&lt;T&gt; &amp;&amp; requires(T t) {
      typename tuple_size&lt;T&gt;::type; <i>// ensures tuple_size&lt;T&gt; is complete</i>
      requires derived_from&lt;tuple_size&lt;T&gt;, integral_constant&lt;size_t, 2&gt;&gt;;
      typename tuple_element_t&lt;0, remove_const_t&lt;T&gt;&gt;;
      typename tuple_element_t&lt;1, remove_const_t&lt;T&gt;&gt;;
      { <ins>std::</ins>get&lt;0&gt;(t) } -&gt; convertible_to&lt;const tuple_element_t&lt;0, T&gt;&amp;&gt;;
      { <ins>std::</ins>get&lt;1&gt;(t) } -&gt; convertible_to&lt;const tuple_element_t&lt;1, T&gt;&amp;&gt;;
    };
</pre></blockquote>
</li>

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

<blockquote><pre>
template&lt;class T, size_t N&gt;
  concept <i>has-tuple-element</i> = <i>// exposition only</i>
    requires(T t) {
      typename tuple_size&lt;T&gt;::type;
      requires N &lt;tuple_size_v&lt;T&gt;;
      typename tuple_element_t&lt;N, T&gt;;
      { <ins>std::</ins>get&lt;N&gt;(t) } -&gt; convertible_to&lt;const tuple_element_t&lt;N, T&gt;&amp;&gt;;
    };
</pre></blockquote>
</li>

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

<blockquote>
<p>
-2- The member <i>typedef-name</i> <tt>iterator_category</tt> is defined if and only if <tt><i>Base</i></tt> 
models <tt>forward_range</tt>. In that case, <tt>iterator_category</tt> is defined as follows: [&hellip;]
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; If <tt><ins>std::</ins>get&lt;N&gt;(*<i>current_</i>)</tt> is an rvalue, <tt>iterator_category</tt> 
denotes <tt>input_iterator_tag</tt>.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
<pre>
static constexpr decltype(auto) <i>get-element</i>(const iterator_t&lt;<i>Base</i>&gt;&amp; i); <i>// exposition only</i>
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Equivalent to:
</p>
<blockquote>
<pre>
if constexpr (is_reference_v&lt;range_reference_t&lt;<i>Base</i>&gt;&gt;) {
  return <ins>std::</ins>get&lt;N&gt;(*i);
} else {
  using E = remove_cv_t&lt;tuple_element_t&lt;N, range_reference_t&lt;<i>Base</i>&gt;&gt;&gt;;
  return static_cast&lt;E&gt;(<ins>std::</ins>get&lt;N&gt;(*i));
}
</pre>
</blockquote>
</blockquote>
</blockquote>
</li>

<li><p>Remove 29.11.3.2 <a href="https://wg21.link/fs.req.namespace">[fs.req.namespace]</a> in its entirety:</p>

<blockquote>
<p>
<del><b>29.11.3.2 Namespaces and headers [fs.req.namespace]</b></del>
<p/>
<del>-1- Unless otherwise specified, references to entities described in subclause 29.11 <a href="https://wg21.link/filesystems">[filesystems]</a> 
are assumed to be qualified with <tt>::std::filesystem::</tt>.</del>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2997" href="https://cplusplus.github.io/LWG/lwg-active.html#2997">2997</a>. LWG 491 and the specification of <tt>{forward_,}list::unique</tt></h3>
<p><b>Section:</b> 22.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a>, 22.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</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> 2017-07-07 <b>Last modified:</b> 2021-05-21</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>Discussion:</b></p>
<p>
There are various problems with the specification of <tt>list::unique</tt> and its <tt>forward_list</tt> counterpart, some of which are obvious even on cursory inspection:
<ul>
<li>It refers to the identifiers <tt>first</tt> and <tt>last</tt>, which aren't even defined.</li>
<li>It uses <tt>i - 1</tt> on non-random-access iterators - in the case of <tt>forward_list</tt>, on forward-only iterators.</li>
<li>The resolution of LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#202">202</a>, changing the specification of <tt>std::unique</tt> to require an equivalence relation
    and adjusting the order of comparison, weren't applied to these member functions.</li>
</ul>
<p/>
LWG <a href="https://cplusplus.github.io/LWG/lwg-closed.html#491">491</a>, which pointed out many of those problems with the specification of <tt>list::unique</tt>, was closed as NAD with the rationale that
<blockquote>
"All implementations known to the author of this Defect Report comply with these assumption", and "no impact on current code is expected", i.e. there is no evidence of real-world confusion or harm.
</blockquote>
That implementations somehow managed to do the right thing in spite of obviously defective standardese doesn't seem like a good reason to not fix the defects.
</p>

<p><i>[2017-07 Toronto Tuesday PM issue prioritization]</i></p>

<p>Priority 3; by the way, there's general wording in 25.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a> p10 that lets us specify iterator arithmetic as if we were using random access iterators.</p>

<p><i>[2017-07-11 Tim comments]</i></p>

<p>I drafted the P/R fully aware of the general wording in 25.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a> p10. However, that general wording is limited to Clause 28, so to make use of the shorthand permitted
by that wording, we would need additional wording importing it to these subclauses.
<p/>
Moreover, that general wording only defines <tt>a+n</tt> and <tt>b-a</tt>; it notably doesn't define <tt>a-n</tt>, which is needed here. And one cannot merely define <tt>a-n</tt> as
<tt>a+(-n)</tt> since that has undefined behavior for forward iterators.
</p>

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

<ol>
<li><p>Edit 22.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> as indicated:</p>
<blockquote>
<pre>
void unique();
template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
</pre>
<blockquote><p>
<ins>-?- <i>Requires:</i> The comparison function shall be an equivalence relation. </ins>
<p/>
-19- <i>Effects:</i> <ins>If <tt>empty()</tt>, has no effects. Otherwise, e</ins><del>E</del>rases all but the first element from every consecutive
group of <del>equal</del><ins>equivalent</ins> elements referred to by the iterator <tt>i</tt> in the range <tt><del>[first + 1, last)</del><ins>[next(begin()), end())</ins></tt>
for which <tt><del>*i == *(i-1)</del><ins>*j == *i</ins></tt> (for the version of <tt>unique</tt> with no arguments) or
<tt><del>pred(*i, *(i - 1))</del><ins>pred(*j, *i)</ins></tt> (for the version of <tt>unique</tt> with a predicate argument) holds<ins>,
where <tt>j</tt> is an iterator in <tt>[begin(), end())</tt> such that <tt>next(j) == i</tt></ins>. Invalidates only the iterators and references to the erased elements.
<p/>
-20- <i>Throws:</i> Nothing unless an exception is thrown by <del><tt>*i == *(i-1)</tt> or <tt>pred(*i, *(i - 1))</tt></del><ins> the equality comparison or the predicate</ins>.
<p/>
-21- <i>Complexity:</i> If <del>the range <tt>[first, last)</tt> is not empty</del><ins><tt>!empty()</tt></ins>, exactly <tt><del>(last - first) - 1</del><ins>size() - 1</ins></tt>
applications of the corresponding predicate, otherwise no applications of the predicate.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 22.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a> as indicated:</p>
<blockquote>
<pre>
void unique();
template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
</pre>
<blockquote><p>
<ins>-?- <i>Requires:</i> The comparison function shall be an equivalence relation. </ins>
<p/>
-16- <i>Effects:</i> <ins>If <tt>empty()</tt>, has no effects. Otherwise, e</ins><del>E</del>rases all but the first element from every consecutive
group of <del>equal</del><ins>equivalent</ins> elements referred to by the iterator <tt>i</tt> in the range <tt><del>[first + 1, last)</del><ins>[next(begin()), end())</ins></tt>
for which <tt><del>*i == *(i-1)</del><ins>*j == *i</ins></tt> (for the version with no arguments) or
<tt><del>pred(*i, *(i - 1))</del><ins>pred(*j, *i)</ins></tt> (for the version with a predicate argument) holds<ins>,
where <tt>j</tt> is an iterator in <tt>[begin(), end())</tt> such that <tt>next(j) == i</tt></ins>. Invalidates only the iterators and references to the erased elements.
<p/>
-17- <i>Throws:</i> Nothing unless an exception is thrown by the equality comparison or the predicate.
<p/>
-18- <i>Complexity:</i> If <del>the range <tt>[first, last)</tt> is not empty</del><ins><tt>!empty()</tt></ins>, exactly
<tt><del>(last - first) - 1</del><ins>distance(begin(), end()) - 1</ins></tt> applications of the corresponding predicate,
    otherwise no applications of the predicate.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>
<p><i>[2021-02-21 Tim redrafts]</i></p>

<p>The wording below incorporates
<a href="https://github.com/cplusplus/draft/pull/4465">editorial pull request 4465</a>. </p>

<p><i>[2021-05-21; Reflector poll]</i></p>

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



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

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

<ol>
<li><p>Edit 22.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> as indicated:</p>
<blockquote><p>
-1- Since lists allow fast insertion and erasing from the middle of a list,
certain operations are provided specifically for them.<sup>222</sup>
In this subclause, arguments for a template parameter named <tt>Predicate</tt> or
<tt>BinaryPredicate</tt> shall meet the corresponding requirements in
25.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a>. <ins>The semantics of <tt>i + n</tt>
and <tt>i - n</tt>, where <tt>i</tt> is an iterator into the list and <tt>n</tt>
is an integer, are the same as those of <tt>next(i, n)</tt> and <tt>prev(i, n)</tt>,
respectively.</ins>
For <tt>merge</tt> and <tt>sort</tt>, the definitions and requirements in
25.8 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a> apply.
<p/>
[&hellip;]
</p>
<pre>
void unique();
template&lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
</pre>
<blockquote><p>
<ins>-?- Let <tt>binary_pred</tt> be <tt>equal_to&lt;&gt;{}</tt> for the first overload.</ins>
<p/>
<ins>-?- <i>Preconditions:</i> <tt>binary_pred</tt> is an equivalence relation.</ins>
<p/>
-20- <i>Effects:</i> Erases all but the first element from every consecutive
group of <del>equal</del><ins>equivalent</ins> elements<ins>. That is, for a nonempty list, erases all elements</ins>
referred to by the iterator <tt>i</tt> in the range <tt><del>[first + 1, last)</del><ins>[begin() + 1, end())</ins></tt>
for which <del><tt>*i == *(i-1)</tt> (for the version of <tt>unique</tt> with no arguments) or</del>
<tt><ins>binary_</ins>pred(*i, *(i - 1))</tt> <ins>is <tt>true</tt></ins><del>(for the version of <tt>unique</tt> with a predicate argument) holds</del>.
Invalidates only the iterators and references to the erased elements.
<p/>
-21- <i>Returns</i>: The number of elements erased.
<p/>
-22- <i>Throws:</i> Nothing unless an exception is thrown by <del><tt>*i == *(i-1)</tt> or <tt>pred(*i, *(i - 1))</tt></del><ins>the predicate</ins>.
<p/>
-23- <i>Complexity:</i> If <del>the range <tt>[first, last)</tt> is not empty</del><ins><tt>empty()</tt> is <tt>false</tt></ins>, exactly <tt><del>(last - first) - 1</del><ins>size() - 1</ins></tt>
applications of the corresponding predicate, otherwise no applications of the predicate.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Edit 22.3.9.6 <a href="https://wg21.link/forwardlist.ops">[forwardlist.ops]</a> as indicated:</p>
<blockquote>
<p>
-1- In this subclause, arguments for a template parameter named <tt>Predicate</tt> or
<tt>BinaryPredicate</tt> shall meet the corresponding requirements in
25.2 <a href="https://wg21.link/algorithms.requirements">[algorithms.requirements]</a>. <ins>The semantics of <tt>i + n</tt>,
where <tt>i</tt> is an iterator into the list and <tt>n</tt>
is an integer, are the same as those of <tt>next(i, n)</tt>. The expression
<tt>i - n</tt>, where <tt>i</tt> is an iterator into the list and <tt>n</tt>
is an integer, means an iterator <tt>j</tt> such that <tt>j + n == i</tt> is
<tt>true</tt>.</ins>
For <tt>merge</tt> and <tt>sort</tt>, the definitions and requirements in
25.8 <a href="https://wg21.link/alg.sorting">[alg.sorting]</a> apply.
<p/>
[&hellip;]
</p>
<pre>
void unique();
template&lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
</pre>
<blockquote><p>
<ins>-?- Let <tt>binary_pred</tt> be <tt>equal_to&lt;&gt;{}</tt> for the first overload.</ins>
<p/>
<ins>-?- <i>Preconditions:</i> <tt>binary_pred</tt> is an equivalence relation.</ins>
<p/>
-18- <i>Effects:</i> Erases all but the first element from every consecutive
group of <del>equal</del><ins>equivalent</ins> elements<ins>. That is, for a nonempty list, 
erases all elements</ins> referred to by the iterator <tt>i</tt> in the range 
<tt><del>[first + 1, last)</del><ins>[begin() + 1, end())</ins></tt>
for which <del><tt>*i == *(i-1)</tt> (for the version with no arguments) or</del>
<tt><ins>binary_</ins>pred(*i, *(i - 1))</tt> <ins>is <tt>true</tt></ins> <del>(for the 
version with a predicate argument) holds</del>. Invalidates only the iterators and references 
to the erased elements.
<p/>
-19- <i>Returns</i>: The number of elements erased.
<p/>
-20- <i>Throws:</i> Nothing unless an exception is thrown by <del>the equality comparison or</del> 
the predicate.
<p/>
-21- <i>Complexity:</i> If <del>the range <tt>[first, last)</tt> is not empty</del><ins><tt>empty()</tt> 
is <tt>false</tt></ins>, exactly <tt><del>(last - first) - 1</del><ins>distance(begin(), end()) - 1</ins></tt> 
applications of the corresponding predicate, otherwise no applications of the predicate.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3410" href="https://cplusplus.github.io/LWG/lwg-active.html#3410">3410</a>. <tt>lexicographical_compare_three_way</tt> is overspecified</h3>
<p><b>Section:</b> 25.8.12 <a href="https://wg21.link/alg.three.way">[alg.three.way]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-02-27 <b>Last modified:</b> 2021-05-26</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#alg.three.way">issues</a> in [alg.three.way].</p>
<p><b>Discussion:</b></p>
<p>
25.8.12 <a href="https://wg21.link/alg.three.way">[alg.three.way]</a>/2 specifies the effects of the <tt>lexicographical_compare_three_way</tt>
algorithm via a large "equivalent to" codeblock. This codeblock specifies one more iterator comparison
than necessary when the first input sequence is greater than the second, and two more than necessary
in other cases. Requiring unnecessary work is the antithesis of C++.
</p>

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

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

<p><i>[2021-05-19 Tim adds wording]</i></p>

<p>The wording below simply respecifies the algorithm in words. It seems pointless
to try to optimize the code when the reading in the discussion above would
entirely rule out things like <tt>memcmp</tt> optimizations for arbitrary
contiguous iterators of bytes.
</p>

<p><i>[2021-05-26; Reflector poll]</i></p>

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



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

<ol>
<li><p>Modify 25.8.12 <a href="https://wg21.link/alg.three.way">[alg.three.way]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class InputIterator1, class InputIterator2, class Cmp&gt;
  constexpr auto
    lexicographical_compare_three_way(InputIterator1 b1, InputIterator1 e1,
                                      InputIterator2 b2, InputIterator2 e2,
                                      Cmp comp)
        -&gt; decltype(comp(*b1, *b2));
</pre>
<blockquote>
<p>
<ins>-?- Let <i>N</i> be min(<tt>e1 - b1, e2 - b2</tt>). Let <i>E(n)</i>
be <tt>comp(*(b1 + <i>n</i>), *(b2 + <i>n</i>))</tt>.</ins>
<p/>
-1- <i>Mandates:</i> <tt>decltype(comp(*b1, *b2))</tt> is a comparison category type.
<p/>
<ins>-?- <i>Returns:</i> <i>E(i)</i>, where <i>i</i> is the smallest integer
in [0, <i>N</i>) such that <i>E(i)</i> <tt>!= 0</tt> is <tt>true</tt>, or
<tt>(e1 - b1) &lt;=&gt; (e2 - b2)</tt> if no such integer exists.</ins>
<p/>
<ins>-?- <i>Complexity</i>: At most <i>N</i> applications of <tt>comp</tt>.</ins>
<p/>
<del>
-2- <i>Effects:</i> Lexicographically compares two ranges and produces a result
of the strongest applicable comparison category type. Equivalent to:</del>
</p>
<blockquote>
<pre>
<del>for ( ; b1 != e1 &amp;&amp; b2 != e2; void(++b1), void(++b2) )
  if (auto cmp = comp(*b1,*b2); cmp != 0)
      return cmp;
return b1 != e1 ? strong_ordering::greater :
       b2 != e2 ? strong_ordering::less :
                  strong_ordering::equal;</del>
</pre>
</blockquote>

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




<hr>
<h3><a name="3430" href="https://cplusplus.github.io/LWG/lwg-active.html#3430">3430</a>. <tt>std::fstream</tt> &amp; co. should be constructible from <tt>string_view</tt></h3>
<p><b>Section:</b> 29.9.1 <a href="https://wg21.link/fstream.syn">[fstream.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-04-15 <b>Last modified:</b> 2021-05-21</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
We have:
</p>
<blockquote><pre>
basic_fstream(const char*, openmode);
basic_fstream(const filesystem::path::value_type*, openmode); // wide systems only
basic_fstream(const string&amp;, openmode);
basic_fstream(const filesystem::path&amp;, openmode);
</pre></blockquote>
<p>
I think the omission of a <tt>string_view</tt> overload was intentional, because the underlying OS call 
(such as <tt>fopen</tt>) needs a NTBS. We wanted the allocation required to turn a <tt>string_view</tt> 
into an NTBS to be explicitly requested by the user. But then we added the <tt>path</tt> overload, 
which is callable with a <tt>string_view</tt>. Converting to a <tt>path</tt> is more expensive than 
converting to <tt>std::string</tt>, because a path has to <em>at least</em> construct a <tt>basic_string</tt>, 
and potentially also does an encoding conversion, parses the path, and potentially allocates a sequence 
of <tt>path</tt> objects for the path components.
<p/>
This means the simpler, more obvious code is slower and uses more memory:
</p>
<blockquote><pre>
string_view sv = "foo.txt";
fstream f1(sv); // bad
fstream f2(string(sv)); // good
</pre></blockquote>
<p>
We should just allow passing a <tt>string_view</tt> directly, since it already compiles but 
doesn't do what anybody expects or wants.
<p/>
Even with a <tt>string_view</tt> overload, passing types like <tt>const char16_t*</tt> or <tt>u32string_view</tt> 
will still implicitly convert to <tt>filesystem::path</tt>, but that seems reasonable. In those cases the 
encoding conversion is necessary. For Windows we support construction from <tt>const wchar_t*</tt> but not 
from <tt>wstring</tt> or <tt>wstring_view</tt>, which means those types will convert to <tt>filesystem::path</tt>. 
That seems suboptimal, so we might also want to add <tt>wstring</tt> and <tt>wstring_view</tt> overloads for 
"wide systems only", as per 29.9.1 <a href="https://wg21.link/fstream.syn">[fstream.syn]</a> p3.
<p/>
Daniel:
<p/>
LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#2883">2883</a> has a more general view on that but does not consider potential cost differences 
in the presence of <tt>path</tt> overloads (Which didn't exist at this point yet).
</p>

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

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

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

<p>
An alternative fix would be to retain the original design and not allow
construction from a <tt>string_view</tt>. The <tt>path</tt> parameters
could be changed to template parameters which are constrained to be exactly
<tt>path</tt>, and not things like <tt>string_view</tt> which can convert
to <tt>path</tt>.
</p>

<p><i>[2020-08-21; Issue processing telecon: send to LEWG]</i></p>

<p>
Just adding support for <tt>string_view</tt> doesn't prevent expensive
conversions from other types that convert to <tt>path</tt>.
Preference for avoiding all expensive implicit conversions to <tt>path</tt>,
maybe via abbreviated function templates:
<pre>
basic_fstream(same_as&lt;filesystem::path&gt; auto const&amp;, openmode);
</pre>
</p>
<p>
It's possible <tt>path_view</tt> will provide a better option at some point.
</p>
<p>
It was noted that <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2676">2676</a> did intentionally allow conversions
from "strings of character types <code>wchar_t</code>, <code>char16_t</code>,
and <code>char32_t</code>". Those conversions don't need to be implicit
for that to be supported.
</p>

<p><i>[2020-09-11; Tomasz comments and provides wording]</i></p>

<p>
During the <a href="https://wiki.edg.com/bin/view/Wg21summer2020/LWG3430">LEWG 2020-08-24 telecon</a> 
the LEWG provided following guidance on the issue:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
We took one poll (exact wording in the notes) to constrain the constructor which takes 
<tt>filesystem::path</tt> to only take <tt>filesystem::path</tt> and not things convertible to it, 
but only 9 out of 26 people present actually voted. Our interpretation: LWG should go ahead with 
making this change. There is still plenty of time for someone who hasn't yet commented on this to 
bring it up even if it is in a tentatively ready state. It would be nice to see a paper to address 
the problem of the templated path constructor, but no one has yet volunteered to do so. 
Note: the issue description is now a misnomer, as adding a <tt>string_view</tt> constructor 
is no longer being considered at this time.
</p>
</blockquote>
<p>
The proposed P/R  follows original LWG proposal and makes the <tt>path</tt> constructor of the 
<tt>basic_*fstreams</tt> "<tt>explicit</tt>". To adhere to current policy, we refrain from use of 
requires clauses and abbreviated function syntax, and introduce a <i>Constraints</i> element.
</p>

<p><i>[2021-05-21; Reflector poll]</i></p>

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



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

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

<blockquote>
<pre>
[&hellip;]
explicit basic_ifstream(const string&amp; s,
                        ios_base::openmode mode = ios_base::in);
<ins>template&lt;class T&gt;</ins>
explicit basic_ifstream(const <del>filesystem::path</del><ins>T</ins>&amp; s,
                        ios_base::openmode mode = ios_base::in);
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
explicit basic_ifstream(const string&amp; s,
                        ios_base::openmode mode = ios_base::in);
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> Equivalent to: <tt>basic_ifstream(s.c_str(), mode)</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
explicit basic_ifstream(const <del>filesystem::path</del><ins>T</ins>&amp; s,
                        ios_base::openmode mode = ios_base::in);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>is_same_v&lt;T, filesystem::path&gt;</tt> is <tt>true</tt>.</ins>
<p/>
-3- <i>Effects:</i> Equivalent to: <tt>basic_ifstream(s.c_str(), mode)</tt>.
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
[&hellip;]
explicit basic_ofstream(const string&amp; s,
                        ios_base::openmode mode = ios_base::out);
<ins>template&lt;class T&gt;</ins>
explicit basic_ofstream(const <del>filesystem::path</del><ins>T</ins>&amp; s,
                        ios_base::openmode mode = ios_base::out);
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
explicit basic_ofstream(const string&amp; s,
                        ios_base::openmode mode = ios_base::out);
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> Equivalent to: <tt>basic_ofstream(s.c_str(), mode)</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
explicit basic_ofstream(const <del>filesystem::path</del><ins>T</ins>&amp; s,
                        ios_base::openmode mode = ios_base::out);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>is_same_v&lt;T, filesystem::path&gt;</tt> is <tt>true</tt>.</ins>
<p/>
-3- <i>Effects:</i> Equivalent to: <tt>basic_ofstream(s.c_str(), mode)</tt>.
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
[&hellip;]
explicit basic_fstream(
  const string&amp; s,
  ios_base::openmode mode = ios_base::in | ios_base::out);
<ins>template&lt;class T&gt;</ins>
explicit basic_fstream(
  const <del>filesystem::path</del><ins>T</ins>&amp; s,
  ios_base::openmode mode = ios_base::in | ios_base::out);
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
explicit basic_fstream(
  const string&amp; s,
  ios_base::openmode mode = ios_base::in | ios_base::out);
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> Equivalent to: <tt>basic_fstream(s.c_str(), mode)</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
explicit basic_fstream(
  const <del>filesystem::path</del><ins>T</ins>&amp; s,
  ios_base::openmode mode = ios_base::in | ios_base::out);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>is_same_v&lt;T, filesystem::path&gt;</tt> is <tt>true</tt>.</ins>
<p/>
-3- <i>Effects:</i> Equivalent to: <tt>basic_fstream(s.c_str(), mode)</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3462" href="https://cplusplus.github.io/LWG/lwg-active.html#3462">3462</a>. &sect;[formatter.requirements]: Formatter requirements forbid use of <tt>fc.arg()</tt></h3>
<p><b>Section:</b> 20.20.5.1 <a href="https://wg21.link/formatter.requirements">[formatter.requirements]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Alberto Barbati <b>Opened:</b> 2020-06-30 <b>Last modified:</b> 2021-05-24</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
The requirements on the expression <tt>f.format(t, fc)</tt> in [tab:formatter] say
</p>
<blockquote><p>
Formats <tt>t</tt> according to the specifiers stored in <tt>*this</tt>, writes the output to <tt>fc.out()</tt>
and returns an iterator past the end of the output range. The output shall only depend on <tt>t</tt>,
<tt>fc.locale()</tt>, and the range <tt>[pc.begin(), pc.end())</tt> from the last call to <tt>f.parse(pc)</tt>.
</p></blockquote>
<p>
Strictly speaking, this wording effectively forbids <tt>f.format(t, fc)</tt> from calling <tt>fc.arg(n)</tt>,
whose motivation is precisely to allow a formatter to rely on arguments different from <tt>t</tt>. According to this
interpretation, there's no conforming way to implement the <tt>"{ <i>arg-id</i> }"</tt> form of the <i>width</i> and
<i>precision</i> fields of standard format specifiers. Moreover, the formatter described in the example if paragraph
20.20.5.4 <a href="https://wg21.link/format.context">[format.context]</a>/8 would also be non-conforming.
</p>

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

<p>
Set priority to 3 after reflector discussions.
</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 20.20.5.1 <a href="https://wg21.link/formatter.requirements">[formatter.requirements]</a>, Table [tab:formatter], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 67: <i>Formatter</i> requirements [tab:formatter]</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Requirement</th>
</tr>

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

<tr>
<td>
<tt>f.format(t, fc)</tt>
</td>
<td>
<tt>FC::iterator</tt>
</td>
<td>
Formats <tt>t</tt> according to the specifiers stored in
<tt>*this</tt>, writes the output to <tt>fc.out()</tt> and returns
an iterator past the end of the output range. The
output shall only depend on <tt>t</tt>, <tt>fc.locale()</tt>,
<del>and</del> the range <tt>[pc.begin(), pc.end())</tt> from
the last call to <tt>f.parse(pc)</tt><ins>, and <tt>fc.arg(n)</tt>,
where <tt>n</tt> is a <tt>size_t</tt> index value that has been
validated with a call to <tt>pc.check_arg_id(n)</tt> in the last
call to <tt>f.parse(pc)</tt></ins>.
</td>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2021-05-20 Tim comments and updates wording]</i></p>

<p>During reflector discussion Victor said that the formatter requirements should
allow dependency on any of the format arguments in the context. The wording below
reflects that.
</p>

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

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



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

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

<blockquote>
<table border="1">
<caption>Table 67: <i>Formatter</i> requirements [tab:formatter]</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Requirement</th>
</tr>

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

<tr>
<td>
<tt>f.format(t, fc)</tt>
</td>
<td>
<tt>FC::iterator</tt>
</td>
<td>
Formats <tt>t</tt> according to the specifiers stored in
<tt>*this</tt>, writes the output to <tt>fc.out()</tt> and returns
an iterator past the end of the output range. The
output shall only depend on <tt>t</tt>, <tt>fc.locale()</tt>,
<ins><tt>fc.arg(n)</tt> for any value <tt>n</tt> of type <tt>size_t</tt>,</ins>
and the range <tt>[pc.begin(), pc.end())</tt> from
the last call to <tt>f.parse(pc)</tt>.
</td>
</tr>

<tr>
<td colspan="3" align="center">
<tt>&hellip;</tt>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3481" href="https://cplusplus.github.io/LWG/lwg-active.html#3481">3481</a>. <tt>viewable_range</tt> mishandles lvalue move-only views</h3>
<p><b>Section:</b> 24.4.5 <a href="https://wg21.link/range.refinements">[range.refinements]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-08-29 <b>Last modified:</b> 2021-05-24</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.refinements">issues</a> in [range.refinements].</p>
<p><b>Discussion:</b></p>
<p>
The <tt>viewable_range concept</tt> (24.4.5 <a href="https://wg21.link/range.refinements">[range.refinements]</a>) and the <tt>views:all</tt> 
range adaptor (24.7.4 <a href="https://wg21.link/range.all">[range.all]</a>) are duals: <tt>viewable_range</tt> is intended to admit 
exactly types <tt>T</tt> for which <tt>views::all(declval&lt;T&gt;())</tt> is well-formed. (Recall 
that <tt>views::all(<i>meow</i>)</tt> is a prvalue whose type models <tt>view</tt> when it is 
well-formed.) Before the addition of move-only view types to the design, this relationship was in 
place (modulo an incredibly pathological case: a <tt>volatile</tt> value of a view type with 
<tt>volatile</tt>-qualified <tt>begin</tt> and <tt>end</tt> models <tt>viewable_range</tt> but is 
rejected by <tt>views::all</tt> unless it also has a <tt>volatile</tt>-qualified copy constructor 
and copy assignment operator). Adding move-only views to the design punches a bigger hole, however: 
<tt>viewable_range</tt> admits lvalues of move-only view types for which <tt>views::all</tt> is 
ill-formed because these lvalues cannot be decay-copied.
<p/>
It behooves us to restore the correspondence between <tt>viewable_range</tt> and <tt>views::all</tt> 
so that instantiations of components constrained with <tt>viewable_range</tt> (which often appears 
indirectly as <tt>views::all_t&lt;R&gt;</tt> in deduction guides) continue to be well-formed when 
the constraints are satisfied.
</p>

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

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

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

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



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

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

<blockquote>
<p>
-5- The <tt>viewable_range</tt> concept specifies the requirements of a <tt>range</tt> 
type that can be converted to a <tt>view</tt> safely.
</p>
<pre>
template&lt;class T&gt;
  concept viewable_range =
    range&lt;T&gt; &amp;&amp; <del>(borrowed_range&lt;T&gt; || view&lt;remove_cvref_t&lt;T&gt;&gt;);</del>
    <ins>((view&lt;remove_cvref_t&lt;T&gt;&gt; &amp;&amp; constructible_from&lt;remove_cvref_t&lt;T&gt;, T&gt;) ||</ins>
    <ins>(!view&lt;remove_cvref_t&lt;T&gt;&gt; &amp;&amp; borrowed_range&lt;T&gt;));</ins>
</pre>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3506" href="https://cplusplus.github.io/LWG/lwg-active.html#3506">3506</a>. Missing allocator-extended constructors for <tt>priority_queue</tt></h3>
<p><b>Section:</b> 22.6.5 <a href="https://wg21.link/priority.queue">[priority.queue]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-11-21 <b>Last modified:</b> 2021-02-26</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#priority.queue">active issues</a> in [priority.queue].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#priority.queue">issues</a> in [priority.queue].</p>
<p><b>Discussion:</b></p>
<p>
<tt>priority_queue</tt> has two constructor templates taking a pair of input
iterators in addition to a comparator and a container, but it does not have
allocator-extended constructors corresponding to these constructor templates:
</p>
<blockquote><pre>
template&lt;class InputIterator&gt;
  priority_queue(InputIterator first, InputIterator last, const Compare&amp; x,
                 const Container&amp;);
template&lt;class InputIterator&gt;
  priority_queue(InputIterator first, InputIterator last,
                 const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
</pre></blockquote>

<p><i>[2020-11-29; Reflector prioritization]</i></p>

<p>
Set priority to 3 during reflector discussions. It has been pointed out that this issue
is related to LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#1199">1199</a>, LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2210">2210</a>, and LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#2713">2713</a>.
</p>

<p><i>[2021-02-17 Tim adds PR]</i></p>


<p><i>[2021-02-26; LWG telecon]</i></p>

<p>
Set status to Tentatively Ready after discussion and poll.
<table>
<tr><th>F</th><th>A</th><th>N</th></tr>
<tr><td>11</td><td>0</td><td>0</td></tr>
</table>
</p>



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

<ol>
<li><p>Add the following paragraph at the end of 22.6.1 <a href="https://wg21.link/container.adaptors.general">[container.adaptors.general]</a>:</p>
<blockquote>
<p>
<ins>-6- The exposition-only alias template <i><tt>iter-value-type</tt></i> defined in
22.3.1 <a href="https://wg21.link/sequences.general">[sequences.general]</a> may appear in deduction guides for container adaptors.</ins>
</p>
</blockquote>
</li>
<li><p>Modify 22.6.5 <a href="https://wg21.link/priority.queue">[priority.queue]</a>, class template <tt>priority_queue</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
  template&lt;class T, class Container = vector&lt;T&gt;,
            class Compare = less&lt;typename Container::value_type&gt;&gt;
  class priority_queue {

  // [&hellip;]

  public:
    priority_queue() : priority_queue(Compare()) {}
    explicit priority_queue(const Compare&amp; x) : priority_queue(x, Container()) {}
    priority_queue(const Compare&amp; x, const Container&amp;);
    priority_queue(const Compare&amp; x, Container&amp;&amp;);
    template&lt;class InputIterator&gt;
      priority_queue(InputIterator first, InputIterator last, const Compare&amp; x,
                      const Container&amp;);
    template&lt;class InputIterator&gt;
      priority_queue(InputIterator first, InputIterator last,
                      const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
    template&lt;class Alloc&gt; explicit priority_queue(const Alloc&amp;);
    template&lt;class Alloc&gt; priority_queue(const Compare&amp;, const Alloc&amp;);
    template&lt;class Alloc&gt; priority_queue(const Compare&amp;, const Container&amp;, const Alloc&amp;);
    template&lt;class Alloc&gt; priority_queue(const Compare&amp;, Container&amp;&amp;, const Alloc&amp;);
    template&lt;class Alloc&gt; priority_queue(const priority_queue&amp;, const Alloc&amp;);
    template&lt;class Alloc&gt; priority_queue(priority_queue&amp;&amp;, const Alloc&amp;);
<ins>    template&lt;class InputIterator, class Alloc&gt;
      priority_queue(InputIterator, InputIterator, const Alloc&amp;);
    template&lt;class InputIterator, class Alloc&gt;
      priority_queue(InputIterator, InputIterator, const Compare&amp;, const Alloc&amp;);
    template&lt;class InputIterator, class Alloc&gt;
      priority_queue(InputIterator, InputIterator, const Compare&amp;, const Container&amp;, const Alloc&amp;);
    template&lt;class InputIterator, class Alloc&gt;
      priority_queue(InputIterator, InputIterator, const Compare&amp;, Container&amp;&amp;, const Alloc&amp;);</ins>

  // [&hellip;]

  };

  template&lt;class Compare, class Container&gt;
    priority_queue(Compare, Container)
      -&gt; priority_queue&lt;typename Container::value_type, Container, Compare&gt;;

  template&lt;class InputIterator,
            class Compare = less&lt;<del>typename iterator_traits</del><ins><i>iter-value-type</i></ins>&lt;InputIterator&gt;<del>::value_type</del>&gt;,
            class Container = vector&lt;<del>typename iterator_traits</del><ins><i>iter-value-type</i></ins>&lt;InputIterator&gt;<del>::value_type</del>&gt;&gt;
    priority_queue(InputIterator, InputIterator, Compare = Compare(), Container = Container())
      -&gt; priority_queue&lt;<del>typename iterator_traits</del><ins><i>iter-value-type</i></ins>&lt;InputIterator&gt;<del>::value_type</del>, Container, Compare&gt;;

  template&lt;class Compare, class Container, class Allocator&gt;
    priority_queue(Compare, Container, Allocator)
      -&gt; priority_queue&lt;typename Container::value_type, Container, Compare&gt;;

<ins>  template&lt;class InputIterator, class Allocator&gt;
    priority_queue(InputIterator, InputIterator, Allocator)
      -&gt; priority_queue&lt;<i>iter-value-type</i>&lt;InputIterator&gt;,
                        vector&lt;<i>iter-value-type</i>&lt;InputIterator&gt;, Allocator&gt;,
                        less&lt;<i>iter-value-type</i>&lt;InputIterator&gt;&gt;&gt;;

  template&lt;class InputIterator, class Compare, class Allocator&gt;
    priority_queue(InputIterator, InputIterator, Compare, Allocator)
      -&gt; priority_queue&lt;<i>iter-value-type</i>&lt;InputIterator&gt;,
                        vector&lt;<i>iter-value-type</i>&lt;InputIterator&gt;, Allocator&gt;, Compare&gt;;

  template&lt;class InputIterator, class Compare, class Container, class Allocator&gt;
    priority_queue(InputIterator, InputIterator, Compare, Container, Allocator)
      -&gt; priority_queue&lt;typename Container::value_type, Container, Compare&gt;;</ins>

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

<li><p>Add the following paragraphs to 22.6.5.3 <a href="https://wg21.link/priqueue.cons.alloc">[priqueue.cons.alloc]</a>:</p>
<blockquote>
<pre>
template&lt;class InputIterator, class Alloc&gt;
  priority_queue(InputIterator first, InputIterator last, const Alloc&amp; a);
</pre>
<blockquote>
<p>-?- <i>Effects:</i> Initializes <tt>c</tt> with <tt>first</tt> as the first argument, <tt>last</tt> as
the second argument, and <tt>a</tt> as the third argument, and value-initializes <tt>comp</tt>;
calls <tt>make_heap(c.begin(), c.end(), comp)</tt>. </p>
</blockquote>
<pre>
template&lt;class InputIterator, class Alloc&gt;
  priority_queue(InputIterator first, InputIterator last, const Compare&amp; compare, const Alloc&amp; a);
</pre>
<blockquote>
<p>-?- <i>Effects:</i> Initializes <tt>c</tt> with <tt>first</tt> as the first argument, <tt>last</tt> as
the second argument, and <tt>a</tt> as the third argument, and initializes <tt>comp</tt> with <tt>compare</tt>;
calls <tt>make_heap(c.begin(), c.end(), comp)</tt>. </p>
</blockquote>
<pre>
template&lt;class InputIterator, class Alloc&gt;
  priority_queue(InputIterator first, InputIterator last, const Compare&amp; compare, const Container&amp; cont, const Alloc&amp; a);
</pre>
<blockquote>
<p>-?- <i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the first argument and <tt>a</tt> as
the second argument, and initializes <tt>comp</tt> with <tt>compare</tt>; calls <tt>c.insert(c.end(), first, last)</tt>;
and finally calls <tt>make_­heap(c.begin(), c.end(), comp)</tt>. </p>
</blockquote>
<pre>
template&lt;class InputIterator, class Alloc&gt;
  priority_queue(InputIterator first, InputIterator last, const Compare&amp; compare, Container&amp;&amp; cont, const Alloc&amp; a);
</pre>
<blockquote>
<p>-?- <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as the first argument and <tt>a</tt> as
the second argument, and initializes <tt>comp</tt> with <tt>compare</tt>; calls <tt>c.insert(c.end(), first, last)</tt>;
and finally calls <tt>make_­heap(c.begin(), c.end(), comp)</tt>. </p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3517" href="https://cplusplus.github.io/LWG/lwg-active.html#3517">3517</a>. <tt>join_view::<i>iterator</i></tt>'s <tt>iter_swap</tt> is underconstrained</h3>
<p><b>Section:</b> 24.7.11.3 <a href="https://wg21.link/range.join.iterator">[range.join.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2021-01-28 <b>Last modified:</b> 2021-01-31</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.join.iterator">active issues</a> in [range.join.iterator].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.join.iterator">issues</a> in [range.join.iterator].</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::ranges::join_view::<i>iterator</i></tt>'s hidden friend <tt>iter_swap</tt> is specified in 
24.7.11.3 <a href="https://wg21.link/range.join.iterator">[range.join.iterator]</a>/16 as:
</p>
<blockquote>
<pre>
friend constexpr void iter_swap(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  noexcept(noexcept(ranges::iter_swap(x.<i>inner_</i>, y.<i>inner_</i>)));
</pre>
<blockquote>
<p>
-16- <i>Effects:</i> Equivalent to: <tt>return ranges::iter_swap(x.<i>inner_</i>, y.<i>inner_</i>);</tt>
</p>
</blockquote>
</blockquote>
<p>
Notably, the expression <tt>ranges::iter_swap(<i>meow</i>, <i>woof</i>)</tt> is not valid for all 
iterators <tt><i>meow</i></tt> and <tt><i>woof</i></tt>, or even all input iterators of the same 
type as is the case here. This <tt>iter_swap</tt> overload should be constrained to require the 
type of <tt>iterator::<i>inner_</i></tt> (<tt>iterator_t&lt;range_reference_t&lt;<i>maybe-const</i>&lt;Const, V&gt;&gt;&gt;)</tt> 
to satisfy <tt>indirectly_swappable</tt>. Notably this is already the case for <tt>iter_swap</tt> 
friends of every other iterator adaptor in the Standard Library (<tt>reverse_iterator</tt>, <tt>move_iterator</tt>, 
<tt>common_iterator</tt>, <tt>counted_iterator</tt>, <tt>filter_view::iterator</tt>, <tt>transform_view::iterator</tt>, and <tt>split_view::<i>inner-iterator</i></tt>). The omission for <tt>join_view::<i>iterator</i></tt> seems to 
have simply been an oversight.
</p>

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

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



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

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> If <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3500">3500</a> is accepted before this issue, it is 
kindly suggested to the Project Editor to apply the equivalent replacement of
"<tt>iterator_t&lt;range_reference_t&lt;<i>Base</i>&gt;&gt;</tt>" by "<tt><i>InnerIter</i></tt>" to
the newly inserted <tt>requires</tt>.
</p>
</blockquote>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V&gt;
    requires view&lt;V&gt; &amp;&amp; input_range&lt;range_reference_t&lt;V&gt;&gt; &amp;&amp;
             (is_reference_v&lt;range_reference_t&lt;V&gt;&gt; ||
             view&lt;range_value_t&lt;V&gt;&gt;)
  template&lt;bool Const&gt;
  struct join_view&lt;V&gt;::<i>iterator</i> {
    [&hellip;]
    
    friend constexpr void iter_swap(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      noexcept(noexcept(ranges::iter_swap(x.<i>inner_</i>, y.<i>inner_</i>)))
      <ins>requires indirectly_swappable&lt;iterator_t&lt;range_reference_t&lt;<i>Base</i>&gt;&gt;&gt;</ins>;
  };
}
</pre>
</blockquote>
[&hellip;]
<blockquote>
<pre>
friend constexpr void iter_swap(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  noexcept(noexcept(ranges::iter_swap(x.<i>inner_</i>, y.<i>inner_</i>)))
  <ins>requires indirectly_swappable&lt;iterator_t&lt;range_reference_t&lt;<i>Base</i>&gt;&gt;&gt;</ins>;
</pre>
<blockquote>
<p>
-16- <i>Effects:</i> Equivalent to: <tt>return ranges::iter_swap(x.<i>inner_</i>, y.<i>inner_</i>);</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3518" href="https://cplusplus.github.io/LWG/lwg-active.html#3518">3518</a>. Exception requirements on char trait operations unclear</h3>
<p><b>Section:</b> 21.2.2 <a href="https://wg21.link/char.traits.require">[char.traits.require]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Zoe Carver <b>Opened:</b> 2021-02-01 <b>Last modified:</b> 2021-02-02</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#char.traits.require">active issues</a> in [char.traits.require].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#char.traits.require">issues</a> in [char.traits.require].</p>
<p><b>Discussion:</b></p>
<p>
21.2.2 <a href="https://wg21.link/char.traits.require">[char.traits.require]</a> p1 says:
</p>
<blockquote>
<p>
<tt>X</tt> denotes a traits class defining types and functions for the character container type 
<tt>C</tt> [&hellip;] Operations on <tt>X</tt> shall not throw exceptions.
</p>
</blockquote>
<p>
It should be clarified what "operations on <tt>X</tt>" means. For example, in <a href="https://reviews.llvm.org/D95251">this 
patch</a>, there was some confusion around the exact meaning of "operations on <tt>X</tt>". If it refers to 
the expressions specified in [tab:char.traits.req] or if it refers to all member functions of <tt>X</tt>, 
this should be worded in some clearer way. 
</p>

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

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



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

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

<blockquote>
<p>
-1- In Table [tab:char.traits.req], <tt>X</tt> denotes a traits class defining types and functions for the 
character container type <tt>C</tt>; [&hellip;] <del>Operations on <tt>X</tt> shall not throw exceptions</del><ins>No
expression which is part of the character traits requirements specified in this subclause 21.2.2 <a href="https://wg21.link/char.traits.require">[char.traits.require]</a> 
shall exit via an exception</ins>.
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3519" href="https://cplusplus.github.io/LWG/lwg-active.html#3519">3519</a>. Incomplete synopses for <tt>&lt;random&gt;</tt> classes</h3>
<p><b>Section:</b> 26.6.4 <a href="https://wg21.link/rand.eng">[rand.eng]</a>, 26.6.5 <a href="https://wg21.link/rand.adapt">[rand.adapt]</a>, 26.6.9 <a href="https://wg21.link/rand.dist">[rand.dist]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2021-02-02 <b>Last modified:</b> 2021-04-19</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">issues</a> in [rand.eng].</p>
<p><b>Discussion:</b></p>
<p>
The synopses for the engine and distribution classes in <tt>&lt;random&gt;</tt> do
not show declarations <tt>operator==</tt>, <tt>operator!=</tt>, <tt>operator&lt;&lt;</tt>, 
and <tt>operator&gt;&gt;</tt>, although they are part of the engine and distribution requirements.
<p/>
Suggested resolution:
<p/>
Add these operators as hidden friends to the respective class synopses.
</p>

<p><i>[2021-02-07: Daniel provides concrete wording]</i></p>

<p>
The proposed wording attempts to use a conservative approach in regard to exception specifications. Albeit 
26.6.4.1 <a href="https://wg21.link/rand.eng.general">[rand.eng.general]</a> p3 says that "no function described in 26.6.4 <a href="https://wg21.link/rand.eng">[rand.eng]</a> throws 
an exception" (unless specified otherwise), not all implementations have marked the equality operators 
as <tt>noexcept</tt> (But some do for their engines, such as VS 2019). [No implementations marks the IO 
stream operators as <tt>noexcept</tt> of-course, because these cannot be prevented to throw exceptions in 
general by design].
<p/>
The wording also uses hidden friends of the IO streaming operators ("inserters and extractors") as
suggested by the issue discussion, but it should be noted that at least some existing implementations use 
out-of-class free function templates for their distributions.
<p/>
Note that we intentionally don't declare any <tt>operator!=</tt>, because the auto-generated form already has
the right semantics. The wording also covers the engine adaptor class templates because similar requirements 
apply to them.
</p>

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

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


<p><i>[2021-03-12; LWG telecon]</i></p>

<p>
Set status to Tentatively Ready after discussion and poll.
<table>
<tr><th>F</th><th>A</th><th>N</th></tr>
<tr><td>10</td><td>0</td><td>0</td></tr>
</table>
</p>



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

<ol>
<li><p>Modify 26.6.4.2 <a href="https://wg21.link/rand.eng.lcong">[rand.eng.lcong]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class UIntType, UIntType a, UIntType c, UIntType m&gt;
class linear_congruential_engine {
  [&hellip;]
  <i>// constructors and seeding functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const linear_congruential_engine&amp; x, const linear_congruential_engine&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const linear_congruential_engine&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, linear_congruential_engine&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.4.3 <a href="https://wg21.link/rand.eng.mers">[rand.eng.mers]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class UIntType, size_t w, size_t n, size_t m, size_t r,
            UIntType a, size_t u, UIntType d, size_t s,
            UIntType b, size_t t,
            UIntType c, size_t l, UIntType f&gt;
class mersenne_twister_engine {
  [&hellip;]
  <i>// constructors and seeding functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const mersenne_twister_engine&amp; x, const mersenne_twister_engine&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const mersenne_twister_engine&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, mersenne_twister_engine&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.4.4 <a href="https://wg21.link/rand.eng.sub">[rand.eng.sub]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class UIntType, size_t w, size_t s, size_t r&gt;
class subtract_with_carry_engine {
  [&hellip;]
  <i>// constructors and seeding functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const subtract_with_carry_engine&amp; x, const subtract_with_carry_engine&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const subtract_with_carry_engine&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, subtract_with_carry_engine&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.5.2 <a href="https://wg21.link/rand.adapt.disc">[rand.adapt.disc]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class Engine, size_t p, size_t r&gt;
class discard_block_engine {
  [&hellip;]
  <i>// constructors and seeding functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const discard_block_engine&amp; x, const discard_block_engine&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const discard_block_engine&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, discard_block_engine&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.5.3 <a href="https://wg21.link/rand.adapt.ibits">[rand.adapt.ibits]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class Engine, size_t w, class UIntType&gt;
class independent_bits_engine {
  [&hellip;]
  <i>// constructors and seeding functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const independent_bits_engine&amp; x, const independent_bits_engine&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const independent_bits_engine&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, independent_bits_engine&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.5.4 <a href="https://wg21.link/rand.adapt.shuf">[rand.adapt.shuf]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class Engine, size_t k&gt;
class shuffle_order_engine {
  [&hellip;]
  <i>// constructors and seeding functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const shuffle_order_engine&amp; x, const shuffle_order_engine&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const shuffle_order_engine&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, shuffle_order_engine&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.2.1 <a href="https://wg21.link/rand.dist.uni.int">[rand.dist.uni.int]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class IntType = int&gt;
class uniform_int_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const uniform_int_distribution&amp; x, const uniform_int_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const uniform_int_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, uniform_int_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.2.2 <a href="https://wg21.link/rand.dist.uni.real">[rand.dist.uni.real]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class uniform_real_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const uniform_real_distribution&amp; x, const uniform_real_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const uniform_real_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, uniform_real_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.3.1 <a href="https://wg21.link/rand.dist.bern.bernoulli">[rand.dist.bern.bernoulli]</a> as indicated:</p>

<blockquote>
<pre>
class bernoulli_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const bernoulli_distribution&amp; x, const bernoulli_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const bernoulli_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, bernoulli_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.3.2 <a href="https://wg21.link/rand.dist.bern.bin">[rand.dist.bern.bin]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class IntType = int&gt;
class binomial_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const binomial_distribution&amp; x, const binomial_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const binomial_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, binomial_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.3.3 <a href="https://wg21.link/rand.dist.bern.geo">[rand.dist.bern.geo]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class IntType = int&gt;
class geometric_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const geometric_distribution&amp; x, const geometric_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const geometric_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, geometric_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.3.4 <a href="https://wg21.link/rand.dist.bern.negbin">[rand.dist.bern.negbin]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class IntType = int&gt;
class negative_binomial_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const negative_binomial_distribution&amp; x, const negative_binomial_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const negative_binomial_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, negative_binomial_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.4.1 <a href="https://wg21.link/rand.dist.pois.poisson">[rand.dist.pois.poisson]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class IntType = int&gt;
class poisson_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const poisson_distribution&amp; x, const poisson_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const poisson_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, poisson_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.4.2 <a href="https://wg21.link/rand.dist.pois.exp">[rand.dist.pois.exp]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class exponential_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const exponential_distribution&amp; x, const exponential_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const exponential_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, exponential_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.4.3 <a href="https://wg21.link/rand.dist.pois.gamma">[rand.dist.pois.gamma]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class gamma_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const gamma_distribution&amp; x, const gamma_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const gamma_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, gamma_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.4.4 <a href="https://wg21.link/rand.dist.pois.weibull">[rand.dist.pois.weibull]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class weibull_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const weibull_distribution&amp; x, const weibull_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const weibull_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, weibull_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.4.5 <a href="https://wg21.link/rand.dist.pois.extreme">[rand.dist.pois.extreme]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class extreme_value_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const extreme_value_distribution&amp; x, const extreme_value_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const extreme_value_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, extreme_value_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.5.1 <a href="https://wg21.link/rand.dist.norm.normal">[rand.dist.norm.normal]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class normal_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const normal_distribution&amp; x, const normal_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const normal_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, normal_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.5.2 <a href="https://wg21.link/rand.dist.norm.lognormal">[rand.dist.norm.lognormal]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class lognormal_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const lognormal_distribution&amp; x, const lognormal_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const lognormal_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, lognormal_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.5.3 <a href="https://wg21.link/rand.dist.norm.chisq">[rand.dist.norm.chisq]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class chi_squared_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const chi_squared_distribution&amp; x, const chi_squared_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const chi_squared_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, chi_squared_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.5.4 <a href="https://wg21.link/rand.dist.norm.cauchy">[rand.dist.norm.cauchy]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class cauchy_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const cauchy_distribution&amp; x, const cauchy_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const cauchy_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, cauchy_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.5.5 <a href="https://wg21.link/rand.dist.norm.f">[rand.dist.norm.f]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class fisher_f_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const fisher_f_distribution&amp; x, const fisher_f_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const fisher_f_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, fisher_f_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.5.6 <a href="https://wg21.link/rand.dist.norm.t">[rand.dist.norm.t]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class student_t_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const student_t_distribution&amp; x, const student_t_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const student_t_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, student_t_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.6.1 <a href="https://wg21.link/rand.dist.samp.discrete">[rand.dist.samp.discrete]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class IntType = int&gt;
class discrete_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const discrete_distribution&amp; x, const discrete_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const discrete_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, discrete_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.6.2 <a href="https://wg21.link/rand.dist.samp.pconst">[rand.dist.samp.pconst]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class piecewise_constant_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const piecewise_constant_distribution&amp; x, const piecewise_constant_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const piecewise_constant_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, piecewise_constant_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>

<li><p>Modify 26.6.9.6.3 <a href="https://wg21.link/rand.dist.samp.plinear">[rand.dist.samp.plinear]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class RealType = double&gt;
class piecewise_linear_distribution {
  [&hellip;]
  <i>// constructors and reset functions</i>
  [&hellip;]
  
  <ins><i>// equality operators</i></ins>
  <ins>friend bool operator==(const piecewise_linear_distribution&amp; x, const piecewise_linear_distribution&amp; y);</ins>

  <i>// generating functions</i>
  [&hellip;]
  
  <i>// property functions</i>
  [&hellip;]
  
  <ins><i>// inserters and extractors</i></ins>
  <ins>template&lt;class charT, class traits&gt;
    friend basic_ostream&lt;charT, traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const piecewise_linear_distribution&amp; x);
  template&lt;class charT, class traits&gt;
    friend basic_istream&lt;charT, traits&gt;&amp;
      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, piecewise_linear_distribution&amp; x);</ins>
};
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3520" href="https://cplusplus.github.io/LWG/lwg-active.html#3520">3520</a>. <tt>iter_move</tt> and <tt>iter_swap</tt> are inconsistent for <tt>transform_view::<i>iterator</i></tt></h3>
<p><b>Section:</b> 24.7.6.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2021-02-03 <b>Last modified:</b> 2021-04-19</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.transform.iterator">active issues</a> in [range.transform.iterator].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.transform.iterator">issues</a> in [range.transform.iterator].</p>
<p><b>Discussion:</b></p>
<p>
For <tt>transform_view::<i>iterator</i></tt>, <tt>iter_move</tt> is specified to operate on the
transformed value but <tt>iter_swap</tt> is specified to operate on the underlying iterator.
<p/>
Consider the following test case:
</p>
<blockquote><pre>
struct X { int x; int y; };
std::vector&lt;X&gt; v = {...};
auto t = v | views::transform(&amp;X::x);
ranges::sort(t);
</pre></blockquote>
<p>
<tt>iter_swap</tt> on <tt>t</tt>'s iterators would swap the whole <tt>X</tt>, including the 
<tt>y</tt> part, but <tt>iter_move</tt> will only move the <tt>x</tt> data member and leave 
the <tt>y</tt> part intact. Meanwhile, <tt>ranges::sort</tt> can use both <tt>iter_move</tt> and
<tt>iter_swap</tt>, and does so in at least one implementation. The mixed behavior means that we 
get neither "sort <tt>X</tt>s by their <tt>x</tt> data member" (as <tt>ranges::sort(v, {}, &amp;X::x)</tt> 
would do), nor "sort the <tt>x</tt> data member of these <tt>X</tt>s and leave the rest unchanged", 
as one might expect, but instead some arbitrary permutation of <tt>y</tt>. This seems like a
questionable state of affairs.
</p>

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

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


<p><i>[2021-03-12; LWG telecon]</i></p>

<p>
Set status to Tentatively Ready after discussion and poll.
<table>
<tr><th>F</th><th>A</th><th>N</th></tr>
<tr><td>9</td><td>0</td><td>0</td></tr>
</table>
</p>



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

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

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, copy_constructible F&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
             regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt; &amp;&amp;
             <i>can-reference</i>&lt;invoke_result_t&lt;F&amp;, range_reference_t&lt;V&gt;&gt;&gt;
  template&lt;bool Const&gt;
  class transform_view&lt;V, F&gt;::<i>iterator</i> {
    [&hellip;]
    <del>friend constexpr void iter_swap(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      noexcept(noexcept(ranges::iter_swap(x.<i>current_</i>, y.<i>current_</i>)))
      requires indirectly_swappable&lt;iterator_t&lt;<i>Base</i>&gt;&gt;;</del>
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
<del>friend constexpr void iter_swap(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
  noexcept(noexcept(ranges::iter_swap(x.<i>current_</i>, y.<i>current_</i>)))
  requires indirectly_swappable&lt;iterator_t&lt;<i>Base</i>&gt;&gt;;</del>
</pre>
<blockquote>
<p>
<del>-23- <i>Effects:</i> Equivalent to <tt>ranges::iter_swap(x.<i>current_</i>, y.<i>current_</i>)</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3521" href="https://cplusplus.github.io/LWG/lwg-active.html#3521">3521</a>. Overly strict requirements on <tt>qsort</tt> and <tt>bsearch</tt></h3>
<p><b>Section:</b> 25.12 <a href="https://wg21.link/alg.c.library">[alg.c.library]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2021-02-02 <b>Last modified:</b> 2021-02-23</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
<p><b>Discussion:</b></p>
<p>
Per 25.12 <a href="https://wg21.link/alg.c.library">[alg.c.library]</a>/2, for <tt>qsort</tt> and <tt>bsearch</tt>, we have:
</p>
<blockquote>
<p>
<i>Preconditions:</i> The objects in the array pointed to by <tt>base</tt> are of trivial type.
</p>
</blockquote>
<p>
This seems like an unnecessarily strict requirement. <tt>qsort</tt> only needs the objects to be of a 
trivially-copyable type (because it will use <tt>memcpy</tt> or equivalent to relocate them), and 
<tt>bsearch</tt> doesn't need any particular properties of the array element type. Presumably it 
would be in improvement to specify the more-precise requirements instead.
<p/>
We should also reconsider the other uses of the notion of a trivial type. It's really not a useful or 
meaningful type property by itself, because it doesn't actually require that any operations on the type 
are valid (due to the possibility of them being ambiguous or only some of them being available) and the 
places that consider it very likely actually mean <tt>is_trivially_copyable</tt> plus 
<tt>is_trivially_default_constructible</tt> instead, or perhaps <tt>is_trivially_copy_constructible</tt> 
and <tt>is_trivially_move_constructible</tt> and so on.
<p/>
Other than <tt>qsort</tt> and <tt>bsearch</tt>, the only uses of this type property in the standard are 
to constrain <tt>max_align_t</tt>, <tt>aligned_storage</tt>, <tt>aligned_union</tt>, and the element type 
of <tt>basic_string</tt> (and in the definition of the deprecated <tt>is_pod</tt> trait), all of which 
(other than <tt>is_pod</tt>) I think really mean "is trivially default constructible", not "has at least 
one eligible default constructor and all eligible default constructors are trivial". And in fact I think 
the alignment types are underspecified &mdash; we don't want to require merely that they be 
trivially-copyable, since that doesn't require any particular operation on them to actually be valid &mdash; 
we also want to require that they actually model <tt>semiregular</tt>.
</p>

<p><i>[2021-02-23; Casey Carter provides concrete wording]</i></p>


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

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



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

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

<blockquote>
<pre>
void* bsearch(const void* key, const void* base, size_t nmemb, size_t size,
             <i>c-compare-pred</i>* compar);
void* bsearch(const void* key, const void* base, size_t nmemb, size_t size,
              <i>compare-pred</i>* compar);
void qsort(void* base, size_t nmemb, size_t size, <i>c-compare-pred</i>* compar);
void qsort(void* base, size_t nmemb, size_t size, <i>compare-pred</i>* compar);
</pre>
<blockquote>
<p>
-2- <i>Preconditions:</i> <ins>For <tt>qsort</tt>, t</ins><del>T</del>he objects in the array pointed to 
by <i>base</i> are of <del>trivial</del><ins>trivially copyable</ins> type.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3522" href="https://cplusplus.github.io/LWG/lwg-active.html#3522">3522</a>. Missing requirement on <tt>InputIterator</tt> template parameter for <tt>priority_queue</tt> constructors</h3>
<p><b>Section:</b> 22.6.5 <a href="https://wg21.link/priority.queue">[priority.queue]</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> 2021-02-17 <b>Last modified:</b> 2021-02-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#priority.queue">active issues</a> in [priority.queue].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#priority.queue">issues</a> in [priority.queue].</p>
<p><b>Discussion:</b></p>
<p>
There is nothing in 22.6.5 <a href="https://wg21.link/priority.queue">[priority.queue]</a> or more generally 22.6 <a href="https://wg21.link/container.adaptors">[container.adaptors]</a>
saying that <tt>InputIterator</tt> in the following constructor templates has to be an input iterator.
</p>
<blockquote><pre>
template&lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last, const Compare&amp; x,
                    const Container&amp;);
template&lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last,
                    const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
</pre></blockquote>
<p>
The second constructor template above therefore accepts
</p>
<blockquote><pre>
std::priority_queue&lt;int&gt; x = {1, 2};
</pre></blockquote>
<p>
to produce a <tt>priority_queue</tt> that contains a single element <tt>2</tt>. This behavior seems extremely questionable.
</p>

<p><i>[2021-02-26; LWG telecon]</i></p>

<p>
Set status to Tentatively Ready after discussion and poll.
<table>
<tr><th>F</th><th>A</th><th>N</th></tr>
<tr><td>11</td><td>0</td><td>0</td></tr>
</table>
</p>



<p><b>Proposed resolution:</b></p>
<blockquote class="note">
<p>
[<i>Drafting note</i>: Because <a href="https://wg21.link/P1425">an upcoming paper</a>
provides iterator-pair constructors for other container adaptors, the wording below
adds the restriction to 22.6.1 <a href="https://wg21.link/container.adaptors.general">[container.adaptors.general]</a> so that it also
covers the constructors that will be added by that paper.
&mdash; <i>end drafting note</i>]
</p>
</blockquote>
<p>
This wording is relative to <a href="https://wg21.link/n4878">N4878</a>.
</p>

<ol>
<li><p>Add the following paragraph to 22.6.1 <a href="https://wg21.link/container.adaptors.general">[container.adaptors.general]</a> after p3:</p>
<blockquote>
<p>
<ins>-?- A constructor template of a container adaptor shall not participate in
overload resolution if it has an <tt>InputIterator</tt> template parameter and a
type that does not qualify as an input iterator is deduced for that parameter.</ins>
</p>
<p>
-4- A deduction guide for a container adaptor shall not participate in overload resolution if any of the following are true:
</p>
<ol style="list-style-type: none">
<li><p>(4.1) &mdash; It has an <tt>InputIterator</tt> template parameter and a type that does not qualify as an input iterator is deduced for that parameter.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3523" href="https://cplusplus.github.io/LWG/lwg-active.html#3523">3523</a>. <tt>iota_view::<i>sentinel</i></tt> is not always <tt>iota_view</tt>'s sentinel</h3>
<p><b>Section:</b> 24.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> Tim Song <b>Opened:</b> 2021-02-17 <b>Last modified:</b> 2021-02-18</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.iota.view">issues</a> in [range.iota.view].</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P1739R4">P1739R4</a> added the following constructor to
<tt>iota_view</tt>:
</p>
<blockquote><pre>
constexpr iota_view(<i>iterator</i> first, <i>sentinel</i> last) : iota_view(*first, last.<i>bound_</i>) {}
</pre></blockquote>
<p>
However, while <tt>iota_view</tt>'s iterator type is always <tt>iota_view::<i>iterator</i></tt>, its sentinel type
is not always <tt>iota_view::<i>sentinel</i></tt>. First, if <tt>Bound</tt> is <tt>unreachable_sentinel_t</tt>, then
the sentinel type is <tt>unreachable_sentinel_t</tt> too - we don't add an unnecessary level of wrapping
on top. Second, when <tt>W</tt> and <tt>Bound</tt> are the same type, <tt>iota_view</tt> models <tt>common_range</tt>, and
the sentinel type is the same as the iterator type - that is, <tt><i>iterator</i></tt>, not <tt><i>sentinel</i></tt>.
</p>
<p>
Presumably the intent is to use the view's actual sentinel type, rather than always use the
<tt><i>sentinel</i></tt> type.
</p>

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

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



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

<ol>
<li><p>Edit 24.6.4.2 <a href="https://wg21.link/range.iota.view">[range.iota.view]</a>, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  // [...]

  template&lt;weakly_­incrementable W, semiregular Bound = unreachable_sentinel_t&gt;
    requires <i>weakly-equality-comparable-with</i>&lt;W, Bound&gt; &amp;&amp; semiregular&lt;W&gt;
  class iota_view : public view_interface&lt;iota_view&lt;W, Bound&gt;&gt; {
  private:
    // [range.iota.iterator], class iota_­view​::​iterator
    struct <i>iterator</i>;            // exposition only
    // [range.iota.sentinel], class iota_­view​::​sentinel
    struct <i>sentinel</i>;            // exposition only
    W <i>value_</i> = W();             // exposition only
    Bound <i>bound_</i> = Bound();     // exposition only
  public:
    iota_view() = default;
    constexpr explicit iota_view(W value);
    constexpr iota_view(type_identity_t&lt;W&gt; value,
                        type_identity_t&lt;Bound&gt; bound);
    constexpr iota_view(<i>iterator</i> first, <i><del>sentinel</del><ins>see below</ins></i> last)<ins>;</ins><del>: iota_view(*first, last.<i>bound_</i>) {}</del>

    constexpr <i>iterator</i> begin() const;
    constexpr auto end() const;
    constexpr <i>iterator</i> end() const requires same_­as&lt;W, Bound&gt;;

    constexpr auto size() const requires see below;
  };

  template&lt;class W, class Bound&gt;
      requires (!<i>is-integer-like</i>&lt;W&gt; || !<i>is-integer-like</i>&lt;Bound&gt; ||
              (<i>is-signed-integer-like</i>&lt;W&gt; == <i>is-signed-integer-like</i>&lt;Bound&gt;))
      iota_view(W, Bound) -&gt; iota_view&lt;W, Bound&gt;;
}
</pre>
<p>[...]</p>
<pre>
constexpr iota_view(type_identity_t&lt;W&gt; value, type_identity_t&lt;Bound&gt; bound);
</pre>
<blockquote>
<p>-8- <i>Preconditions</i>: <tt>Bound</tt> denotes <tt>unreachable_­sentinel_­t</tt> or <tt>bound</tt> is reachable
from <tt>value</tt>. When <tt>W</tt> and <tt>Bound</tt> model <tt>totally_­ordered_­with</tt>, then <tt>bool(value &lt;= bound)</tt> is true.</p>
<p>-9- <i>Effects</i>: Initializes <tt><i>value_</i></tt>­ with <tt>value</tt> and <tt><i>bound_</i></tt> with <tt>bound</tt>.</p>
</blockquote>
<pre>
<ins>constexpr iota_view(<i>iterator</i> first, <i>see below</i> last);</ins>
</pre>
<blockquote>
<p><ins>-?- <i>Effects</i>: Equivalent to:</ins></p>
<ol style="list-style-type: none">
<li><p><ins>(?.1) &mdash; If <tt>same_as&lt;W, Bound&gt;</tt> is <tt>true</tt>, <tt>iota_view(first.<i>value_</i>, last.<i>value_</i>)</tt>.</ins></p></li>
<li><p><ins>(?.2) &mdash; Otherwise, if <tt>Bound</tt> denotes <tt>unreachable_sentinel_t</tt>, <tt>iota_view(first.<i>value_</i>, last)</tt>.</ins></p></li>
<li><p><ins>(?.3) &mdash; Otherwise, <tt>iota_view(first.<i>value_</i>, last.<i>bound_</i>)</tt>.</ins></p></li>
</ol>
<p><ins>-?- <i>Remarks</i>: The type of <tt>last</tt> is:</ins></p>
<ol style="list-style-type: none">
<li><p><ins>(?.1) &mdash; If <tt>same_as&lt;W, Bound&gt;</tt> is <tt>true</tt>, <tt><i>iterator</i></tt>.</ins></p></li>
<li><p><ins>(?.2) &mdash; Otherwise, if <tt>Bound</tt> denotes <tt>unreachable_sentinel_t</tt>, <tt>Bound</tt>.</ins></p></li>
<li><p><ins>(?.3) &mdash; Otherwise, <tt><i>sentinel</i></tt>.</ins></p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3526" href="https://cplusplus.github.io/LWG/lwg-active.html#3526">3526</a>. Return types of <tt>uses_allocator_construction_args</tt> unspecified</h3>
<p><b>Section:</b> 20.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2021-02-25 <b>Last modified:</b> 2021-05-26</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#allocator.uses.construction">active issues</a> in [allocator.uses.construction].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#allocator.uses.construction">issues</a> in [allocator.uses.construction].</p>
<p><b>Discussion:</b></p>
<p>
The synopsis of <tt>&lt;memory&gt;</tt> in 20.10.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a> declares six overloads of 
<tt>uses_allocator_construction_args</tt> with return types "<i>see below</i>":
</p>
<blockquote><pre>
template&lt;class T, class Alloc, class... Args&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  Args&amp;&amp;... args) noexcept -&gt; <i>see below</i>;
template&lt;class T, class Alloc, class Tuple1, class Tuple2&gt;>
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, piecewise_construct_t,
                                                  Tuple1&amp;&amp; x, Tuple2&amp;&amp; y)
                                                  noexcept -&gt; see below;
template&lt;class T, class Alloc&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc) noexcept -&gt; <i>see below</i>;
template&lt;class T, class Alloc, class U, class V&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  U&amp;&amp; u, V&amp;&amp; v) noexcept -&gt; <i>see below</i>;
template&lt;class T, class Alloc, class U, class V&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  const pair&lt;U, V&gt;&amp; pr) noexcept -&gt; <i>see below</i>;
template&lt;class T, class Alloc, class U, class V>
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  pair&lt;U, V&gt;&amp;&amp; pr) noexcept -&gt; <i>see below</i>;
</pre></blockquote>
<p>
The "<i>see below</i>s" also appear in the detailed specification of these overloaded function templates 
in 20.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> para 4 through 15. Despite that the values these function 
templates return are specified therein, the return types are not. Presumably LWG wanted to specify deduced 
return types, but couldn't figure out how to do so, and just gave up?
</p>

<p><i>[2021-02-27; Daniel comments and provides wording]</i></p>

<p>
My interpretation is that the appearance of the <i>trailing-return-type</i> was actually unintended and that
these functions where supposed to use the return type placeholder to signal the intention that the actual
return type is deduced by the consistent sum of all return statements as they appear in the prototype specifications.
Given that at least one implementation has indeed realized this form, I suggest to simply adjust the specification
to remove the <i>trailing-return-type</i>. Specification-wise we have already existing practice for this 
approach (See e.g. <tt>to_address</tt>).
</p>

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

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


<p><i>[2021-05-26; Reflector poll]</i></p>

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



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

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

<blockquote>
<pre>
namespace std {
  [&hellip;]
  <i>// 20.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>, uses-allocator construction</i>
  template&lt;class T, class Alloc, class... Args&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    Args&amp;&amp;... args) noexcept <del>-&gt; <i>see below</i></del>;
  template&lt;class T, class Alloc, class Tuple1, class Tuple2&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, piecewise_construct_t,
                                                    Tuple1&amp;&amp; x, Tuple2&amp;&amp; y)
                                                    noexcept <del>-&gt; <i>see below</i></del>;
  template&lt;class T, class Alloc&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc) noexcept <del>-&gt; <i>see below</i></del>;
  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    U&amp;&amp; u, V&amp;&amp; v) noexcept <del>-&gt; <i>see below</i></del>;
  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    const pair&lt;U, V&gt;&amp; pr) noexcept <del>-&gt; <i>see below</i></del>;
  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    pair&lt;U, V&gt;&amp;&amp; pr) noexcept <del>-&gt; <i>see below</i></del>;   
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Edit 20.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T, class Alloc, class... Args&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  Args&amp;&amp;... args) noexcept <del>-&gt; <i>see below</i></del>;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-5- <i>Returns:</i> A <tt>tuple</tt> value determined as follows:
</p>
<ol style="list-style-type: none">
<li><p>(5.1) &mdash; if [&hellip;], return <tt>forward_as_tuple(std::forward&lt;Args&gt;(args)...)</tt>.</p></li>
<li><p>(5.2) &mdash; Otherwise, if [&hellip;], return</p>
<blockquote><pre>
tuple&lt;allocator_arg_t, const Alloc&amp;, Args&amp;&amp;...&gt;(
  allocator_arg, alloc, std::forward&lt;Args&gt;(args)...)
</pre></blockquote>
</li>
<li><p>(5.3) &mdash; Otherwise, if [&hellip;], return <tt>forward_as_tuple(std::forward&lt;Args&gt;(args)..., alloc)</tt>.</p></li>
<li><p>(5.4) &mdash; Otherwise, the program is ill-formed.</p></li>
</ol>
</blockquote>
<pre>
template&lt;class T, class Alloc, class Tuple1, class Tuple2&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, piecewise_construct_t,
                                                  Tuple1&amp;&amp; x, Tuple2&amp;&amp; y)
                                                  noexcept <del>-&gt; <i>see below</i></del>;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-7- <i>Effects:</i> For <tt>T</tt> specified as <tt>pair&lt;T1, T2&gt;</tt>, equivalent to:
</p>
<blockquote><pre>
return make_tuple(
  piecewise_construct,
  apply([&amp;alloc](auto&amp;&amp;... args1) {
          return uses_allocator_construction_args&lt;T1&gt;(
            alloc, std::forward&lt;decltype(args1)&gt;(args1)...);
        }, std::forward&lt;Tuple1&gt;(x)),
  apply([&amp;alloc](auto&amp;&amp;... args2) {
          return uses_allocator_construction_args&lt;T2&gt;(
            alloc, std::forward&lt;decltype(args2)&gt;(args2)...);
        }, std::forward&lt;Tuple2&gt;(y)));
</pre></blockquote>
</blockquote>
<pre>
template&lt;class T, class Alloc&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc) noexcept <del>-&gt; <i>see below</i></del>;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-9- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return uses_allocator_construction_args&lt;T&gt;(alloc, piecewise_construct,
                                           tuple&lt;&gt;{}, tuple&lt;&gt;{});
</pre></blockquote>
</blockquote>
<pre>
template&lt;class T, class Alloc, class U, class V&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  U&amp;&amp; u, V&amp;&amp; v) noexcept <del>-&gt; <i>see below</i></del>;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-11- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return uses_allocator_construction_args&lt;T&gt;(alloc, piecewise_construct,
                                           forward_as_tuple(std::forward&lt;U&gt;(u)),
                                           forward_as_tuple(std::forward&lt;V&gt;(v));
</pre></blockquote>
</blockquote>
<pre>
template&lt;class T, class Alloc, class U, class V&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  const pair&lt;U, V&gt;&amp; pr) noexcept <del>-&gt; <i>see below</i></del>;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-13- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return uses_allocator_construction_args&lt;T&gt;(alloc, piecewise_construct,
                                           forward_as_tuple(pr.first),
                                           forward_as_tuple(pr.second));
</pre></blockquote>
</blockquote>
<pre>
template&lt;class T, class Alloc, class U, class V&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  pair&lt;U, V&gt;&amp;&amp; pr) noexcept <del>-&gt; <i>see below</i></del>;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return uses_allocator_construction_args&lt;T&gt;(alloc, piecewise_construct,
                                           forward_as_tuple(std::move(pr).first),
                                           forward_as_tuple(std::move(pr).second));
</pre></blockquote>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3527" href="https://cplusplus.github.io/LWG/lwg-active.html#3527">3527</a>. <tt>uses_allocator_construction_args</tt> handles rvalue pairs of rvalue references incorrectly</h3>
<p><b>Section:</b> 20.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2021-02-27 <b>Last modified:</b> 2021-02-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#allocator.uses.construction">active issues</a> in [allocator.uses.construction].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#allocator.uses.construction">issues</a> in [allocator.uses.construction].</p>
<p><b>Discussion:</b></p>
<p>
For an rvalue pair <tt>pr</tt>, <tt>uses_allocator_construction_args</tt> is specified to forward
<tt>std::move(pr).first</tt> and <tt>std::move(pr).second</tt>. This is correct
for non-references and lvalue references, but wrong for rvalue refrences because
the class member access produces an lvalue (see 7.6.1.5 <a href="https://wg21.link/expr.ref">[expr.ref]</a>/6).
<tt>get</tt> produces an xvalue, which is what is desired here.
</p>

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

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



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

<ol>
<li><p>Edit 20.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class T, class Alloc, class U, class V&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  pair&lt;U, V&gt;&amp;&amp; pr) noexcept -&gt; <i>see below</i>;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return uses_allocator_construction_args&lt;T&gt;(alloc, piecewise_construct,
                                            forward_as_tuple(<del>std::move(pr).first</del><ins>get&lt;0&gt;(std::move(pr))</ins>),
                                            forward_as_tuple(<del>std::move(pr).second</del><ins>get&lt;1&gt;(std::move(pr))</ins>));
</pre></blockquote>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3528" href="https://cplusplus.github.io/LWG/lwg-active.html#3528">3528</a>. <tt>make_from_tuple</tt> can perform (the equivalent of) a C-style cast</h3>
<p><b>Section:</b> 20.5.5 <a href="https://wg21.link/tuple.apply">[tuple.apply]</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> 2021-02-28 <b>Last modified:</b> 2021-03-12</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
<tt>make_from_tuple</tt> is specified to return <tt>T(get&lt;I&gt;(std::forward&lt;Tuple&gt;(t))...)</tt>.
When there is only a single tuple element, this is equivalent to a C-style cast
that may be a <tt>reinterpret_cast</tt>, a <tt>const_cast</tt>,
or an access-bypassing <tt>static_cast</tt>.
</p>

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

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



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

<ol>
<li><p>Edit 20.5.5 <a href="https://wg21.link/tuple.apply">[tuple.apply]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class T, class Tuple&gt;
  constexpr T make_from_tuple(Tuple&amp;&amp; t);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-2- <i>Effects:</i>  Given the exposition-only function:
</p>
<blockquote><pre>
template&lt;class T, class Tuple, size_t... I&gt;
<ins>  requires is_constructible_v&lt;T, decltype(get&lt;I&gt;(declval&lt;Tuple&gt;()))...></ins>
constexpr T <i>make-from-tuple-impl</i>(Tuple&amp;&amp; t, index_sequence&lt;I...&gt;) {     // exposition only
  return T(get&lt;I&gt;(std::forward&lt;Tuple&gt;(t))...);
}
</pre></blockquote>
<p>
Equivalent to:
</p>
<blockquote><pre>
return <i>make-from-tuple-impl</i>&lt;T&gt;(
  <ins>std::</ins>forward&lt;Tuple&gt;(t),
  make_index_sequence&lt;tuple_size_v&lt;remove_reference_t&lt;Tuple&gt;&gt;&gt;{});
</pre></blockquote>
<p>
[<i>Note 1:</i> The type of T must be supplied as an explicit template parameter,
as it cannot be deduced from the argument list. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3529" href="https://cplusplus.github.io/LWG/lwg-active.html#3529">3529</a>. <code>priority_queue(first, last)</code> should construct <code>c</code> with <code>(first, last)</code></h3>
<p><b>Section:</b> 22.6.5 <a href="https://wg21.link/priority.queue">[priority.queue]</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> 2021-03-01 <b>Last modified:</b> 2021-03-05</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#priority.queue">active issues</a> in [priority.queue].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#priority.queue">issues</a> in [priority.queue].</p>
<p><b>Discussion:</b></p>
<p>
Tim's new constructors for <code>priority_queue</code> (LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3506">3506</a>)
are specified so that when you construct
</p>
<blockquote>
<pre>
auto pq = PQ(first, last, a);
</pre>
</blockquote>
<p>
it calls this new-in-LWG3506 constructor:
</p>
<blockquote>
<pre>
template&lt;class InputIterator, class Alloc&gt;
  priority_queue(InputIterator first, InputIterator last, const Alloc&amp; a);
</pre>
<p>
<i>Effects:</i>
Initializes <code>c</code> with <code>first</code> as the first argument,
<code>last</code> as the second argument,
and <code>a</code> as the third argument,
and value-initializes <code>comp</code>;
calls <code>make_heap(c.begin(), c.end(), comp)</code>.
</p>
</blockquote>
<p>
But the pre-existing constructors are specified so that when you construct
</p>
<blockquote>
<pre>
auto pq = PQ(first, last);
</pre>
</blockquote>
<p>
it calls this pre-existing constructor:
</p>
<blockquote>
<pre>
template&lt;class InputIterator&gt;
  priority_queue(InputIterator first, InputIterator last, const Compare&amp; x = Compare(), Container&amp;&amp; y = Container());
</pre>
<p>
<i>Preconditions:</i>
<code>x</code> defines a strict weak ordering ([alg.sorting]).
</p>
<p>
<i>Effects:</i>
Initializes <code>comp</code> with <code>x</code>
and <code>c</code> with <code>y</code>
(copy constructing or move constructing as appropriate);
calls <code>c.insert(c.end(), first, last)</code>;
and finally calls <code>make_heap(c.begin(), c.end(), comp)</code>.
</p>
</blockquote>

<p>
In other words,
</p>
<blockquote>
<pre>
auto pq = PQ(first, last);
</pre>
</blockquote>
<p>
will default-construct a <code>Container</code>,
then move-construct <code>c</code> from that object,
then <code>c.insert(first, last)</code>,
and finally <code>make_heap</code>.
</p>
<p>
But our new
</p>
<blockquote>
<pre>
auto pq = PQ(first, last, a);
</pre>
</blockquote>
<p>
will simply construct <code>c</code> with <code>(first, last)</code>,
then <code>make_heap</code>.
</p>
<p>
The latter is obviously better.
</p>
<p>
Also, Corentin's <a href="https://wg21.link/p1425r3">P1425R3</a>
specifies the new iterator-pair constructors for
<code>stack</code> and <code>queue</code>
to construct <code>c</code> from <code>(first, last)</code>. Good.
</p>
<p>
LWG should refactor the existing constructor overload set so that
the existing non-allocator-taking constructors simply construct <code>c</code>
from <code>(first, last)</code>.
This will improve consistency with the resolutions of LWG3506 and P1425,
and reduce the surprise factor for users.
</p>

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

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



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

<ol>
<li>
<p>Edit 22.6.5.1 <a href="https://wg21.link/priqueue.overview">[priqueue.overview]</a> as indicated:</p>

<blockquote>
<pre>
<ins>
template&lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last, const Compare&amp; x = Compare());</ins>
template&lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last, const Compare&amp; x, const Container&amp; y);
template&lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last, const Compare&amp; x<del><del> = Compare()</del></del>, Container&amp;&amp; y<del> = Container()</del>);
</pre>
</blockquote>
</li>

<li>
<p>Edit 22.6.5.2 <a href="https://wg21.link/priqueue.cons">[priqueue.cons]</a> as indicated:</p>

<blockquote>
<pre>
<ins>
template&lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last, const Compare&amp; x = Compare());
</ins>
</pre>
<p>
<ins>
<i>Preconditions:</i>
<code>x</code> defines a strict weak ordering ([alg.sorting]).
</ins>
</p>
<p>
<ins>
<i>Effects:</i>
Initializes <code>c</code> with <code>first</code> as the first argument and <code>last</code> as the second argument, and initializes <code>comp</code> with <code>x</code>; then calls <code>make_heap(c.begin(), c.end(), comp)</code>.
</ins>
</p>

<pre>
template&lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last, const Compare&amp; x, const Container&amp; y);
template&lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last, const Compare&amp; x<del> = Compare()</del>, Container&amp;&amp; y<del> = Container()</del>);
</pre>
<p>
<i>Preconditions:</i>
<code>x</code> defines a strict weak ordering ([alg.sorting]).
</p>
<p>
<i>Effects:</i>
Initializes <code>comp</code> with <code>x</code> and <code>c</code> with <code>y</code> (copy constructing or
move constructing as appropriate); calls <code>c.insert(c.end(), first, last)</code>;
and finally calls <code>make_heap(c.begin(), c.end(), comp)</code>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3530" href="https://cplusplus.github.io/LWG/lwg-active.html#3530">3530</a>. <tt><i>BUILTIN-PTR-MEOW</i></tt> should not opt the type out of syntactic checks</h3>
<p><b>Section:</b> 20.14.8.8 <a href="https://wg21.link/comparisons.three.way">[comparisons.three.way]</a>, 20.14.9 <a href="https://wg21.link/range.cmp">[range.cmp]</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> 2021-03-04 <b>Last modified:</b> 2021-03-08</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The use of <tt><i>BUILTIN-PTR-MEOW</i></tt> for the constrained comparison
function objects was needed to disable the semantic requirements on the
associated concepts when the comparison resolves to a built-in operator
comparing pointers: the comparison object is adding special handling for this
case to produce a total order despite the core language saying otherwise,
so requiring the built-in operator to then produce a total order as part
of the semantic requirements doesn't make sense.
<p/>
However, because it is specified as a disjunction on the constraint,
it means that the comparison function objects are now required to accept
types that don't even meet the syntactic requirements of the associated
concept. For example, <tt>ranges::less</tt> requires all six comparison operators
(because of <tt>totally_ordered_with</tt>) to be present &hellip; except when
<tt>operator&lt;</tt> on the arguments resolves to a built-in operator comparing
pointers, in which case it just requires <tt>operator&lt;</tt> and <tt>operator==</tt>
(except that the latter isn't even required to be checked &mdash; it comes from the use
of <tt>ranges::equal_to</tt> in the precondition of <tt>ranges::less</tt>).
This seems entirely arbitrary.
</p>

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

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



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

<ol>
<li><p>Edit 20.14.8.8 <a href="https://wg21.link/comparisons.three.way">[comparisons.three.way]</a> as indicated:</p>
<blockquote>
<p>
<del>-1- In this subclause, <tt><i>BUILTIN-PTR-THREE-WAY</i>(T, U)</tt> for types <tt>T</tt>
and <tt>U</tt> is a boolean constant expression. <tt><i>BUILTIN-PTR-THREE-WAY</i>(T, U)</tt>
is true if and only if <tt>&lt;=&gt;</tt> in the expression</del>
</p>
<blockquote><pre>
<del>declval&lt;T&gt;() &lt;=&gt; declval&lt;U&gt;()</del>
</pre></blockquote>
<p><del>resolves to a built-in operator comparing pointers.</del></p>

<pre>
struct compare_three_way {
  template&lt;class T, class U&gt;
    <del>requires three_way_comparable_with&lt;T, U&gt; || <i>BUILTIN-PTR-THREE-WAY</i>(T, U)</del>
  constexpr auto operator()(T&amp;&amp; t, U&amp;&amp; u) const;

  using is_transparent = <i>unspecified</i>;
};
</pre>

<pre>
template&lt;class T, class U&gt;
  <del>requires three_way_comparable_with&lt;T, U&gt; || <i>BUILTIN-PTR-THREE-WAY</i>(T, U)</del>
constexpr auto operator()(T&amp;&amp; t, U&amp;&amp; u) const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> and <tt>U</tt> satisfy <tt>three_way_comparable_with</tt>.</ins>
<p/>
-2- <i>Preconditions:</i> If the expression
<tt>std​::​forward&lt;T&gt;(t) &lt;=&gt; std​::​forward&lt;U&gt;(u)</tt> results in a call
to a built-in operator <tt>&lt;=&gt;</tt> comparing pointers of type <tt>P</tt>, the conversion
sequences from both <tt>T</tt> and <tt>U</tt> to <tt>P</tt> are equality-preserving
(18.2 <a href="https://wg21.link/concepts.equality">[concepts.equality]</a>)<ins>; otherwise, <tt>T</tt> and <tt>U</tt>
model <tt>three_way_comparable_with</tt></ins>.
<p/>
-3- <i>Effects:</i></p>
<ol style="list-style-type: none">
<li><p>
(3.1) &mdash; If the expression <tt>std​::​forward&lt;T&gt;(t) &lt;=&gt; std​::​forward&lt;U&gt;(u)</tt>
results in a call to a built-in operator <tt>&lt;=&gt;</tt> comparing pointers of type <tt>P</tt>,
returns <tt>strong_­ordering​::​less</tt> if (the converted value of) <tt>t</tt> precedes <tt>u</tt> in
the implementation-defined strict total order over pointers (3.27 <a href="https://wg21.link/defns.order.ptr">[defns.order.ptr]</a>),
<tt>strong_­ordering​::​greater</tt> if <tt>u</tt> precedes <tt>t</tt>, and otherwise <tt>strong_­ordering​::​equal</tt>.
</p>
</li>
<li><p>
(3.2) &mdash; Otherwise, equivalent to: <tt>return std​::​forward&lt;T&gt;(t) &lt;=&gt; std​::​forward&lt;U&gt;(u);</tt>
</p></li>
</ol>
</blockquote>
</blockquote>
</li>
<li><p>Edit 20.14.9 <a href="https://wg21.link/range.cmp">[range.cmp]</a> as indicated:</p>
<blockquote>
<p>
<del>-1- In this subclause, <tt><i>BUILTIN-PTR-CMP</i>(T,</tt> <i>op</i><tt>, U)</tt>
for types <tt>T</tt> and <tt>U</tt> and where <i>op</i> is an equality (7.6.10 <a href="https://wg21.link/expr.eq">[expr.eq]</a>)
or relational operator (7.6.9 <a href="https://wg21.link/expr.rel">[expr.rel]</a>) is a boolean constant expression.
<tt><i>BUILTIN-PTR-CMP</i>(T,</tt> <i>op</i><tt>, U)</tt>
is true if and only if <i>op</i> in the expression
<tt>declval&lt;T&gt;()</tt> <i>op</i> <tt>declval&lt;U&gt;()</tt>
resolves to a built-in operator comparing pointers.</del></p>

<pre>
struct ranges::equal_to {
  template&lt;class T, class U&gt;
    <del>requires equality_comparable_with&lt;T, U&gt; || <i>BUILTIN-PTR-CMP</i>(T, ==, U)</del>
  constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;

  using is_transparent = <i>unspecified</i>;
};
</pre>

<pre>
template&lt;class T, class U&gt;
  <del>requires equality_comparable_with&lt;T, U&gt; || <i>BUILTIN-PTR-CMP</i>(T, ==, U)</del>
constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> and <tt>U</tt> satisfy <tt>equality_comparable_with</tt>.</ins>
<p/>
-2- <i>Preconditions:</i> If the expression
<tt>std​::​forward&lt;T&gt;(t) == std​::​forward&lt;U&gt;(u)</tt> results in a call
to a built-in operator <tt>==</tt> comparing pointers of type <tt>P</tt>, the conversion
sequences from both <tt>T</tt> and <tt>U</tt> to <tt>P</tt> are equality-preserving
(18.2 <a href="https://wg21.link/concepts.equality">[concepts.equality]</a>)<ins>; otherwise, <tt>T</tt> and <tt>U</tt>
model <tt>equality_comparable_with</tt></ins>.
<p/>
-3- <i>Effects:</i></p>
<ol style="list-style-type: none">
<li><p>
(3.1) &mdash; If the expression <tt>std​::​forward&lt;T&gt;(t) == std​::​forward&lt;U&gt;(u)</tt>
results in a call to a built-in operator <tt>==</tt> comparing pointers of type <tt>P</tt>,
returns <tt>false</tt> if either (the converted value of) <tt>t</tt> precedes <tt>u</tt> or <tt>u</tt>
precedes <tt>t</tt> in the implementation-defined strict total order over pointers
(3.27 <a href="https://wg21.link/defns.order.ptr">[defns.order.ptr]</a>) and otherwise <tt>true</tt>.
</p>
</li>
<li><p>
(3.2) &mdash; Otherwise, equivalent to: <tt>return std​::​forward&lt;T&gt;(t) == std​::​forward&lt;U&gt;(u);</tt>
</p>
</li>
</ol>
</blockquote>
<pre>
struct ranges::not_equal_to {
    template&lt;class T, class U&gt;
        <del>requires equality_comparable_with&lt;T, U&gt; || <i>BUILTIN-PTR-CMP</i>(T, ==, U)</del>
    constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;

    using is_transparent = <i>unspecified</i>;
};
</pre>

<pre>
<ins>template&lt;class T, class U&gt;
constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> and <tt>U</tt> satisfy <tt>equality_comparable_with</tt>.</ins>
<p/>
-4- <del><tt>operator()</tt> has effects e</del><ins><i>Effects:</i> E</ins>quivalent to:</p>
<blockquote><pre>
return !ranges::equal_to{}(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u));
</pre></blockquote>
</blockquote>
<pre>
struct ranges::greater {
  template&lt;class T, class U&gt;
    <del>requires totally_ordered_with&lt;T, U&gt; || <i>BUILTIN-PTR-CMP</i>(T, &lt;, U)</del>
  constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;

  using is_transparent = <i>unspecified</i>;
};
</pre>

<pre>
template&lt;class T, class U&gt;
constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> and <tt>U</tt> satisfy <tt>totally_ordered_with</tt>.</ins>
<p/>
-5- <del><tt>operator()</tt> has effects e</del><ins><i>Effects:</i> E</ins>quivalent to:</p>
<blockquote><pre>
return ranges::less{}(std::forward&lt;U&gt;(u), std::forward&lt;T&gt;(t));
</pre></blockquote>
</blockquote>

<pre>
struct ranges::less {
  template&lt;class T, class U&gt;
    <del>requires totally_ordered_with&lt;T, U&gt; || <i>BUILTIN-PTR-CMP</i>(T, &lt;, U)</del>
  constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;

  using is_transparent = <i>unspecified</i>;
};
</pre>

<pre>
template&lt;class T, class U&gt;
  <del>requires totally_ordered_with&lt;T, U&gt; || <i>BUILTIN-PTR-CMP</i>(T, &lt;, U)</del>
constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> and <tt>U</tt> satisfy <tt>totally_ordered_with</tt>.</ins>
<p/>
-6- <i>Preconditions:</i> If the expression
<tt>std​::​forward&lt;T&gt;(t) &lt; std​::​forward&lt;U&gt;(u)</tt> results in a call
to a built-in operator <tt>&lt;</tt> comparing pointers of type <tt>P</tt>, the conversion
sequences from both <tt>T</tt> and <tt>U</tt> to <tt>P</tt> are equality-preserving
(18.2 <a href="https://wg21.link/concepts.equality">[concepts.equality]</a>)<ins>; otherwise, <tt>T</tt> and <tt>U</tt>
model <tt>totally_ordered_with</tt></ins>.
For any expressions <tt>ET</tt> and <tt>EU</tt> such that <tt>decltype((ET))</tt> is <tt>T</tt> and
<tt>decltype((EU))</tt> is <tt>U</tt>, exactly one of <tt>ranges::less{}(ET, EU)</tt>, <tt>ranges::less{}(EU, ET)</tt>,
or <tt>ranges::equal_to{}(ET, EU)</tt> is <tt>true</tt>.
<p/>
-7- <i>Effects:</i></p>
<ol style="list-style-type: none">
<li><p>
(7.1) &mdash; If the expression <tt>std​::​forward&lt;T&gt;(t) &lt; std​::​forward&lt;U&gt;(u)</tt>
results in a call to a built-in operator <tt>&lt;</tt> comparing pointers of type <tt>P</tt>,
returns <tt>true</tt> if (the converted value of) <tt>t</tt> precedes <tt>u</tt> in the
implementation-defined strict total order over pointers (3.27 <a href="https://wg21.link/defns.order.ptr">[defns.order.ptr]</a>)
and otherwise <tt>false</tt>.
</p>
</li>
<li><p>
(7.2) &mdash; Otherwise, equivalent to: <tt>return std​::​forward&lt;T&gt;(t) &lt; std​::​forward&lt;U&gt;(u);</tt>
</p>
</li>
</ol>
</blockquote>
<pre>
struct ranges::greater_equal {
  template&lt;class T, class U&gt;
    <del>requires totally_ordered_with&lt;T, U&gt; || <i>BUILTIN-PTR-CMP</i>(T, &lt;, U)</del>
  constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;

  using is_transparent = <i>unspecified</i>;
};
</pre>

<pre>
<ins>template&lt;class T, class U&gt;
constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> and <tt>U</tt> satisfy <tt>totally_ordered_with</tt>.</ins>
<p/>
-8- <del><tt>operator()</tt> has effects e</del><ins><i>Effects:</i> E</ins>quivalent to:</p>
<blockquote><pre>
return !ranges::less{}(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u));
</pre></blockquote>
</blockquote>

<pre>
struct ranges::less_equal {
  template&lt;class T, class U&gt;
    <del>requires totally_ordered_with&lt;T, U&gt; || <i>BUILTIN-PTR-CMP</i>(T, &lt;, U)</del>
  constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;

  using is_transparent = <i>unspecified</i>;
};
</pre>

<pre>
<ins>template&lt;class T, class U&gt;
constexpr bool operator()(T&amp;&amp; t, U&amp;&amp; u) const;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> and <tt>U</tt> satisfy <tt>totally_ordered_with</tt>.</ins>
<p/>
-9- <del><tt>operator()</tt> has effects e</del><ins><i>Effects:</i> E</ins>quivalent to:</p>
<blockquote><pre>
return !ranges::less{}(std::forward&lt;U&gt;(u), std::forward&lt;T&gt;(t));
</pre></blockquote>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3532" href="https://cplusplus.github.io/LWG/lwg-active.html#3532">3532</a>. <tt>split_view&lt;V, P&gt;::<i>inner-iterator</i>&lt;true&gt;::operator++(int)</tt> should depend on <tt><i>Base</i></tt></h3>
<p><b>Section:</b> 24.7.12.5 <a href="https://wg21.link/range.split.inner">[range.split.inner]</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> 2021-03-11 <b>Last modified:</b> 2021-04-20</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<tt>split_view&lt;V, P&gt;::<i>inner-iterator</i>&lt;Const&gt;::operator++(int)</tt> is specified directly in the 
synopsis in 24.7.12.5 <a href="https://wg21.link/range.split.inner">[range.split.inner]</a> as:
</p>
<blockquote><pre>
constexpr decltype(auto) operator++(int) {
  if constexpr (forward_range&lt;V&gt;) {
    auto tmp = *this;
    ++*this;
    return tmp;
  } else
    ++*this;
}
</pre></blockquote>
<p>
The dependency on the properties of <tt>V</tt> here is odd given that we are wrapping an iterator obtained from a 
<tt><i>maybe-const</i>&lt;Const, V&gt;</tt> (aka <tt><i>Base</i></tt>). It seems like this function should instead 
be concerned with <tt>forward_range&lt;<i>Base</i>&gt;</tt>.
</p>

<p><i>[2021-04-20; Reflector poll]</i></p>

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



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


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

<blockquote>
<pre>
constexpr decltype(auto) operator++(int) {
  if constexpr (forward_range&lt;<del>V</del><ins><i>Base</i></ins>&gt;) {
    auto tmp = *this;
    ++*this;
    return tmp;
  } else
    ++*this;
}
</pre>
</blockquote>

</li>

</ol>






<hr>
<h3><a name="3533" href="https://cplusplus.github.io/LWG/lwg-active.html#3533">3533</a>. Make <tt>base() const &amp;</tt> consistent across iterator wrappers that supports <tt>input_iterator</tt>s</h3>
<p><b>Section:</b> 24.7.5.3 <a href="https://wg21.link/range.filter.iterator">[range.filter.iterator]</a>, 24.7.6.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a>, 24.7.16.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2021-03-14 <b>Last modified:</b> 2021-04-20</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The resolution of LWG issue <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3391">3391</a> changed the <tt>base()</tt> function for the 
<tt>counted_iterator</tt>/<tt>move_iterator</tt> to return <tt>const &amp;</tt>, because the previous 
specification prevented non-mutating uses of the base iterator (comparing against sentinel) and made 
<tt>take_view</tt> unimplementable. However, this change was not applied for all other iterators wrappers, 
that may wrap move-only input iterators. As consequence, we end-up with inconsistency where a user can 
perform the following operations on some adapters, but not on others (e. g. <tt>take_view</tt> uses 
<tt>counted_iterator</tt> so it supports them).
</p>
<ol style="list-style-type:upper-alpha">
<li><p>read the original value of the base iterator, by calling <tt>operator*</tt></p></li>
<li><p>find position of an element in the underlying iterator, when sentinel is sized by calling <tt>operator-</tt> 
(e.g. all input iterators wrapped into <tt>counted_iterator</tt>).</p></li>
</ol>
<p>
To fix above, the proposed wording below proposes to modify the signature of <tt>iterator::base() const &amp;</tt> 
member function for all iterators adapters that support input iterator. These include:
</p>
<ul>
<li><p><tt>filter_view::<i>iterator</i></tt> (uses case B)</p></li>
<li><p><tt>transform_view::<i>iterator</i></tt> (uses case A)</p></li>
<li><p><tt>elements_view::<i>iterator</i></tt> (uses case B)</p></li>
<li><p><tt>lazy_split_view&lt;V, Pattern&gt;::<i>inner-iterator</i></tt> (uses case B) if 
<a href="https://wg21.link/p2210">P2210</a> is accepted</p></li>
</ul>
<p>
Note: <tt>common_iterator</tt> does not expose the <tt>base()</tt> function (because it can either point to 
iterator or sentinel), so changes to above are not proposed. However, both (A) and (B) use cases are supported.
</p>

<p><i>[2021-04-20; Reflector poll]</i></p>

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



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

<blockquote class="note">
<p>
If <a href="https://wg21.link/p2210">P2210</a> would become accepted, the corresponding subclause 
[range.lazy.split.inner] (?) for <tt>lazy_split_view::<i>inner-iterator</i></tt> would require a similar change.
</p>
</blockquote>

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

<blockquote>
<blockquote>
<pre>
[&hellip;]
constexpr <ins>const</ins> iterator_t&lt;V&gt;<ins>&amp;</ins> base() const &amp;
  <del>requires copyable&lt;iterator_t&lt;V&gt;&gt;</del>;
[&hellip;]
</pre>
</blockquote>
</blockquote>
[&hellip;]
<blockquote>
<pre>
constexpr <ins>const</ins> iterator_t&lt;V&gt;<ins>&amp;</ins> base() const &amp;
  <del>requires copyable&lt;iterator_t&lt;V&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Equivalent to: <tt>return <i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<blockquote>
<pre>
[&hellip;]
constexpr <ins>const</ins> iterator_t&lt;<i>Base</i>&gt;<ins>&amp;</ins> base() const &amp;
  <del>requires copyable&lt;iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
[&hellip;]
</pre>
</blockquote>
</blockquote>
[&hellip;]
<blockquote>
<pre>
constexpr <ins>const</ins> iterator_t&lt;<i>Base</i>&gt;<ins>&amp;</ins> base() const &amp;
  <del>requires copyable&lt;iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Equivalent to: <tt>return <i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<blockquote>
<pre>
[&hellip;]
constexpr <ins>const</ins> iterator_t&lt;<i>Base</i>&gt;<ins>&amp;</ins> base() const &amp;
  <del>requires copyable&lt;iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
[&hellip;]
</pre>
</blockquote>
</blockquote>
[&hellip;]
<blockquote>
<pre>
constexpr <ins>const</ins> iterator_t&lt;<i>Base</i>&gt;<ins>&amp;</ins> base() const &amp;
  <del>requires copyable&lt;iterator_t&lt;<i>Base</i>&gt;&gt;</del>;
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Equivalent to: <tt>return <i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="3536" href="https://cplusplus.github.io/LWG/lwg-active.html#3536">3536</a>. Should <tt>chrono::from_stream()</tt> assign zero to <tt>duration</tt> for failure?</h3>
<p><b>Section:</b> 27.5.11 <a href="https://wg21.link/time.duration.io">[time.duration.io]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Matt Stephanson <b>Opened:</b> 2021-03-19 <b>Last modified:</b> 2021-04-20</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#time.duration.io">issues</a> in [time.duration.io].</p>
<p><b>Discussion:</b></p>
<p>
The <tt>duration</tt> specialization of <tt>from_stream</tt> says in <a href="https://wg21.link/n4878">N4878</a> 
27.5.11 <a href="https://wg21.link/time.duration.io">[time.duration.io]</a>/3:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;"><p>
If the parse parses everything specified by the parsing format flags without error, and yet none of the flags impacts a duration, 
<tt>d</tt> will be assigned a zero value.
</p></blockquote>
<p>
This is in contrast to the other specializations that say, for example, 27.8.3.3 <a href="https://wg21.link/time.cal.day.nonmembers">[time.cal.day.nonmembers]</a>/8:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;"><p>
If the parse fails to decode a valid day, <tt>is.setstate(ios_base::failbit)</tt> is called and <tt>d</tt> 
is not modified.
</p></blockquote>
<p>
The wording ("none of the flags impacts a duration" vs. "parse fails to decode a valid [meow]") and semantics 
("assigned a zero value" vs. "not modified") are different, and it's not clear why that should be so. It also 
leaves unspecified what should be done in case of a parse failure, for example parsing <tt>"%j"</tt> from a 
stream containing <tt>"meow"</tt>. 27.13 <a href="https://wg21.link/time.parse">[time.parse]</a>/12 says that <tt>failbit</tt> should be set, 
but neither it nor 27.5.11 <a href="https://wg21.link/time.duration.io">[time.duration.io]</a>/3 mention the <tt>duration</tt> result if parsing fails.
<p/>
This has been discussed at the Microsoft STL project, where Howard Hinnant, coauthor of 
<a href="https://wg21.link/p0355R7">P0355R7</a> that added these functions, 
<a href="https://github.com/microsoft/STL/issues/1740#issuecomment-802414649">commented</a>:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
This looks like a bug in the standard to me, due to two errors on my part.
<p/>
I believe that the standard should clearly say that if <tt>failbit</tt> is set, the parsed variable 
(<tt>duration</tt>, <tt>time_point</tt>, whatever) is not modified. I mistakenly believed that the 
definition of unformatted input function covered this behavior. But after review, I don't believe it 
does. Instead each extraction operator seems to say this separately.
<p/>
I also at first did not have my example implementation coded to leave the duration unchanged. So that's how 
the wording got in in the first place. Here's the commit where I fixed my implementation: 
<a href="https://github.com/HowardHinnant/date/commit/d53db7a1cb61dc2651374e5b9660ed07e6d28358">HowardHinnant/date@d53db7a</a>. 
And I failed to propagate that fix into the proposal/standard.
</p>
</blockquote>
<p>
It would be clearer and simpler for users if the <tt>from_stream</tt> specializations were consistent in wording 
and behavior.
<p/>
Thanks to Stephan T. Lavavej, Miya Natsuhara, and Howard Hinnant for valuable investigation and discussion 
of this issue.
</p>

<p><i>[2021-04-20; Reflector poll]</i></p>

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



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

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

<blockquote>
<pre>
template&lt;class charT, class traits, class Rep, class Period, class Alloc = allocator&lt;charT&gt;&gt;
  basic_istream&lt;charT, traits&gt;&amp;
    from_stream(basic_istream&lt;charT, traits&gt;&amp; is, const charT* fmt,
                duration&lt;Rep, Period&gt;&amp; d,
                basic_string&lt;charT, traits, Alloc&gt;* abbrev = nullptr,
                minutes* offset = nullptr);
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Attempts to parse the input stream <tt>is</tt> into the duration <tt>d</tt> using 
the format flags given in the NTCTS <tt>fmt</tt> as specified in 27.13 <a href="https://wg21.link/time.parse">[time.parse]</a>. <del>If the parse 
parses everything specified by the parsing format flags without error, and yet none of the flags impacts 
a duration, <tt>d</tt> will be assigned a zero value</del><ins>If the parse fails to decode a valid duration, 
<tt>is.setstate(ios_base::failbit)</tt> is called and <tt>d</tt> is not modified</ins>. If <tt>%Z</tt> is 
used and successfully parsed, that value will be assigned to <tt>*abbrev</tt> if <tt>abbrev</tt> is non-null. 
If <tt>%z</tt> (or a modified variant) is used and successfully parsed, that value will be assigned to 
<tt>*offset</tt> if <tt>offset</tt> is non-null.
</p>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="3539" href="https://cplusplus.github.io/LWG/lwg-active.html#3539">3539</a>. <tt>format_to</tt> must not copy models of <tt>output_iterator&lt;const charT&amp;&gt;</tt></h3>
<p><b>Section:</b> 20.20.4 <a href="https://wg21.link/format.functions">[format.functions]</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> 2021-03-31 <b>Last modified:</b> 2021-04-20</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#format.functions">issues</a> in [format.functions].</p>
<p><b>Discussion:</b></p>
<p>
20.20.4 <a href="https://wg21.link/format.functions">[format.functions]</a> specifies the overloads of <tt>format_to</tt> as:
</p>
<blockquote>
<pre>
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p>
-8- <i>Effects:</i> Equivalent to:
</p>
<blockquote>
<pre>
using context = basic_format_context&lt;Out, decltype(fmt)::value_type&gt;;
return vformat_to(out, fmt, make_format_args&lt;context&gt;(args...));
</pre>
</blockquote>
</blockquote>
<pre>
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, const locale&amp; loc, string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, const locale&amp; loc, wstring_view fmt, const Args&amp;... args);
  Out format_to(Out out, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p>
-9- <i>Effects:</i> Equivalent to:
</p>
<blockquote>
<pre>
using context = basic_format_context&lt;Out, decltype(fmt)::value_type&gt;;
return vformat_to(out, loc, fmt, make_format_args&lt;context&gt;(args...));
</pre>
</blockquote>
</blockquote>
</blockquote>
<p>
but the overloads of <tt>vformat_to</tt> take their first argument by value (from the same subclause):
</p>
<blockquote>
<pre>
template&lt;class Out&gt;
  Out vformat_to(Out out, string_view fmt,
                 format_args_t&lt;type_identity_t&lt;Out&gt;, char&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, wstring_view fmt,
                 format_args_t&lt;type_identity_t&lt;Out&gt;, wchar_t&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, string_view fmt,
                 format_args_t&lt;type_identity_t&lt;Out&gt;, char&gt; args);
template&lt;class Out>
  Out vformat_to(Out out, const locale&amp; loc, wstring_view fmt,
                 format_args_t&lt;type_identity_t&lt;Out&gt;, wchar_t&gt; args);
</pre>
<blockquote>
<p>
-10- Let <tt>charT</tt> be <tt>decltype(fmt)::value_type</tt>.
<p/>
-11- <i>Constraints:</i> <tt>Out</tt> satisfies <tt>output_iterator&lt;const charT&amp;&gt;</tt>.
<p/>
-12- <i>Preconditions:</i> <tt>Out</tt> models <tt>output_iterator&lt;const charT&amp;&gt;</tt>.
</p>
</blockquote>
</blockquote>
<p>
and require its type to model <tt>output_iterator&lt;const charT&amp;&gt;</tt>. <tt>output_iterator&lt;T, U&gt;</tt> 
refines <tt>input_or_output_iterator&lt;T&gt;</tt> which refines <tt>movable&lt;T&gt;</tt>, but it notably does not 
refine <tt>copyable&lt;T&gt;</tt>. Consequently, the "Equivalent to" code for the <tt>format_to</tt> overloads is 
copying an iterator that could be move-only. I suspect it is not the intent that calls to <tt>format_to</tt> with 
move-only iterators be ill-formed, but that it was simply an oversight that this wording needs updating to be 
consistent with the change to allow move-only single-pass iterators in C++20.
</p>

<p><i>[2021-04-20; Reflector poll]</i></p>

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



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

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

<blockquote>
<pre>
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p>
-8- <i>Effects:</i> Equivalent to:
</p>
<blockquote>
<pre>
using context = basic_format_context&lt;Out, decltype(fmt)::value_type&gt;;
return vformat_to(<ins>std::move(</ins>out<ins>)</ins>, fmt, make_format_args&lt;context&gt;(args...));
</pre>
</blockquote>
</blockquote>
<pre>
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, const locale&amp; loc, string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, const locale&amp; loc, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p>
-9- <i>Effects:</i> Equivalent to:
</p>
<blockquote>
<pre>
using context = basic_format_context&lt;Out, decltype(fmt)::value_type&gt;;
return vformat_to(<ins>std::move(</ins>out<ins>)</ins>, loc, fmt, make_format_args&lt;context&gt;(args...));
</pre>
</blockquote>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3540" href="https://cplusplus.github.io/LWG/lwg-active.html#3540">3540</a>. &sect;[format.arg] There should be no <tt>const</tt> in <tt>basic_format_arg(const T* p)</tt></h3>
<p><b>Section:</b> 20.20.6.1 <a href="https://wg21.link/format.arg">[format.arg]</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> 2021-04-07 <b>Last modified:</b> 2021-04-20</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#format.arg">active issues</a> in [format.arg].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#format.arg">issues</a> in [format.arg].</p>
<p><b>Discussion:</b></p>
<p>
When <a href="https://wg21.link/p0645r10">P0645R10</a> "Text formatting" was merged into the draft standard, there was 
a typo: an exposition-only constructor of <tt>basic_format_arg</tt> is declared as accepting <tt>const T*</tt> in the 
class synopsis, but is later declared to accept <tt>T*</tt>. This was 
<a href="https://github.com/cplusplus/draft/issues/3461">editorial issue 3461</a> and was resolved by adding 
<tt>const</tt> to the redeclaration.
<p/>
As it is, constructing <tt>basic_format_arg</tt> from <tt>void*</tt> will select 
<tt>template&lt;class T&gt; explicit basic_format_arg(const T&amp; v)</tt> and store a 
<tt>basic_format_arg::handle</tt> instead of select <tt>template&lt;class T&gt; basic_format_arg(const T*)</tt> and 
store a <tt>const void*</tt>, because <tt>void*</tt> &rarr; <tt>void*const&amp;</tt> is identity conversion, while 
<tt>void*</tt> &rarr; <tt>const void*</tt> is qualification conversion.
<p/>
While this technically works, it seems that storing a <tt>const void*</tt> would be more intuitive.
<p/>
Hence, I think <tt>const</tt> should be removed from both declarations of <tt>basic_format_arg(const T*)</tt>, 
so that construction from <tt>void*</tt> will select this constructor, resulting in more intuitive behavior.
</p>

<p><i>[2021-04-20; Reflector poll]</i></p>

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



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

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

<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;class Context&gt;
  class basic_format_arg {
  public:
    class handle;

  private:
    using char_type = typename Context::char_type;                     <i>// exposition only</i>

    variant&lt;monostate, bool, char_type,
      int, unsigned int, long long int, unsigned long long int,
      float, double, long double,
      const char_type*, basic_string_view&lt;char_type&gt;,
      const void*, handle&gt; value;                                      <i>// exposition only</i>

    template&lt;class T&gt; explicit basic_format_arg(const T&amp; v) noexcept;  <i>// exposition only</i>
    explicit basic_format_arg(float n) noexcept;                       <i>// exposition only</i>
    explicit basic_format_arg(double n) noexcept;                      <i>// exposition only</i>
    explicit basic_format_arg(long double n) noexcept;                 <i>// exposition only</i>
    explicit basic_format_arg(const char_type* s);                     <i>// exposition only</i>

    template&lt;class traits&gt;
      explicit basic_format_arg(
        basic_string_view&lt;char_type, traits&gt; s) noexcept;              <i>// exposition only</i>

    template&lt;class traits, class Allocator&gt;
      explicit basic_format_arg(
        const basic_string&lt;char_type, traits, Allocator&gt;&amp; s) noexcept; <i>// exposition only</i>
    
    explicit basic_format_arg(nullptr_t) noexcept;                     <i>// exposition only</i>

    template&lt;class T&gt;
      explicit basic_format_arg(<del>const</del> T* p) noexcept;                  <i>// exposition only</i>
  public:
    basic_format_arg() noexcept;

    explicit operator bool() const noexcept;
  };
}
</pre>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;class T&gt; explicit basic_format_arg(<del>const</del> T* p) noexcept;
</pre>
<blockquote>
<p>
-12- <i>Constraints:</i> <tt>is_void_v&lt;T&gt;</tt> is <tt>true</tt>.
<p/>
-13- <i>Effects:</i> Initializes <tt>value</tt> with <tt>p</tt>.
<p/>
-14- [<i>Note 1</i>: Constructing <tt>basic_format_arg</tt> from a pointer to a member is ill-formed unless the 
user provides an enabled specialization of formatter for that pointer to member type. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3541" href="https://cplusplus.github.io/LWG/lwg-active.html#3541">3541</a>. <tt>indirectly_readable_traits</tt> should be SFINAE-friendly for all types</h3>
<p><b>Section:</b> 23.3.2.2 <a href="https://wg21.link/readable.traits">[readable.traits]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Christopher Di Bella <b>Opened:</b> 2021-04-08 <b>Last modified:</b> 2021-04-20</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#readable.traits">issues</a> in [readable.traits].</p>
<p><b>Discussion:</b></p>
<p>
Following the outcome of LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3446">3446</a>, a strict implementation of <tt>std::indirectly_readable_traits</tt> 
isn't SFINAE-friendly for types that have different <tt>value_type</tt> and <tt>element_type</tt> members due to 
the ambiguity between the <tt><i>has-member-value-type</i></tt> and <tt><i>has-member-element-type</i></tt> 
specialisations. Other traits types are empty when requirements aren't met; we should follow suit here.
</p>

<p><i>[2021-04-20; Reflector poll]</i></p>

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



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

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

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

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

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

[&hellip;]

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

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

<ins>template&lt;<i>has-member-value-type</i> T&gt;
  requires <i>has-member-element-type</i>&lt;T&gt;
struct indirectly_readable_traits&lt;T&gt; { };</ins>
  
template&lt;<i>has-member-value-type</i> T&gt;
  requires <i>has-member-element-type</i>&lt;T&gt; &amp;&amp;
           same_as&lt;remove_cv_t&lt;typename T::element_type&gt;, remove_cv_t&lt;typename T::value_type&gt;&gt;
struct indirectly_readable_traits&lt;T&gt;
  : <i>cond-value-type</i>&lt;typename T::value_type&gt; { };
[&hellip;]
</pre>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3542" href="https://cplusplus.github.io/LWG/lwg-active.html#3542">3542</a>. <tt>basic_format_arg</tt> mis-handles <tt>basic_string_view</tt> with custom traits</h3>
<p><b>Section:</b> 20.20.6.1 <a href="https://wg21.link/format.arg">[format.arg]</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> 2021-04-20 <b>Last modified:</b> 2021-05-10</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#format.arg">active issues</a> in [format.arg].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#format.arg">issues</a> in [format.arg].</p>
<p><b>Discussion:</b></p>
<p>
<tt>basic_format_arg</tt> has a constructor that accepts a <tt>basic_string_view</tt> of an appropriate character type, 
with <em>any</em> <tt>traits</tt> type. The constructor is specified in 20.20.6.1 <a href="https://wg21.link/format.arg">[format.arg]</a> as:
</p>
<blockquote><pre>
template&lt;class traits&gt;
explicit basic_format_arg(basic_string_view&lt;char_type, traits&gt; s) noexcept;
</pre>
<blockquote>
<p>
-9- <i>Effects:</i> Initializes <tt>value</tt> with <tt>s</tt>.
</p>
</blockquote>
</blockquote>
<p>
Recall that <tt>value</tt> is a <tt>variant&lt;monostate, bool, char_type, int, unsigned int, long long int, 
unsigned long long int, float, double, long double, const char_type*, basic_string_view&lt;char_type&gt;, const void*, handle&gt;</tt> 
as specified earlier in the subclause. Since <tt>basic_string_view&lt;<i>meow</i>, <i>woof</i>&gt;</tt> cannot be 
initialized with an lvalue <tt>basic_string_view&lt;<i>meow</i>, <i>quack</i>&gt;</tt> &mdash; and certainly none 
of the other alternative types can be initialized by such an lvalue &mdash; the effects of this constructor are 
ill-formed when <tt>traits</tt> is not <tt>std::char_traits&lt;char_type&gt;</tt>.
<p/>
The <tt>basic_string</tt> constructor deals with this same issue by ignoring the deduced traits type when initializing 
<tt>value</tt>'s <tt>basic_string_view</tt> member:
</p>
<blockquote><pre>
template&lt;class traits, class Allocator&gt;
  explicit basic_format_arg(
    const basic_string&lt;char_type, traits, Allocator&gt;&amp; s) noexcept;
</pre>
<blockquote>
<p>
-10- <i>Effects:</i> Initializes <tt>value</tt> with <tt>basic_string_view&lt;char_type&gt;(s.data(), s.size())</tt>.
</p>
</blockquote>
</blockquote>
<p>
which immediately begs the question of "why doesn't the <tt>basic_string_view</tt> constructor do the same?"
</p>

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

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



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

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

<blockquote>
<pre>
template&lt;class traits&gt;
  explicit basic_format_arg(basic_string_view&lt;char_type, traits&gt; s) noexcept;
</pre>
<blockquote>
<p>
-9- <i>Effects:</i> Initializes <tt>value</tt> with <tt><del>s</del><ins>basic_string_view&lt;char_type&gt;(s.data(), s.size())</ins></tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3543" href="https://cplusplus.github.io/LWG/lwg-active.html#3543">3543</a>. Definition of when <tt>counted_iterators</tt> refer to the same sequence isn't quite right</h3>
<p><b>Section:</b> 23.5.6.1 <a href="https://wg21.link/counted.iterator">[counted.iterator]</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> 2021-04-21 <b>Last modified:</b> 2021-05-10</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#counted.iterator">issues</a> in [counted.iterator].</p>
<p><b>Discussion:</b></p>
<p>
23.5.6.1 <a href="https://wg21.link/counted.iterator">[counted.iterator]</a>/3 says:
</p>
<blockquote><p>
Two values <tt>i1</tt> and <tt>i2</tt> of types <tt>counted_iterator&lt;I1&gt;</tt> and
<tt>counted_iterator&lt;I2&gt;</tt> refer to elements of the same sequence if and
only if <tt>next(i1.base(), i1.count())</tt> and <tt>next(i2.base(), i2.count())</tt>
refer to the same (possibly past-the-end) element.
</p></blockquote>
<p>
However, some users of <tt>counted_iterator</tt> (such as <tt>take_view</tt>) don't guarantee that 
there are <tt>count()</tt> elements past <tt>base()</tt>. It seems that we need to rephrase this 
definition to account for such uses.
</p>

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

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



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

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

<blockquote>
<p>
-3- Two values <tt>i1</tt> and <tt>i2</tt> of types <tt>counted_iterator&lt;I1&gt;</tt> and 
<tt>counted_iterator&lt;I2&gt;</tt> refer to elements of the same sequence if and only if 
<ins>there exists some integer <tt><i>n</i></tt> such that</ins> <tt>next(i1.base(), 
i1.count() <ins>+ <i>n</i></ins>)</tt> and <tt>next(i2.base(), i2.count() <ins>+ <i>n</i></ins>)</tt> 
refer to the same (possibly past-the-end) element.</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3544" href="https://cplusplus.github.io/LWG/lwg-active.html#3544">3544</a>. <tt><i>format-arg-store</i>::args</tt> is unintentionally not exposition-only</h3>
<p><b>Section:</b> 20.20.6.2 <a href="https://wg21.link/format.arg.store">[format.arg.store]</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> 2021-04-22 <b>Last modified:</b> 2021-05-20</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
Despite the statement in 20.20.6.3 <a href="https://wg21.link/format.args">[format.args]</a>/1:
</p>
<blockquote><p>
An instance of <tt>basic_format_args</tt> provides access to formatting arguments. Implementations should
optimize the representation of <tt>basic_format_args</tt> for a small number of formatting arguments.
[<i>Note 1:</i> For example, by storing indices of type alternatives separately from values and packing
the former. &mdash; <i>end note</i>]
</p></blockquote>
<p>
<tt>make_format_args</tt> and <tt>make_wformat_args</tt> are specified to return an object whose type is
a specialization of the exposition-only class template <tt><i>format-arg-store</i></tt> which has a public
non-static data member that is an <tt>array</tt> of <tt>basic_format_arg</tt>. In order to actually
"optimize the representation of <tt>basic_format_args</tt>" an implementation must internally avoid using
<tt>make_format_args</tt> (and <tt>make_wformat_args</tt>) and instead use a different mechanism to type-erase
arguments. <tt>basic_format_args</tt> must still be convertible from <tt><i>format-arg-store</i></tt> as
specified, however, so internally <tt>basic_format_args</tt> must support both the bad/slow standard mechanism
and a good/fast internal-only mechanism for argument storage.
<p/>
While this complicated state of affairs is technically implementable, it greatly complicates the implementation
of <tt>&lt;format&gt;</tt> with no commensurate benefit. Indeed, naive users may make the mistake of thinking
that e.g. <tt>vformat(fmt, make_format_args(args...))</tt> is as efficient as <tt>format(fmt, args...)</tt> &mdash;
that's what the "<i>Effects:</i> Equivalent to" in 20.20.4 <a href="https://wg21.link/format.functions">[format.functions]</a>/2 implies &mdash; and
inadvertently introduce performance regressions. It would be better for both implementers and users if
<tt><i>format-arg-store</i></tt> had no public data members and its member <tt>args</tt> were made exposition-only.
</p>

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

<p>
Priority set to 3.
Tim: "The current specification of <code>make_format_args</code> depends on
<code><i>format-arg-store</i></code> being an aggregate,
which is no longer true with this PR."
</p>

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

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

<blockquote>
<pre>
[&hellip;]
<i>// 20.20.6.2 <a href="https://wg21.link/format.arg.store">[format.arg.store]</a>, class template format-arg-store</i>
template&lt;class Context, class... Args&gt; <del>struct</del><ins>class</ins> <i>format-arg-store</i>; <i>// exposition only</i>
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
namespace std {
  template&lt;class Context, class... Args&gt;
  <del>struct</del><ins>class</ins> <i>format-arg-store</i> { <i>// exposition only</i>
    array&lt;basic_format_arg&lt;Context&gt;, sizeof...(Args)&gt; args; <ins><i>// exposition only</i></ins>
  };
}
</pre>
</blockquote>
</li>
</ol>
</blockquote>
<p><i>[2021-05-18; Tim updates wording.]</i></p>


<p><i>[2021-05-20; Reflector poll]</i></p>

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



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

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

<blockquote>
<pre>
[&hellip;]
<i>// 20.20.6.2 <a href="https://wg21.link/format.arg.store">[format.arg.store]</a>, class template format-arg-store</i>
template&lt;class Context, class... Args&gt; <del>struct</del><ins>class</ins> <i>format-arg-store</i>; <i>// exposition only</i>

template&lt;class Context = format_context, class... Args&gt;
  <i>format-arg-store</i>&lt;Context, Args...&gt;
    make_format_args(const Args&amp;... <ins>fmt_</ins>args);
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
namespace std {
  template&lt;class Context, class... Args&gt;
  <del>struct</del><ins>class</ins> <i>format-arg-store</i> { <i>// exposition only</i>
    array&lt;basic_format_arg&lt;Context&gt;, sizeof...(Args)&gt; args; <ins><i>// exposition only</i></ins>
  };
}
</pre>
<p>-1- An instance of <tt><i>format-arg-store</i></tt> stores formatting arguments.</p>
<pre>
template&lt;class Context = format_context, class... Args&gt;
  <i>format-arg-store</i>&lt;Context, Args...&gt; make_format_args(const Args&amp;... <ins>fmt_</ins>args);
</pre>
<blockquote>
<p>
-2- <i>Preconditions</i>: The type <tt>typename Context::template formatter_type&lt;T<sub>i</sub>&gt;</tt>
meets the <i>Formatter</i> requirements (20.20.5.1 <a href="https://wg21.link/formatter.requirements">[formatter.requirements]</a>)
for each <tt>T<sub>i</sub></tt> in <tt>Args</tt>.
<p/>
-3- <i>Returns</i>: <del></del>
<ins>An object of type <tt><i>format-arg-store</i>&lt;Context, Args...&gt;</tt>
whose <tt>args</tt> data member is initialized with</ins>
<tt>{basic_format_arg&lt;Context&gt;(<ins>fmt_</ins>args)...}</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3546" href="https://cplusplus.github.io/LWG/lwg-active.html#3546">3546</a>. <tt>common_iterator</tt>'s <tt><i>postfix-proxy</i></tt> is not quite right</h3>
<p><b>Section:</b> 23.5.4.5 <a href="https://wg21.link/common.iter.nav">[common.iter.nav]</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> 2021-04-23 <b>Last modified:</b> 2021-05-17</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/p2259r1">P2259R1</a> modeled <tt>common_iterator::operator++(int)</tt>'s 
<tt><i>postfix-proxy</i></tt> class on the existing proxy class used by <tt>common_iterator::operator-&gt;</tt>, 
but in doing so it overlooked two differences:
</p>
<ul>
<li><p><tt>operator-&gt;</tt>'s proxy is only used when <tt>iter_reference_t&lt;I&gt;</tt> is not a
reference type; this is not the case for <tt><i>postfix-proxy</i></tt>;</p></li>
<li><p><tt>operator-&gt;</tt> returns a prvalue proxy, while <tt>operator++</tt>'s <tt><i>postfix-proxy</i></tt>
is returned by (elidable) move, so the latter needs to require <tt>iter_value_t&lt;I&gt;</tt> to be 
<tt>move_constructible</tt>.</p></li>
</ul>
<p>
The proposed wording has been implemented and tested.
</p>

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

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


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

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



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

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

<blockquote>
<pre>
decltype(auto) operator++(int);
</pre>
<blockquote>
<p>
-4- <i>Preconditions:</i> <tt>holds_alternative&lt;I&gt;(v_)</tt> is <tt>true</tt>.
<p/>
-5- <i>Effects:</i> If <tt>I</tt> models <tt>forward_iterator</tt>, equivalent to:
</p>
<blockquote><pre>
common_iterator tmp = *this;
++*this;
return tmp;
</pre></blockquote>
<p>
Otherwise, if <tt>requires (I&amp; i) { { *i++ } -&gt; <i>can-reference</i>; }</tt> is <tt>true</tt> 
or <tt>constructible_from&lt;iter_value_t&lt;I&gt;, iter_reference_t&lt;I&gt;&gt; <ins>&amp;&amp;
move_constructible&lt;iter_value_t&lt;I&gt;&gt;</ins></tt> is <tt>false</tt>, equivalent to:
</p>
<blockquote><pre>
return get&lt;I&gt;(v_)++;
</pre></blockquote>
<p>
Otherwise, equivalent to:
</p>
<blockquote><pre>
<i>postfix-proxy</i> p(**this);
++*this;
return p;
</pre></blockquote>
<p>
where <tt><i>postfix-proxy</i></tt> is the exposition-only class:
</p>
<blockquote><pre>
class <i>postfix-proxy</i> {
  iter_value_t&lt;I&gt; keep_;
  <i>postfix-proxy</i>(iter_reference_t&lt;I&gt;&amp;&amp; x)
    : keep_(std::<del>move</del><ins>forward&lt;iter_reference_t&lt;I&gt;&gt;</ins>(x)) {}
public:
  const iter_value_t&lt;I&gt;&amp; operator*() const {
    return keep_;
  }
};
</pre></blockquote>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3548" href="https://cplusplus.github.io/LWG/lwg-active.html#3548">3548</a>. <tt>shared_ptr</tt> construction from <tt>unique_ptr</tt> should move (not copy) the deleter</h3>
<p><b>Section:</b> 20.11.3.2 <a href="https://wg21.link/util.smartptr.shared.const">[util.smartptr.shared.const]</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> 2021-05-04 <b>Last modified:</b> 2021-05-17</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>Discussion:</b></p>
<p>
The construction of a <tt>shared_ptr</tt> from a suitable <tt>unique_ptr</tt> rvalue <tt>r</tt> 
(which was last modified by LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2415">2415</a>, but not in ways relevant to this issue) calls 
for <tt>shared_ptr(r.release(), r.get_deleter())</tt> in the case where the deleter is not a reference.
<p/>
This specification requires the deleter to be copyable, which seems like an unnecessary restriction. 
Note that the constructor <tt>unique_ptr(unique_ptr&amp;&amp; u)</tt> only requires <tt>u</tt>'s deleter 
to be <i>Cpp17MoveConstructible</i>. By analogy, the constructor <tt>shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp;)</tt> 
should also require <tt>D</tt> to be only move-, not copy-constructible.
</p>

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

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



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

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

<blockquote>
<pre>
template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);
</pre>
<blockquote>
<p>
-28- <i>Constraints:</i> <tt>Y*</tt> is compatible with <tt>T*</tt> and <tt>unique_ptr&lt;Y, D&gt;::pointer</tt> 
is convertible to <tt>element_type*</tt>.
<p/>
-29- <i>Effects:</i> If <tt>r.get() == nullptr</tt>, equivalent to <tt>shared_ptr()</tt>. Otherwise, if <tt>D</tt> 
is not a reference type, equivalent to <tt>shared_ptr(r.release(), <ins>std::move(</ins>r.get_deleter()<ins>)</ins>)</tt>. 
Otherwise, equivalent to <tt>shared_ptr(r.release(), ref(r.get_deleter()))</tt>. If an exception is thrown, 
the constructor has no effect.
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3549" href="https://cplusplus.github.io/LWG/lwg-active.html#3549">3549</a>. <tt>view_interface</tt> is overspecified to derive from <tt>view_base</tt></h3>
<p><b>Section:</b> 24.5.3 <a href="https://wg21.link/view.interface">[view.interface]</a>, 24.4.4 <a href="https://wg21.link/range.view">[range.view]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2021-05-09 <b>Last modified:</b> 2021-05-26</p>
<p><b>Priority: </b>2
</p>
<p><b>Discussion:</b></p>
<p>
<tt>view_interface&lt;D&gt;</tt> is currently specified to publicly derive from
<tt>view_base</tt>. This derivation requires unnecessary padding in range adaptors
like <tt>reverse_view&lt;V&gt;</tt>: the <tt>view_base</tt> subobject of the
<tt>reverse_view</tt> is required to reside at a different address than the
<tt>view_base</tt> subobject of <tt>V</tt> (assuming that <tt>V</tt> similarly
opted into being a view through derivation from <tt>view_interface</tt> or
<tt>view_base</tt>).
<p/>
This appears to be a case of overspecification: we want public and unambiguous
derivation from <tt>view_interface</tt> to make the class a <tt>view</tt>; the exact
mechanism of how that opt-in is accomplished should have been left as an
implementation detail.
<p/>
The proposed resolution below has been implemented on top of libstdc++ master
and passes its ranges testsuite, with the exception of a test that checks for the size of
various range adaptors (and therefore asserts the existence of
<tt>view_base</tt>-induced padding).
</p>

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

<p>
Priority set to 2.
</p>


<p><i>[2021-05-26; Reflector poll]</i></p>

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



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

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

<blockquote>
<pre>
<ins>template&lt;class T&gt;
  inline constexpr bool <i>is-derived-from-view-interface</i> = <i>see below</i>;   // exposition only</ins>
template&lt;class T&gt;
  inline constexpr bool enable_view = derived_from&lt;T, view_base&gt; <ins>|| <i>is-derived-from-view-interface</i>&lt;T&gt;</ins>;
</pre>
<blockquote>
<p>
<ins>-?- For a type <tt>T</tt>, <tt><i>is-derived-from-view-interface</i>&lt;T&gt;</tt>
is <tt>true</tt> if and only if <tt>T</tt> has exactly one public base class
<tt>view_interface&lt;U&gt;</tt> for some type <tt>U</tt> and
<tt>T</tt> has no base classes of type <tt>view_interface&lt;V&gt;</tt> for any
other type <tt>V</tt>.</ins>
<p/>
-5- Remarks: Pursuant to 16.4.5.2.1 <a href="https://wg21.link/namespace.std">[namespace.std]</a>, users may specialize
<tt>enable_view</tt> to <tt>true</tt> for cv-unqualified program-defined types which
model <tt>view</tt>, and <tt>false</tt> for types which do not. Such specializations
shall be usable in constant expressions (7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>) and have
type <tt>const bool</tt>.
</p>
</blockquote>
</blockquote>

</li>
<li>
<p>Modify 24.5.3.1 <a href="https://wg21.link/view.interface.general">[view.interface.general]</a> as indicated: </p>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;class D&gt;
    requires is_class_v&lt;D&gt; &amp;&amp; same_as&lt;D, remove_cv_t&lt;D&gt;&gt;
  class view_interface <del>: public view_base</del> {

  [&hellip;]

  };
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3551" href="https://cplusplus.github.io/LWG/lwg-active.html#3551">3551</a>. <tt>borrowed_{iterator,subrange}_t</tt> are overspecified</h3>
<p><b>Section:</b> 24.5.5 <a href="https://wg21.link/range.dangling">[range.dangling]</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> 2021-05-12 <b>Last modified:</b> 2021-05-20</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
As discussed in <a href="https://wg21.link/p1715r0">P1715R0</a>, 
there are ways to implement something equivalent to <tt>std::conditional_t</tt> 
that are better for compile times. However, <tt>borrowed_{iterator,subrange}_t</tt> 
are currently specified to use <tt>conditional_t</tt>, and this appears to be 
user-observable due to the transparency of alias templates. We should simply 
specify the desired result and leave the actual definition to the implementation.
</p>

<p><i>[2021-05-20; Reflector poll]</i></p>

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



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

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

<blockquote>
<pre>
  [&hellip;]
namespace std::ranges {
  [&hellip;]
  <i>// 24.5.5 <a href="https://wg21.link/range.dangling">[range.dangling]</a>, dangling iterator handling</i>
  struct dangling;
  
  template&lt;range R&gt;
    using borrowed_iterator_t = <ins><i>see below</i></ins><del>conditional_t&lt;borrowed_range&lt;R&gt;, iterator_t&lt;R&gt;, dangling&gt;</del>;

  template&lt;range R&gt;
    using borrowed_subrange_t = <ins><i>see below</i></ins>
      <del>conditional_t&lt;borrowed_range&lt;R&gt;, subrange&lt;iterator_t&lt;R&gt;&gt;, dangling&gt;</del>;

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

</li>
<li>
<p>Modify 24.5.5 <a href="https://wg21.link/range.dangling">[range.dangling]</a> as indicated: </p>
<blockquote>
<p>
-1- The tag type <tt>dangling</tt> is used together with the template aliases <tt>borrowed_iterator_t</tt> and 
<tt>borrowed_subrange_t</tt>. When an algorithm that typically returns an iterator into, or a subrange of, a 
range argument is called with an rvalue range argument that does not model <tt>borrowed_range</tt> 
(24.4.2 <a href="https://wg21.link/range.range">[range.range]</a>), the return value possibly refers to a range whose lifetime has ended. In such 
cases, the tag type <tt>dangling</tt> is returned instead of an iterator or subrange.
</p>
<blockquote><pre>
namespace std::ranges {
  struct dangling {
    [&hellip;]
  };
}
</pre></blockquote>
<p>
-2- [<i>Example 1:</i> [&hellip;] &mdash; <i>end example</i>]
<p/>
<ins>-?- For a type <tt>R</tt> that models <tt>range</tt>:</ins>
<ol style="list-style-type: none">
<li><p><ins>(?.1) &mdash; if <tt>R</tt> models <tt>borrowed_range</tt>, then <tt>borrowed_iterator_t&lt;R&gt;</tt>
denotes <tt>iterator_t&lt;R&gt;</tt>, and <tt>borrowed_subrange_t&lt;R&gt;</tt> denotes 
<tt>subrange&lt;iterator_t&lt;R&gt;&gt;</tt>;</ins></p></li>
<li><p><ins>(?.2) &mdash; otherwise, both <tt>borrowed_iterator_t&lt;R&gt;</tt> and <tt>borrowed_subrange_t&lt;R&gt;</tt> 
denote <tt>dangling</tt>.</ins></p></li>
</ol>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3552" href="https://cplusplus.github.io/LWG/lwg-active.html#3552">3552</a>. Parallel specialized memory algorithms should require forward iterators</h3>
<p><b>Section:</b> 20.10.2 <a href="https://wg21.link/memory.syn">[memory.syn]</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> 2021-05-16 <b>Last modified:</b> 2021-05-20</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#memory.syn">issues</a> in [memory.syn].</p>
<p><b>Discussion:</b></p>
<p>
The parallel versions of <tt>uninitialized_{copy,move}{,_n}</tt> are currently
depicted as accepting input iterators for their source range. Similar to the 
non-uninitialized versions, they should require the source range to be at least forward.
</p>

<p><i>[2021-05-20; Reflector poll]</i></p>

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



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

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

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

  template&lt;class InputIterator, class NoThrowForwardIterator&gt;
    NoThrowForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
                                              NoThrowForwardIterator result);
  template&lt;class ExecutionPolicy, class <del>Input</del><ins>Forward</ins>Iterator, class NoThrowForwardIterator&gt;
    NoThrowForwardIterator uninitialized_copy(ExecutionPolicy&amp;&amp; exec, <i>// see 25.3.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a></i>
                                              <del>Input</del><ins>Forward</ins>Iterator first, <del>Input</del><ins>Forward</ins>Iterator last,
                                              NoThrowForwardIterator result);
  template&lt;class InputIterator, class Size, class NoThrowForwardIterator&gt;
    NoThrowForwardIterator uninitialized_copy_n(InputIterator first, Size n,
                                                NoThrowForwardIterator result);
  template&lt;class ExecutionPolicy, class <del>Input</del><ins>Forward</ins>Iterator, class Size, class NoThrowForwardIterator&gt;
    NoThrowForwardIterator uninitialized_copy_n(ExecutionPolicy&amp;&amp; exec, <i>// see 25.3.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a></i>
                                                <del>Input</del><ins>Forward</ins>Iterator first, Size n,
                                                NoThrowForwardIterator result);  
  [&hellip;]

  template&lt;class InputIterator, class NoThrowForwardIterator&gt;
    NoThrowForwardIterator uninitialized_move(InputIterator first, InputIterator last,
                                              NoThrowForwardIterator result);
  template&lt;class ExecutionPolicy, class <del>Input</del><ins>Forward</ins>Iterator, class NoThrowForwardIterator&gt;
    NoThrowForwardIterator uninitialized_move(ExecutionPolicy&amp;&amp; exec, <i>// see 25.3.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a></i>
                                              <del>Input</del><ins>Forward</ins>Iterator first, <del>Input</del><ins>Forward</ins>Iterator last,
                                              NoThrowForwardIterator result);
  template&lt;class InputIterator, class Size, class NoThrowForwardIterator&gt;
    pair&lt;InputIterator, NoThrowForwardIterator&gt;
      uninitialized_move_n(InputIterator first, Size n, NoThrowForwardIterator result);
  template&lt;class ExecutionPolicy, class <del>Input</del><ins>Forward</ins>Iterator, class Size, class NoThrowForwardIterator&gt;
    pair&lt;<del>Input</del><ins>Forward</ins>Iterator, NoThrowForwardIterator&gt;
      uninitialized_move_n(ExecutionPolicy&amp;&amp; exec, <i>// see 25.3.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a></i>
                           <del>Input</del><ins>Forward</ins>Iterator first, Size n, NoThrowForwardIterator result);

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

</li>
</ol>





<hr>
<h3><a name="3553" href="https://cplusplus.github.io/LWG/lwg-active.html#3553">3553</a>. Useless constraint in <tt>split_view::<i>outer-iterator</i>::value_type::begin()</tt></h3>
<p><b>Section:</b> 24.7.12.4 <a href="https://wg21.link/range.split.outer.value">[range.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> 2021-05-18 <b>Last modified:</b> 2021-05-26</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.split.outer.value">issues</a> in [range.split.outer.value].</p>
<p><b>Discussion:</b></p>
<p>
The <tt>copyable</tt> constraint in <tt>split_view::<i>outer-iterator</i>::value_type::begin()</tt> 
is useless because <tt><i>outer-iterator</i></tt> always satisfies <tt>copyable</tt>.
<p/>
When <tt>V</tt> does not model <tt>forward_range</tt>, the <tt><i>outer-iterator</i></tt> only contains a pointer, so it 
is obviously copyable; When <tt>V</tt> is a <tt>forward_range</tt>, the <tt>iterator_t&lt;Base&gt;</tt> is a 
<tt>forward_iterator</tt>, so it is copyable, which makes <tt><i>outer-iterator</i></tt> also copyable.
<p/>
Suggested resolution: Remove the no-<tt>const begin()</tt> and useless <tt>copyable</tt> constraint in
24.7.12.4 <a href="https://wg21.link/range.split.outer.value">[range.split.outer.value]</a>.
</p>

<p><i>[2021-05-26; Reflector poll]</i></p>

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



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

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

<blockquote>
<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 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>
  public:
    value_type() = default;
    constexpr explicit value_type(<i>outer-iterator</i> i);
    constexpr <i>inner-iterator</i>&lt;Const&gt; begin() const <del>requires copyable&lt;<i>outer-iterator</i>&gt;</del>;
    <del>constexpr <i>inner-iterator</i>&lt;Const&gt; begin() requires (!copyable&lt;<i>outer-iterator</i>&gt;);</del>
    constexpr default_sentinel_t end() const;
  };
}
</pre>
</blockquote>
[&hellip;]
<pre>
constexpr <i>inner-iterator</i>&lt;Const&gt; begin() const <del>requires copyable&lt;<i>outer-iterator</i>&gt;</del>;
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> Equivalent to: <tt>return <i>inner-iterator</i>&lt;Const&gt;{<i>i_</i>};</tt>
</p>
</blockquote>
<pre>
<del>constexpr <i>inner-iterator</i>&lt;Const&gt; begin() requires (!copyable&lt;<i>outer-iterator</i>&gt;)</del>;
</pre>
<blockquote>
<p>
<del>-3- <i>Effects:</i> Equivalent to: <tt>return <i>inner-iterator</i>&lt;Const&gt;{std::move(<i>i_</i>)};</tt></del>
</p>
</blockquote>
[&hellip;]
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3555" href="https://cplusplus.github.io/LWG/lwg-active.html#3555">3555</a>. <tt>{transform,elements}_view::<i>iterator</i>::iterator_concept</tt>
should consider const-qualification of the underlying range</h3>
<p><b>Section:</b> 24.7.6.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a>, 24.7.16.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2021-05-23 <b>Last modified:</b> 2021-05-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#range.transform.iterator">active issues</a> in [range.transform.iterator].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.transform.iterator">issues</a> in [range.transform.iterator].</p>
<p><b>Discussion:</b></p>
<p>
<tt>transform_view::<i>iterator&lt;true&gt;</i>::iterator_concept</tt> and
<tt>elements_view::<i>iterator&lt;true&gt;</i>::iterator_concept</tt> (i.e.,
the const versions) are currently specified as looking at the properties of <tt>V</tt>
(i.e., the underlying view without const), while the actual iterator operations
are all correctly specified as using <tt><i>Base</i></tt> (which includes
the const). <tt>iterator_concept</tt> should do so too.
<p/>
The proposed resolution has been implemented and tested on top of libstdc++.
</p>

<p><i>[2021-05-26; Reflector poll]</i></p>

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



<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4885">N4885</a>.
</p>
<ol>
<li>
<p>Modify 24.7.6.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a> as indicated:</p>
<blockquote>
<p>-1- <tt>iterator::iterator_concept</tt> is defined as follows: </p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; If <tt><del>V</del><ins><i>Base</i></ins></tt> models <tt>random_access_range</tt>, then
<tt>iterator_concept</tt> denotes <tt>random_access_iterator_tag</tt>.</p></li>
<li><p>(1.2) &mdash; Otherwise, if <tt><del>V</del><ins><i>Base</i></ins></tt> models <tt>bidirectional_range</tt>,
then <tt>iterator_concept</tt> denotes <tt>bidirectional_iterator_tag</tt>.</p></li>
<li><p>(1.3) &mdash; Otherwise, if <tt><del>V</del><ins><i>Base</i></ins></tt> models <tt>forward_range</tt>,
then <tt>iterator_concept</tt> denotes <tt>forward_iterator_tag</tt>.</p></li>
<li><p>(1.4) &mdash; Otherwise, <tt>iterator_concept</tt> denotes <tt>input_iterator_tag</tt>.</p></li>
</ol>
</blockquote>
</li>
<li>
<p>Modify 24.7.16.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> as indicated:</p>
<blockquote>
<p>-1- The member <i>typedef-name</i> <tt>iterator_concept</tt> is defined as follows: </p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; If <tt><del>V</del><ins><i>Base</i></ins></tt> models <tt>random_access_range</tt>, then
<tt>iterator_concept</tt> denotes <tt>random_access_iterator_tag</tt>.</p></li>
<li><p>(1.2) &mdash; Otherwise, if <tt><del>V</del><ins><i>Base</i></ins></tt> models <tt>bidirectional_range</tt>,
then <tt>iterator_concept</tt> denotes <tt>bidirectional_iterator_tag</tt>.</p></li>
<li><p>(1.3) &mdash; Otherwise, if <tt><del>V</del><ins><i>Base</i></ins></tt> models <tt>forward_range</tt>,
then <tt>iterator_concept</tt> denotes <tt>forward_iterator_tag</tt>.</p></li>
<li><p>(1.4) &mdash; Otherwise, <tt>iterator_concept</tt> denotes <tt>input_iterator_tag</tt>.</p></li>
</ol>
</blockquote>
</li>
</ol>




</body>
</html>
