<!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, Feb. 2022</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table {border-collapse: collapse;}
</style>
</head>
<body>
<h1>C++ Standard Library Issues to be moved in Virtual Plenary, Feb. 2022</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P2531R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>2022-01-31</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>
<hr>
<h3><a name="3088" href="https://cplusplus.github.io/LWG/lwg-active.html#3088">3088</a>. <tt>forward_list::merge</tt> behavior unclear when passed <tt>*this</tt></h3>
<p><b>Section:</b> 22.3.9.6 <a href="https://wg21.link/forward.list.ops">[forward.list.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> 2018-03-19 <b>Last modified:</b> 2022-01-31</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#300">300</a> changed <tt>list::merge</tt> to be a no-op when passed <tt>*this</tt>, but there's
no equivalent rule for <tt>forward_list::merge</tt>.
Presumably the <tt>forward_list</tt> proposal predated the adoption of LWG 300's PR and was never updated
for the change. Everything in the discussion of that issue applies mutatis mutandis to the current
specification of <tt>forward_list::merge</tt>.
</p>

<p><i>[2018-06-18 after reflector discussion]</i></p>

<p>Priority set to 3</p>

<p><i>[2019-07-30 Tim provides updated PR]</i></p>

<p>Per the comments during issue prioritization, the new PR tries to synchronize the wording
between <tt>list::merge</tt> and <tt>forward_list::merge</tt>.</p>
<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to <a href="https://wg21.link/n4727">N4727</a>.</p>

<ol>
<li><p>Edit 99 [forwardlist.ops] as indicated:</p>
<blockquote>
<pre>
void merge(forward_list&amp; x);
void merge(forward_list&amp;&amp; x);
template&lt;class Compare&gt; void merge(forward_list&amp; x, Compare comp);
template&lt;class Compare&gt; void merge(forward_list&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>
-20- <i>Requires:</i> <tt>*this</tt> and <tt>x</tt> are both sorted with respect to the comparator
<tt>operator&lt;</tt> (for the first two overloads) or <tt>comp</tt> (for the last two overloads),
and <tt>get_allocator() == x.get_allocator()</tt> is <tt>true</tt>.
<p/>
-21- <i>Effects:</i> <ins>If <tt>addressof(x) == this</tt>, does nothing. Otherwise,
m</ins><del>M</del>erges the two sorted ranges <tt>[begin(), end())</tt> and <tt>[x.begin(), x.end())</tt>.
<ins>The result is a range that is sorted with respect to the comparator <tt>operator&lt;</tt>
(for the first two overloads) or <tt>comp</tt> (for the last two overloads).</ins> <tt>x</tt> is
empty after the merge. If an exception is thrown other than by a comparison there are no effects.
Pointers and references to the moved elements of <tt>x</tt> now refer to those same elements but
as members of <tt>*this</tt>. Iterators referring to the moved elements will continue to refer to
their elements, but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>.
<p/>
-22- <i>Remarks:</i> Stable (16.4.6.8 <a href="https://wg21.link/algorithm.stable">[algorithm.stable]</a>). The behavior is undefined if
<tt>get_allocator() != x.get_allocator()</tt>.
<p/>
-23- <i>Complexity:</i> At most <tt>distance(begin(), end()) + distance(x.begin(), x.end()) - 1</tt>
comparisons <ins>if <tt>addressof(x) != this</tt>; otherwise, no comparisons are performed</ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>
<p><i>[2021-05-22 Tim syncs wording to the current working draft]</i></p>


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

<ol>
<li><p>Edit 22.3.9.6 <a href="https://wg21.link/forward.list.ops">[forward.list.ops]</a> as indicated:</p>
<blockquote>
<pre>
void merge(forward_list&amp; x);
void merge(forward_list&amp;&amp; x);
template&lt;class Compare&gt; void merge(forward_list&amp; x, Compare comp);
template&lt;class Compare&gt; void merge(forward_list&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>comp</tt> be <tt>less&lt;&gt;{}</tt> for the first two overloads.</ins>
<p/>
-24- <i>Preconditions:</i> <tt>*this</tt> and <tt>x</tt> are both sorted with respect to the comparator
<del><tt>operator&lt;</tt> (for the first two overloads) or</del> <tt>comp</tt>
<del> (for the last two overloads)</del>,
and <tt>get_allocator() == x.get_allocator()</tt> is <tt>true</tt>.
<p/>
-25- <i>Effects:</i> <ins>If <tt>addressof(x) == this</tt>, there are no effects. Otherwise,
m</ins><del>M</del>erges the two sorted ranges <tt>[begin(), end())</tt> and <tt>[x.begin(), x.end())</tt>.
<ins>The result is a range that is sorted with respect to the comparator <tt>comp</tt>.</ins> <del><tt>x</tt> is
empty after the merge. If an exception is thrown other than by a comparison there are no effects.</del>
Pointers and references to the moved elements of <tt>x</tt> now refer to those same elements but
as members of <tt>*this</tt>. Iterators referring to the moved elements will continue to refer to
their elements, but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>.
<p/>
-26- <i>Complexity:</i> At most <tt>distance(begin(), end()) + distance(x.begin(), x.end()) - 1</tt>
comparisons <ins>if <tt>addressof(x) != this</tt>; otherwise, no comparisons are performed</ins>.
<p/>
-27- <i>Remarks:</i> Stable (16.4.6.8 <a href="https://wg21.link/algorithm.stable">[algorithm.stable]</a>). <ins>If <tt>addressof(x) != this</tt>,
<tt>x</tt> is empty after the merge. No elements are copied by this operation.
If an exception is thrown other than by a comparison there are no effects.</ins>
</p>
</blockquote>
</blockquote>
</li>
<li><p>Edit 22.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> as indicated:</p>
<blockquote>
<pre>
void merge(list&amp; x);
void merge(list&amp;&amp; x);
template&lt;class Compare&gt; void merge(list&amp; x, Compare comp);
template&lt;class Compare&gt; void merge(list&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>comp</tt> be <tt>less&lt;&gt;{}</tt> for the first two overloads.</ins>
<p/>
-26- <i>Preconditions:</i> <del>Both the list and the argument list shall be</del><ins><tt>*this</tt> and <tt>x</tt> are both</ins>
sorted with respect to the comparator <del><tt>operator&lt;</tt>
(for the first two overloads) or </del><tt>comp</tt><del> (for the last two overloads)</del>, and
<tt>get_allocator() == x.get_allocator()</tt> is <tt>true</tt>.
<p/>
-27- <i>Effects:</i> If <tt>addressof(x) == this</tt>, <del>does nothing; o</del><ins>there are no effects. O</ins>therwise,
merges the two sorted ranges <tt>[begin(), end())</tt> and <tt>[x.begin(), x.end())</tt>.
The result is a range <del>in which the elements will be sorted in non-decreasing order according to the ordering
defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt>, in the range other than the first, the condition
<tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt></del><ins>that is sorted with respect to the comparator
<tt>comp</tt></ins>. Pointers and references to the moved elements of <tt>x</tt> now refer to those same elements
but as members of <tt>*this</tt>. Iterators referring to the moved elements will continue to refer to their elements,
but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>.
<p/>
-28- <i>Complexity:</i> At most <tt>size() + x.size() - 1</tt> <del>applications of <tt>comp</tt></del><ins>comparisons</ins>
if <tt>addressof(x) != this</tt>; otherwise, no <del>applications of <tt>comp</tt></del><ins>comparisons</ins> are performed.
<del>If an exception is thrown other than by a comparison there are no effects.</del><p/>
-29- <i>Remarks:</i> Stable (16.4.6.8 <a href="https://wg21.link/algorithm.stable">[algorithm.stable]</a>). If <tt>addressof(x) != this</tt>, <del>the range
<tt>[x.begin(), x.end())</tt></del><ins><tt>x</tt></ins> is empty after the merge. No elements are copied by this operation.
<ins>If an exception is thrown other than by a comparison there are no effects.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3471" href="https://cplusplus.github.io/LWG/lwg-active.html#3471">3471</a>. <tt>polymorphic_allocator::allocate</tt> does not satisfy <i>Cpp17Allocator</i> requirements</h3>
<p><b>Section:</b> 20.12 <a href="https://wg21.link/mem.res">[mem.res]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2020-07-27 <b>Last modified:</b> 2022-01-31</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#mem.res">issues</a> in [mem.res].</p>
<p><b>Discussion:</b></p>
<p>
With the adoption of <a href="https://wg21.link/p0593r6">P0593R6</a> in Prague,
<tt>std::ptr::polymorphic_allocator</tt> no longer satisfies the of <i>Cpp17Allocator</i>
requirements. Specifically, all calls to <tt>allocate(n)</tt> need to create an object
for an array of <tt>n T</tt>s (but not initialize any of those elements).
<tt>std::pmr::polymorphic_allocator</tt> calls its underlying memory resource to allocate
sufficient bytes of storage, but it does not create (and start the lifetime of) the array
object within that storage.
</p>

<p><i>[2020-08-03; Billy comments]</i></p>

<p>
It's worth noting that the resolution of <a href="https://wg21.link/cwg2382">CWG 2382</a>
has impact on implementors for this issue.
</p>

<p><i>[2020-08-21; 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>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The proposed wording is inspired by the example given in the "Assertion/note" column of the expression
<tt>a.allocate(n)</tt> in table [tab:cpp17.allocator].]
</p>
</blockquote>

<ol>
<li><p>Modify 20.12.2.2 <a href="https://wg21.link/mem.res.public">[mem.res.public]</a> as indicated:</p>

<blockquote>
<pre>
[[nodiscard]] void* allocate(size_t bytes, size_t alignment = max_align);
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> Equivalent to: <del><tt>return do_allocate(bytes, alignment);</tt></del>
</p>
<blockquote><pre>
<ins>void* p = do_allocate(bytes, alignment);
return launder(new (p) byte[bytes]);</ins>
</pre></blockquote>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

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

<p>
<tt>memory_resource::allocate</tt> is the PMR equivalent of <tt>malloc</tt>
and <tt>operator new</tt>. It therefore needs the "suitable created object"
wording (see 6.7.2 <a href="https://wg21.link/intro.object">[intro.object]</a>, 20.10.11 <a href="https://wg21.link/c.malloc">[c.malloc]</a>).
This ensures that it creates the requisite array object automatically for all
the allocation functions of <tt>polymorphic_allocator</tt>,
and returns the correct pointer value in all cases.
</p>

<p><i>[2022-01-31; 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.12.2.2 <a href="https://wg21.link/mem.res.public">[mem.res.public]</a> as indicated:</p>

<blockquote>
<pre>
[[nodiscard]] void* allocate(size_t bytes, size_t alignment = max_align);
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> <del>Equivalent to: <tt>return</tt></del>
<ins>Allocates storage by calling</ins> <tt>do_allocate(bytes, alignment)</tt><del><tt>;</tt></del>
<ins>and implicitly creates objects within the allocated region of storage.</ins>
<p/>
<ins>-?- <i>Returns:</i> A pointer to a suitable created object
(6.7.2 <a href="https://wg21.link/intro.object">[intro.object]</a>) in the allocated region of storage.</ins>
<p/>
<ins>-?- <i>Throws:</i> What and when the call to <tt>do_allocate</tt> throws.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3525" href="https://cplusplus.github.io/LWG/lwg-active.html#3525">3525</a>. <tt>uses_allocator_construction_args</tt> fails to handle types convertible to <tt>pair</tt></h3>
<p><b>Section:</b> 20.10.7.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-23 <b>Last modified:</b> 2022-01-31</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>
As currently specified, the following program is ill-formed (and appears to have been since LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#2975">2975</a>):
</p>
<blockquote><pre>
struct S {
  operator std::pair&lt;const int, int&gt;() const {
    return {};
  }
};

void f() {
  std::pmr::map&lt;int, int&gt; s;
  s.emplace(S{});
}
</pre></blockquote>
<p>
There's no matching overload for <tt>uses_allocator_construction_args&lt;pair&lt;const int, int&gt;&gt;(alloc, S&amp;&amp;)</tt>,
since <tt>S</tt> is not a <tt>pair</tt> and every overload for constructing <tt>pair</tt>s that takes one
non-allocator argument expects a <tt>pair</tt> from which template arguments can be deduced.
</p>
<p><i>[2021-02-27 Tim adds PR and comments]</i></p>

<p>The superseded resolution below attempts to solve this issue by adding two
additional overloads of <tt>uses_allocator_construction_args</tt> to
handle this case. However, the new overloads forces implicit conversions
at the call to <tt>uses_allocator_construction_args</tt>, which requires
the result to be consumed within the same full-expression
before any temporary created from the conversion is destroyed.
This is not the case for the <tt>piecewise_construct</tt> overload of
<tt>uses_allocator_construction_args</tt>, which recursively calls
<tt>uses_allocator_construction_args</tt> for the two elements of the pair, which
might themselves be <tt>pair</tt>s.</p>
<p>
The approach taken in the revised PR is to produce an exposition-only
<tt><i>pair-constructor</i></tt> object instead. The object holds the allocator
and the argument by reference, implicitly converts to the specified specialization of <tt>pair</tt>,
and when so converted return a <tt>pair</tt> that is constructed by uses-allocator
construction with the converted value of the original argument.
This maintains the existing design that <tt>pair</tt> itself doesn't know
anything about allocator construction.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<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.7.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>, uses-allocator construction</i>
  [&hellip;]

<ins>  template&lt;class T, class Alloc&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    const remove_cv_t&lt;T&gt;&amp; pr) noexcept;</ins>
  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>;

<ins>  template&lt;class T, class Alloc&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    remove_cv_t&lt;T&gt;&amp;&amp; pr) noexcept;</ins>
  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>;
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Edit 20.10.7.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> as indicated:</p>
<blockquote>
<pre>
<ins>template&lt;class T, class Alloc&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  const remove_cv_t&lt;T&gt;&amp; pr) noexcept;</ins>
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>;
</pre>
<blockquote>
<p>
-12- <i>Constraints:</i> <tt>T</tt> is a specialization of <tt>pair</tt>. <ins>For the second overload, <tt>is_same_v&lt;pair&lt;U, V&gt;, remove_cv_t&lt;T&gt;&gt;</tt> is <tt>false</tt>.</ins>
<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>
<ins>template&lt;class T, class Alloc&gt;
  constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                  remove_cv_t&lt;T&gt;&amp;&amp; pr) noexcept;</ins>
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>
-14- <i>Constraints:</i> <tt>T</tt> is a specialization of <tt>pair</tt>. <ins>For the second overload, <tt>is_same_v&lt;pair&lt;U, V&gt;, remove_cv_t&lt;T&gt;&gt;</tt> is <tt>false</tt>.</ins>
<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>
</blockquote>

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

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

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<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.7.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>, uses-allocator construction</i>
  [&hellip;]

  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    const pair&lt;U, V&gt;&amp; pr) 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,
                                                    pair&lt;U, V&gt;&amp;&amp; pr) noexcept -&gt; <i>see below</i>;


<ins>  template&lt;class T, class Alloc, class U&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, U&amp;&amp; u) noexcept;</ins>
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Add the following to 20.10.7.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>:</p>
<blockquote>
<pre>
<ins>  template&lt;class T, class Alloc, class U&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, U&amp;&amp; u) noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- Let <tt><i>FUN</i></tt> be the function template:</ins>
</p>
<blockquote><pre><ins>
  template&lt;class A, class B&gt;
  void <i>FUN</i>(const pair&lt;A, B&gt;&amp;);</ins>
</pre></blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> is a specialization of <tt>pair</tt>, and the expression <tt><i>FUN</i>(u)</tt> is not well-formed when considered as an unevaluated operand.</ins>
<p/>
<ins>-?- <i>Effects:</i> Equivalent to:</ins>
</p>
<blockquote><pre><ins>
return make_tuple(<i>pair-constructor</i>{alloc, u});</ins>
</pre></blockquote>
<p><ins>where <tt><i>pair-constructor</i></tt> is an exposition-only class defined as follows:</ins></p>
<blockquote><pre><ins>
struct <i>pair-constructor</i> {
  using <i>pair-type</i> = remove_cv_t&lt;T&gt;;            // exposition only

  constexpr operator <i>pair-type</i>() const {
    return <i>do-construct</i>(std::forward&lt;U&gt;(<i>u</i>));
  }

  constexpr auto <i>do-construct</i>(const <i>pair-type</i>&amp; p) const {  // exposition only
    return make_obj_using_allocator&lt;<i>pair-type</i>&gt;(<i>alloc</i>, p);
  }
  constexpr auto <i>do-construct</i>(<i>pair-type</i>&amp;&amp; p) const {  // exposition only
    return make_obj_using_allocator&lt;<i>pair-type</i>&gt;(<i>alloc</i>, std::move(p));
  }

  const Alloc&amp; <i>alloc</i>;  // exposition only
  U&amp; <i>u</i>;                // exposition only
};
</ins></pre></blockquote>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2021-12-02 Tim updates PR to avoid public exposition-only members]</i></p>


<p><i>[2022-01-31; 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/N4901">N4901</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.7.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>, uses-allocator construction</i>
  [&hellip;]
  template&lt;class T, class Alloc, class U, class V&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc,
                                                    pair&lt;U, V&gt;&amp; pr) noexcept;

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

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

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

<ins>  template&lt;class T, class Alloc, class U&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, U&amp;&amp; u) noexcept;</ins>
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Add the following to 20.10.7.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a>:</p>
<blockquote>
<pre>
<ins>  template&lt;class T, class Alloc, class U&gt;
    constexpr auto uses_allocator_construction_args(const Alloc&amp; alloc, U&amp;&amp; u) noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- Let <tt><i>FUN</i></tt> be the function template:</ins>
</p>
<blockquote><pre><ins>
  template&lt;class A, class B&gt;
  void <i>FUN</i>(const pair&lt;A, B&gt;&amp;);</ins>
</pre></blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>T</tt> is a specialization of <tt>pair</tt>, and the expression <tt><i>FUN</i>(u)</tt> is not well-formed when considered as an unevaluated operand.</ins>
<p/>
<ins>-?- Let <tt><i>pair-constructor</i></tt> be an exposition-only class defined as follows:</ins></p>
<blockquote><pre><ins>
class <i>pair-constructor</i> {
  using <i>pair-type</i> = remove_cv_t&lt;T&gt;;            // exposition only

  constexpr auto <i>do-construct</i>(const <i>pair-type</i>&amp; p) const {  // exposition only
    return make_obj_using_allocator&lt;<i>pair-type</i>&gt;(<i>alloc_</i>, p);
  }
  constexpr auto <i>do-construct</i>(<i>pair-type</i>&amp;&amp; p) const {  // exposition only
    return make_obj_using_allocator&lt;<i>pair-type</i>&gt;(<i>alloc_</i>, std::move(p));
  }

  const Alloc&amp; <i>alloc_</i>;  // exposition only
  U&amp; <i>u_</i>;                // exposition only

public:
  constexpr operator <i>pair-type</i>() const {
    return <i>do-construct</i>(std::forward&lt;U&gt;(<i>u_</i>));
  }
};
</ins></pre></blockquote>

<p>
<ins> -?- <i>Returns:</i> <tt>make_tuple(<i>pc</i>)</tt>, where <tt><i>pc</i></tt>
is a <tt><i>pair-constructor</i></tt> object whose <tt><i>alloc_</i></tt> member is
initialized with <tt>alloc</tt> and whose <tt><i>u_</i></tt> member is initialized with <tt>u</tt>.
</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3598" href="https://cplusplus.github.io/LWG/lwg-active.html#3598">3598</a>. <tt>system_category().default_error_condition(0)</tt> is underspecified</h3>
<p><b>Section:</b> 19.5.3.5 <a href="https://wg21.link/syserr.errcat.objects">[syserr.errcat.objects]</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> 2021-09-23 <b>Last modified:</b> 2021-10-14</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#syserr.errcat.objects">issues</a> in [syserr.errcat.objects].</p>
<p><b>Discussion:</b></p>
<p>
19.5.3.5 <a href="https://wg21.link/syserr.errcat.objects">[syserr.errcat.objects]</a> says:
</p>
<blockquote><p>
If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, 
the function shall return <tt>error_condition(posv, generic_category())</tt>. Otherwise, 
the function shall return <tt>error_condition(ev, system_category())</tt>. What constitutes 
correspondence for any given operating system is unspecified.
</p></blockquote>
<p>
What is "a POSIX <tt>errno</tt> value"? Does it mean a value equal to one of the <tt>&lt;cerrno&gt;</tt> 
<tt>Exxx</tt> macros? Because in that case, the value <tt>0</tt> is not "a POSIX <tt>errno</tt> value". 
So arguably <tt>system_category().default_error_condition(0)</tt> is required to return an 
<tt>error_condition</tt> using the "system" category, which means that <tt>error_code{} == error_condition{}</tt> 
is required to be <tt>false</tt>. This seems wrong.
<p/>
For POSIX-based systems the value <tt>0</tt> should definitely correspond to the generic category. 
Arguably that needs to be <tt>true</tt> for all systems, because the <tt>std::error_code</tt> API 
strongly encourages a model where zero means "no error".
<p/>
The proposed resolution has been implemented in libstdc++. Libc++ has always treated system error code 
<tt>0</tt> as corresponding to generic error code <tt>0</tt>.
</p>

<p><i>[2021-10-14; 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/n4892">N4892</a>.
</p>

<ol>
<li><p>Modify 19.5.3.5 <a href="https://wg21.link/syserr.errcat.objects">[syserr.errcat.objects]</a> as indicated:</p>

<blockquote>
<pre>
const error_category&amp; system_category() noexcept;
</pre>
<blockquote>
<p>
-3- <i>Returns:</i> [&hellip;]
<p/>
-4- <i>Remarks:</i> The object's <tt>equivalent</tt> virtual functions shall behave as specified 
for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function shall return a pointer 
to the string <tt>"system"</tt>. The object's <tt>default_error_condition</tt> virtual function 
shall behave as follows:
<p/>
If the argument <tt>ev</tt> <ins>is equal to <tt>0</tt>, the function returns 
<tt>error_condition(0, generic_category())</tt>. Otherwise, if <tt>ev</tt></ins> corresponds to a POSIX 
<tt>errno</tt> value <tt>posv</tt>, the function <del>shall return</del><ins>returns</ins> 
<tt>error_condition(posv, generic_category())</tt>. Otherwise, the function <del>shall return</del><ins>returns</ins> 
<tt>error_condition(ev, system_category())</tt>. What constitutes correspondence for any given operating 
system is unspecified.
<p/>
[<i>Note 1</i>: The number of potential system error codes is large and unbounded, and some might not 
correspond to any POSIX <tt>errno</tt> value. Thus implementations are given latitude in determining 
correspondence. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3601" href="https://cplusplus.github.io/LWG/lwg-active.html#3601">3601</a>. <tt>common_iterator</tt>'s <tt><i>postfix-proxy</i></tt> needs <tt>indirectly_readable</tt></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> Casey Carter <b>Opened:</b> 2021-09-24 <b>Last modified:</b> 2021-10-14</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#common.iter.nav">issues</a> in [common.iter.nav].</p>
<p><b>Discussion:</b></p>
<p>
It would appear that when <a href="https://wg21.link/p2259r1">P2259R1</a> added <tt><i>postfix-proxy</i></tt> to 
<tt>common_iterator::operator++(int)</tt> LWG missed a crucial difference between <tt>operator++(int)</tt> and 
<tt>operator-&gt;</tt> which uses a similar proxy: <tt>operator-&gt;</tt> requires the wrapped type to be 
<tt>indirectly_readable</tt>, but <tt>operator++(int)</tt> does not. Consequently, operations that read from the 
wrapped type for the <tt><i>postfix-proxy</i></tt> case in <tt>operator++(int)</tt> are not properly constrained 
to be valid.
</p>

<p><i>[2021-10-14; 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/n4892">N4892</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><ins>indirectly_readable&lt;I&gt; &amp;&amp;</ins> constructible_from&lt;iter_value_t&lt;I&gt;, 
iter_reference_t&lt;I&gt;&gt; &amp;&amp; move_constructible&lt;iter_value_t&lt;I&gt;&gt;</tt> is <tt>false</tt>, 
equivalent to:
</p>
<blockquote><pre>
return get&lt;I&gt;(v_)++;
</pre></blockquote>
<p>
Otherwise, equivalent to: [&hellip;]
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3607" href="https://cplusplus.github.io/LWG/lwg-active.html#3607">3607</a>. <tt>contiguous_iterator</tt> should not be allowed to have custom <tt>iter_move</tt> and <tt>iter_swap</tt> behavior</h3>
<p><b>Section:</b> 23.3.4.14 <a href="https://wg21.link/iterator.concept.contiguous">[iterator.concept.contiguous]</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-09-28 <b>Last modified:</b> 2021-10-23</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
The <tt>iter_move</tt> and <tt>iter_swap</tt> customization points were introduced
primarily for proxy iterators. Whatever their application to non-proxy
iterators in general, they should not be allowed to have custom
behavior for contiguous iterators &mdash; this new iterator category was
introduced in large part to permit better optimizations, and allowing
custom <tt>iter_move/iter_swap</tt> prevents such optimizations for a wide
variety of algorithms that are specified to call them.
</p>

<p><i>[2021-10-14; 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/n4892">N4892</a>.
</p>

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

<blockquote>
<pre>
template&lt;class I&gt;
  concept contiguous_iterator =
    random_access_iterator&lt;I&gt; &amp;&amp;
    derived_from&lt;<i>ITER_CONCEPT</i>(I), contiguous_iterator_tag&gt; &amp;&amp;
    is_lvalue_reference_v&lt;iter_reference_t&lt;I&gt;&gt; &amp;&amp;
    same_as&lt;iter_value_t&lt;I&gt;, remove_cvref_t&lt;iter_reference_t&lt;I&gt;&gt;&gt; &amp;&amp;
    requires(const I&amp; i) {
      { to_address(i) } -&gt; same_as&lt;add_pointer_t&lt;iter_reference_t&lt;I&gt;&gt;&gt;;
    };
</pre>
<blockquote>
<p>
-2- Let <tt>a</tt> and <tt>b</tt> be dereferenceable iterators and <tt>c</tt> be a non-dereferenceable 
iterator of type <tt>I</tt> such that <tt>b</tt> is reachable from <tt>a</tt> and <tt>c</tt> is 
reachable from <tt>b</tt>, and let <tt>D</tt> be <tt>iter_difference_t&lt;I&gt;</tt>. The type <tt>I</tt> 
models <tt>contiguous_iterator</tt> only if
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; <tt>to_address(a) == addressof(*a)</tt>,</p></li>
<li><p>(2.2) &mdash; <tt>to_address(b) == to_address(a) + D(b - a)</tt>, <del>and</del></p></li>
<li><p>(2.3) &mdash; <tt>to_address(c) == to_address(a) + D(c - a)</tt><del>.</del><ins>,</ins></p></li>
<li><p><ins>(2.?) &mdash; <tt>ranges::iter_move(a)</tt> has the same type, value category, and effects as 
<tt>std::move(*a)</tt>, and</ins></p></li>
<li><p><ins>(2.?) &mdash; if <tt>ranges::iter_swap(a, b)</tt> is well-formed, it has effects
equivalent to <tt>ranges::swap(*a, *b)</tt>.</ins></p></li>
</ol>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3610" href="https://cplusplus.github.io/LWG/lwg-active.html#3610">3610</a>. <tt>iota_view::size</tt> sometimes rejects integer-class types</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> Jiang An <b>Opened:</b> 2021-09-29 <b>Last modified:</b> 2021-10-14</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#range.iota.view">active issues</a> in [range.iota.view].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#range.iota.view">issues</a> in [range.iota.view].</p>
<p><b>Discussion:</b></p>
<p>
It seems that the <tt>iota_view</tt> tends to accept integer-class types as its value types, by using 
<tt><i>is-integer-like</i></tt> or <tt><i>is-signed-integer-like</i></tt> through the specification, 
although it's unspecified whether any of them satisfies <tt>weakly_incrementable</tt>. However, the 
<i>requires-clause</i> of <tt>iota_view::size</tt> (24.6.4.2 <a href="https://wg21.link/range.iota.view">[range.iota.view]</a> p16) uses 
<tt>(integral&lt;W&gt; &amp;&amp; integral&lt;Bound&gt;)</tt>, which sometimes rejects integer-class types.
<p/>
Should we relax the restrictions by changing this part to <tt>(<i>is-integer-like</i>&lt;W&gt; &amp;&amp; 
<i>is-integer-like</i>&lt;Bound&gt;)</tt>?
</p>

<p><i>[2021-10-14; 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/n4892">N4892</a>.
</p>

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

<blockquote>
<pre>
constexpr auto size() const requires <i>see below</i>;
</pre>
<blockquote>
<p>
-15- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
if constexpr (<i>is-integer-like</i>&lt;W&gt; &amp;&amp; <i>is-integer-like</i>&lt;Bound&gt;)
  return (<i>value_</i> &lt; 0)
    ? ((<i>bound_</i> &lt; 0)
      ? <i>to-unsigned-like</i>(-<i>value_</i>) - <i>to-unsigned-like</i>(-<i>bound_</i>)
      : <i>to-unsigned-like</i>(<i>bound_</i>) + <i>to-unsigned-like</i>(-<i>value_</i>))
    : <i>to-unsigned-like</i>(<i>bound_</i>) - <i>to-unsigned-like</i>(<i>value_</i>);
else
  return <i>to-unsigned-like</i>(<i>bound_</i> - <i>value_</i>);
</pre></blockquote>
<p>
-16- <i>Remarks:</i> The expression in the <i>requires-clause</i> is equivalent to:
</p>
<blockquote><pre>
(same_as&lt;W, Bound&gt; &amp;&amp; <i>advanceable</i>&lt;W&gt;) || (<del>integral</del><ins><i>is-integer-like</i></ins>&lt;W&gt; &amp;&amp; <del>integral</del><ins><i>is-integer-like</i></ins>&lt;Bound&gt;) ||
  sized_sentinel_for&lt;Bound, W&gt;
</pre></blockquote>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3612" href="https://cplusplus.github.io/LWG/lwg-active.html#3612">3612</a>. Inconsistent pointer alignment in <tt>std::format</tt></h3>
<p><b>Section:</b> 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Victor Zverovich <b>Opened:</b> 2021-10-02 <b>Last modified:</b> 2021-10-14</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.string.std">active issues</a> in [format.string.std].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#format.string.std">issues</a> in [format.string.std].</p>
<p><b>Discussion:</b></p>
<p>
According to [tab:format.type.ptr] pointers are formatted as hexadecimal integers (at least in the 
common case when <tt>uintptr_t</tt> is available). However, it appears that they have left alignment 
by default according to [tab:format.align]:
</p>
<blockquote><p>
Forces the field to be aligned to the start of the available space. This is the default for non-arithmetic 
types, <tt>charT</tt>, and <tt>bool</tt>, unless an integer presentation type is specified.
</p></blockquote>
<p>
because pointers are not arithmetic types.
<p/>
For example:
</p>
<blockquote><pre>
void* p = &hellip;
std::format("{:#16x}", std::bit_cast&lt;uintptr_t&gt;(p));
std::format("{:16}", p);
</pre></blockquote>
<p>
may produce <tt>"  0x7fff88716c84"</tt> and <tt>"0x7fff88716c84  "</tt> (the actual output depends 
on the value of <tt>p</tt>).
<p/>
This is inconsistent and clearly a bug in specification that should have included pointers together 
with arithmetic types in [tab:format.align].
</p>

<p><i>[2021-10-14; 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/n4892">N4892</a>.
</p>

<ol>
<li><p>Modify 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a>, Table [tab:format.align], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 59 &mdash; Meaning of <i>align</i> options  [tab:format.align]</caption>
<tr style="text-align:center">
<th>Option</th>
<th>Meaning</th>
</tr>
<tr>
<td><tt>&lt;</tt></td>
<td>Forces the field to be aligned to the start of the available space. This is the default for
non-arithmetic <ins>non-pointer</ins> types, <tt>charT</tt>, and <tt>bool</tt>, unless an integer 
presentation type is specified.</td>
</tr>
<tr>
<td><tt>&gt;</tt></td>
<td>Forces the field to be aligned to the end of the available space. This is the default for
arithmetic types other than <tt>charT</tt> and <tt>bool</tt><ins>, pointer types</ins> or when an 
integer presentation type is specified.</td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>
</blockquote>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The wording above touches a similar area as LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3586">3586</a>. To help solving the
merge conflict the following shows the delta of this proposed wording on top of the LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3586">3586</a>
merge result]
</p>
</blockquote>

<blockquote>
<table border="1">
<caption>Table 59 &mdash; Meaning of <i>align</i> options  [tab:format.align]</caption>
<tr style="text-align:center">
<th>Option</th>
<th>Meaning</th>
</tr>
<tr>
<td><tt>&lt;</tt></td>
<td>Forces the field to be aligned to the start of the available space. This is the default when 
the presentation type is a non-arithmetic <ins>non-pointer</ins> type.</td>
</tr>
<tr>
<td><tt>&gt;</tt></td>
<td>Forces the field to be aligned to the end of the available space. This is the default when 
the presentation type is an arithmetic <ins>or pointer</ins> type.</td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3616" href="https://cplusplus.github.io/LWG/lwg-active.html#3616">3616</a>. LWG 3498 seems to miss the non-member <tt>swap</tt> for <tt>basic_syncbuf</tt></h3>
<p><b>Section:</b> 29.11.2.6 <a href="https://wg21.link/syncstream.syncbuf.special">[syncstream.syncbuf.special]</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-10-07 <b>Last modified:</b> 2021-10-14</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3498">3498</a> fixes the inconsistent <tt>noexcept</tt>-specifiers for member functions of <tt>basic_syncbuf</tt>, 
but the proposed resolution in LWG <a href="https://cplusplus.github.io/LWG/lwg-defects.html#3498">3498</a> seems to miss the non-member <tt>swap</tt>, which also has 
inconsistent <tt>noexcept</tt>-specifier: 29.11.2.6 <a href="https://wg21.link/syncstream.syncbuf.special">[syncstream.syncbuf.special]</a> says it's <tt>noexcept</tt>, 
while 29.11.1 <a href="https://wg21.link/syncstream.syn">[syncstream.syn]</a> says it's not.
<p/>
Since the non-member <tt>swap</tt> and the member <tt>swap</tt> have equivalent effect, and LWG 3498 removes 
<tt>noexcept</tt> from the latter, I think it's pretty clear that the former should not be <tt>noexcept</tt>.
</p>

<p><i>[2021-10-14; 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/n4892">N4892</a>.
</p>

<ol>
<li><p>Modify 29.11.2.6 <a href="https://wg21.link/syncstream.syncbuf.special">[syncstream.syncbuf.special]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class charT, class traits, class Allocator&gt;
  void swap(basic_syncbuf&lt;charT, traits, Allocator&gt;&amp; a,
            basic_syncbuf&lt;charT, traits, Allocator&gt;&amp; b) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to <tt>a.swap(b)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3618" href="https://cplusplus.github.io/LWG/lwg-active.html#3618">3618</a>. Unnecessary <tt>iter_move</tt> for <tt>transform_view::iterator</tt></h3>
<p><b>Section:</b> 24.7.7.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2021-10-12 <b>Last modified:</b> 2021-10-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#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</tt>'s iterator currently specifies a customization point for <tt>iter_move</tt>. 
 This customization point does the same thing that the default implementation would do &mdash; 
 <tt>std::move(*E)</tt> if <tt>*E</tt> is an lvalue, else <tt>*E</tt> &mdash; except that it is only 
 there to provide the correct conditional <tt>noexcept</tt> specification. But for <tt>iota_view</tt>, 
 we instead provide a <tt>noexcept</tt>-specifier on the iterator's <tt>operator*</tt>. We should do 
 the same thing for both, and the simplest thing would be:
<p/>
Change 24.7.7.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a> to put the whole body into <tt>noexcept</tt>:
</p>
<blockquote><pre>
constexpr decltype(auto) operator*() const <ins>noexcept(noexcept(invoke(*<i>parent_</i>-&gt;<i>fun_</i>, *<i>current_</i>)))</ins> {
  return invoke(*<i>parent_</i>-&gt;<i>fun_</i>, *<i>current_</i>);
} 
</pre></blockquote>
<p>
And to remove this:
</p>
<blockquote><pre>
friend constexpr decltype(auto) iter_move(const <i>iterator</i>&amp; i)
  noexcept(noexcept(invoke(*i.<i>parent_</i>-&gt;<i>fun_</i>, *i.<i>current_</i>))) {
  if constexpr (is_lvalue_reference_v&lt;decltype(*i)&gt;)
    return std::move(*i);
  else
    return *i;
}
</pre></blockquote>

<p><i>[2022-01-29; 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/n4892">N4892</a>.
</p>

<ol>
<li><p>Modify 24.7.7.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a>, class template <tt>transform_view::<i>iterator</i></tt>, 
as indicated:</p>

<blockquote>
<pre>
[&hellip;]
constexpr decltype(auto) operator*() const <ins>noexcept(noexcept(invoke(*<i>parent_</i>-&gt;<i>fun_</i>, *<i>current_</i>)))</ins> {
  return invoke(*<i>parent_</i>-&gt;<i>fun_</i>, *<i>current_</i>);
}
[&hellip;]
<del>friend constexpr decltype(auto) iter_move(const <i>iterator</i>&amp; i)
  noexcept(noexcept(invoke(*i.<i>parent_</i>-&gt;<i>fun_</i>, *i.<i>current_</i>))) {
  if constexpr (is_lvalue_reference_v&lt;decltype(*i)&gt;)
    return std::move(*i);
  else
    return *i;
}</del>
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3619" href="https://cplusplus.github.io/LWG/lwg-active.html#3619">3619</a>. Specification of <tt>vformat_to</tt> contains ill-formed <tt>formatted_size</tt> calls</h3>
<p><b>Section:</b> 20.20.5 <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> Tim Song <b>Opened:</b> 2021-10-17 <b>Last modified:</b> 2021-10-17</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>
The specification of <tt>vformat_to</tt> says that it formats "into the range
<tt>[out, out + N)</tt>, where <tt>N</tt> is <tt>formatted_size(fmt, args...)</tt> for the
functions without a <tt>loc</tt> parameter and <tt>formatted_size(loc, fmt, args...)</tt> 
for the functions with a <tt>loc</tt> parameter".
<p/>
This is wrong in at least two ways:
</p>
<ul>
<li><p>First, <tt>args</tt> is a <tt>(w)format_args</tt>, not a pack, so it doesn't make
sense to use <tt>...</tt> to expand it.</p></li>
<li><p>Second, <tt>fmt</tt> is a <tt>(w)string_view</tt> parameter, and it is never a
constant expression, and so the call is ill-formed after <a href="https://wg21.link/P2216">P2216</a> added 
compile-time format string checking.</p></li>
</ul>

<p><i>[2022-01-29; 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/n4892">N4892</a>.
</p>

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

<blockquote>
<pre>
template&lt;class Out&gt;
  Out vformat_to(Out out, string_view fmt, format_args args);
template&lt;class Out&gt;
  Out vformat_to(Out out, wstring_view fmt, wformat_args args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, string_view fmt, format_args args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, wstring_view fmt, wformat_args args);
</pre>
<blockquote>
<p>
-12- Let <tt>charT</tt> be <tt>decltype(fmt)::value_type</tt>.
<p/>
-13- <i>Constraints:</i> <tt>Out</tt> satisfies <tt>output_iterator&lt;const charT&amp;&gt;</tt>.
<p/>
-14- <i>Preconditions:</i> <tt>Out</tt> models <tt>output_iterator&lt;const charT&amp;&gt;</tt>.
<p/>
-15- <i>Effects:</i> Places the character representation of formatting the arguments provided by 
<tt>args</tt>, formatted according to the specifications given in <tt>fmt</tt>, into the range 
<tt>[out, out + N)</tt>, where <tt>N</tt> is <del><tt>formatted_size(fmt, args...)</tt> for the 
functions without a <tt>loc</tt> parameter and <tt>formatted_size(loc, fmt, args...)</tt> for 
the functions with a <tt>loc</tt> parameter</del><ins>the number of characters in that
character representation</ins>. If present, <tt>loc</tt> is used for locale-specific formatting.
<p/>
-16- <i>Returns:</i> <tt>out + N</tt>.
<p/>
-17- [&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3621" href="https://cplusplus.github.io/LWG/lwg-active.html#3621">3621</a>. Remove feature-test macro <tt>__cpp_lib_monadic_optional</tt></h3>
<p><b>Section:</b> 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2021-10-18 <b>Last modified:</b> 2021-10-23</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="https://cplusplus.github.io/LWG/lwg-index-open.html#version.syn">active issues</a> in [version.syn].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#version.syn">issues</a> in [version.syn].</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P0798R8">P0798R8</a> "Monadic operations for <tt>std::optional</tt>"
created a new feature-test macro <tt>__cpp_lib_monadic_optional</tt>
for a relatively minor enhancement.
<p/>
We should instead increment the value of the existing
feature-test macro <tt>__cpp_lib_optional</tt>.
</p>

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

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

<blockquote>
<pre>
[&hellip;]
<del>#define __cpp_lib_monadic_optional 202110L <i>// also in &lt;optional&gt;</i></del>
[&hellip;]
#define __cpp_lib_optional <del>202106L</del><ins>202110L</ins> <i>// also in &lt;optional&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3632" href="https://cplusplus.github.io/LWG/lwg-active.html#3632">3632</a>. <tt>unique_ptr</tt> "<i>Mandates:</i> This constructor is not selected by class template argument deduction"</h3>
<p><b>Section:</b> 20.11.1.3.2 <a href="https://wg21.link/unique.ptr.single.ctor">[unique.ptr.single.ctor]</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-11-03 <b>Last modified:</b> 2021-11-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P1460R1">P1460R1</a> changed the wording for <tt>unique_ptr</tt>'s constructor <tt>unique_ptr(pointer)</tt>.
In C++17, it said in [unique.ptr.single.ctor] p5:
</p>
<blockquote>
<pre>
explicit unique_ptr(pointer p) noexcept;
</pre>
<blockquote>
<p>
<i>Preconditions:</i> [&hellip;]
<p/>
<i>Effects:</i> [&hellip;]
<p/>
<i>Postconditions:</i> [&hellip;]
<p/>
<b><i>Remarks:</i></b> If <tt>is_pointer_v&lt;deleter_type&gt;</tt> is <tt>true</tt> or 
<tt>is_default_constructible_v&lt;deleter_type&gt;</tt> is <tt>false</tt>, this constructor shall not 
participate in overload resolution. <b>If class template argument deduction would select the function 
template corresponding to this constructor, then the program is ill-formed</b>.
</p>
</blockquote>
</blockquote>
<p>
In C++20, it says in [unique.ptr.single.ctor] p5:
</p>
<blockquote>
<pre>
explicit unique_ptr(pointer p) noexcept;
</pre>
<blockquote>
<p>
<i>Constraints:</i> <tt>is_pointer_v&lt;deleter_type&gt;</tt> is <tt>false</tt> and 
<tt>is_default_constructible_v&lt;deleter_type&gt;</tt> is <tt>true</tt>.
<p/>
<b><i>Mandates:</i> This constructor is not selected by class template argument deduction.</b>
<p/>
<i>Preconditions:</i> [&hellip;]
<p/>
<i>Effects:</i> [&hellip;]
<p/>
<i>Postconditions:</i> [&hellip;]
</p>
</blockquote>
</blockquote>
<p>
Normally, we use "<i>Mandates:</i>" for <tt>static_assert</tt>-like stuff, not just to indicate that 
some constructor doesn't contribute to CTAD. Both libstdc++ and Microsoft (and soon libc++, see 
<a href="https://reviews.llvm.org/D112904">LLVM issue</a>) seem to agree about the intent of this wording: 
It's basically asking for the constructor to be implemented with a CTAD firewall, as
</p>
<blockquote>
<pre>
explicit unique_ptr(type_identity_t&lt;pointer&gt; p) noexcept;
</pre>
</blockquote>
<p>
and there is no actual <tt>static_assert</tt> corresponding to this "<i>Mandates:</i>" element. In particular, 
the following program is well-formed on all vendors:
</p>
<blockquote>
<pre>
// <a href="https://godbolt.org/z/h5bb1WbTz">godbolt link</a>
template&lt;class T&gt; auto f(T p) -&gt; decltype(std::unique_ptr(p));
template&lt;class T&gt; constexpr bool f(T p) { return true; }  
static_assert(f((int*)nullptr));
</pre>
</blockquote>
<p>
I claim that this is a confusing and/or wrong use of "<i>Mandates:</i>". My proposed resolution is 
simply to respecify the constructor as
</p>
<blockquote>
<pre>
explicit unique_ptr(<b>type_identity_t&lt;pointer&gt;</b> p) noexcept;
</pre>
<blockquote>
<p>
<i>Constraints:</i> <tt>is_pointer_v&lt;deleter_type&gt;</tt> is <tt>false</tt> and 
<tt>is_default_constructible_v&lt;deleter_type&gt;</tt> is <tt>true</tt>.
<p/>
<i>Preconditions:</i> [&hellip;]
<p/>
<i>Effects:</i> [&hellip;]
<p/>
<i>Postconditions:</i> [&hellip;]
</p>
</blockquote>
</blockquote>
<p>
with no <i>Mandates:</i> or <i>Remarks:</i> elements at all.
</p>

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

<ol>

<li><p>Modify 20.11.1.3.1 <a href="https://wg21.link/unique.ptr.single.general">[unique.ptr.single.general]</a>, class template <tt>unique_ptr</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 20.11.1.3.2 <a href="https://wg21.link/unique.ptr.single.ctor">[unique.ptr.single.ctor]</a>, constructors</i>
constexpr unique_ptr() noexcept;
explicit unique_ptr(<ins>type_identity_t&lt;</ins>pointer<ins>&gt;</ins> p) noexcept;
unique_ptr(<ins>type_identity_t&lt;</ins>pointer<ins>&gt;</ins> p, <i>see below</i> d1) noexcept;
unique_ptr(<ins>type_identity_t&lt;</ins>pointer<ins>&gt;</ins> p, <i>see below</i> d2) noexcept;
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 20.11.1.3.2 <a href="https://wg21.link/unique.ptr.single.ctor">[unique.ptr.single.ctor]</a> as indicated:</p>

<blockquote>
<pre>
explicit unique_ptr(<ins>type_identity_t&lt;</ins>pointer<ins>&gt;</ins> p) noexcept;
</pre>
<blockquote>
<p>
-5- <i>Constraints:</i> <tt>is_pointer_v&lt;deleter_type&gt;</tt> is <tt>false</tt> and 
<tt>is_default_constructible_v&lt;deleter_type&gt;</tt> is <tt>true</tt>.
<p/>
<del>-6- <i>Mandates:</i> This constructor is not selected by class template argument 
deduction (12.2.2.9 <a href="https://wg21.link/over.match.class.deduct">[over.match.class.deduct]</a>).</del>
<p/>
-7- <i>Preconditions:</i> [&hellip;]
<p/>
-8- <i>Effects:</i> [&hellip;]
<p/>
-9- <i>Postconditions:</i> [&hellip;]
</p>
</blockquote>
<pre>
unique_ptr(<ins>type_identity_t&lt;</ins>pointer<ins>&gt;</ins> p, const D&amp; d) noexcept;
unique_ptr(<ins>type_identity_t&lt;</ins>pointer<ins>&gt;</ins> p, remove_reference_t&lt;D&gt;&amp;&amp; d) noexcept;
</pre>
<blockquote>
<p>
-10- <i>Constraints:</i> <tt>is_constructible_v&lt;D, decltype(d)&gt;</tt> is <tt>true</tt>.
<p/>
<del>-11- <i>Mandates:</i> These constructors are not selected by class template argument 
deduction (12.2.2.9 <a href="https://wg21.link/over.match.class.deduct">[over.match.class.deduct]</a>).</del>
<p/>
-12- <i>Preconditions:</i> [&hellip;]
<p/>
-13- <i>Effects:</i> [&hellip;]
<p/>
-14- <i>Postconditions:</i> [&hellip;]
<p/>
-15- <i>Remarks:</i> If <tt>D</tt> is a reference type, the second constructor is defined as deleted.
<p/>
-16- [<i>Example 1</i>: [&hellip;] &mdash; <i>end example</i>]
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3643" href="https://cplusplus.github.io/LWG/lwg-active.html#3643">3643</a>. Missing <tt>constexpr</tt> in <tt>std::counted_iterator</tt></h3>
<p><b>Section:</b> 23.5.6.5 <a href="https://wg21.link/counted.iter.nav">[counted.iter.nav]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jiang An <b>Opened:</b> 2021-11-21 <b>Last modified:</b> 2022-01-30</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
One overload of <tt>std::counted_operator::operator++</tt> is not <tt>constexpr</tt> currently, 
which is seemly because of that a try-block (specified in 23.5.6.5 <a href="https://wg21.link/counted.iter.nav">[counted.iter.nav]</a>/4) 
is not allowed in a constexpr function until C++20. Given a try-block is allowed in a constexpr 
function in C++20, IMO this overload should also be <tt>constexpr</tt>.
<p/>
MSVC STL has already added <tt>constexpr</tt> <a href="https://github.com/microsoft/STL/blob/1e42166b78f814c9150afff98cc399773eda8ddf/stl/inc/iterator#L599">at first</a>. 
The situation of this overload is originally found by Casey Carter, but no LWG issue has been submitted.
</p>

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

<ol>

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

<blockquote>
<pre>
[&hellip;]
constexpr counted_iterator&amp; operator++();
<ins>constexpr</ins> decltype(auto) operator++(int);
constexpr counted_iterator operator++(int)
  requires forward_iterator&lt;I&gt;;
constexpr counted_iterator&amp; operator--()
  requires bidirectional_iterator&lt;I&gt;;
constexpr counted_iterator operator--(int)
  requires bidirectional_iterator&lt;I&gt;;
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
<ins>constexpr</ins> decltype(auto) operator++(int);
</pre>
<blockquote>
<p>
-3- <i>Preconditions:</i> <tt>length &gt; 0</tt>.
<p/>
-4- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
--length;
try { return current++; }
catch(...) { ++length; throw; }
</pre></blockquote>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3648" href="https://cplusplus.github.io/LWG/lwg-active.html#3648">3648</a>. <tt>format</tt> should not print <tt>bool</tt> with <tt>'c'</tt></h3>
<p><b>Section:</b> 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2021-11-30 <b>Last modified:</b> 2022-01-30</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.string.std">active issues</a> in [format.string.std].</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#format.string.std">issues</a> in [format.string.std].</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/P1652R1">P1652R1</a> prints integral inputs as characters with <tt>'c'</tt> and preserves the
wording to treat <tt>bool</tt> as a one-byte unsigned integer; this accidentally asks the 
implementation to cast <tt>bool</tt> into a 1-bit character if a user asks for the <tt>'c'</tt> 
presentation type.
<p/>
Recent wording improvements made this implied behavior obvious.
</p>

<p><i>[2021-12-04; Daniel comments]</i></p>

<p>
This issue relates to LWG <a href="https://cplusplus.github.io/LWG/lwg-active.html#3644">3644</a>.
</p>

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

<ol>

<li><p>Modify 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a>, Table 67 [tab:format.type.bool], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 67 &mdash; Meaning of <i>type</i> options for <tt>bool</tt> [tab:format.type.bool]</caption>
<tr style="text-align:center">
<th>Type</th>
<th>Meaning</th>
</tr>
<tr>
<td>none, <tt>s</tt></td>
<td>Copies textual representation, either <tt>true</tt> or <tt>false</tt>, to the output.</td>
</tr>
<tr>
<td><tt>b</tt>, <tt>B</tt>, <del><tt>c</tt>,</del> <tt>d</tt>, <tt>o</tt>, <tt>x</tt>, <tt>X</tt></td>
<td>As specified in Table 65 [tab:format.type.int] for the value <tt>static_cast&lt;unsigned char&gt;(value)</tt>.</td>
</tr>
</table>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3649" href="https://cplusplus.github.io/LWG/lwg-active.html#3649">3649</a>. [fund.ts.v3] Reinstate and bump <tt>__cpp_lib_experimental_memory_resource</tt> feature test macro</h3>
<p><b>Section:</b> 1.5 [fund.ts.v3::general.feature.test] <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-12-03 <b>Last modified:</b> 2022-01-30</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v3</b></p>
<p>
The rebase on C++17 in <a href="https://wg21.link/P0996">P0996</a> had the effect of deleting the feature test macro 
<tt>__cpp_lib_experimental_memory_resource</tt>: the macro was ostensibly tied to the 
<tt>memory_resource</tt> facility that had become part of C++17, but we overlooked that there 
was a residual piece that has not been adopted in the IS, namely the <tt>resource_adaptor</tt> 
class template.
<p/>
It is still useful to be able to detect the presence of <tt>resource_adaptor</tt>, so we should 
reinstate the feature test macro and bump its value.
</p>

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

<ol>

<li><p>Modify 1.5 [fund.ts.v3::general.feature.test], Table 2, as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 2 &mdash; Significant features in this technical specification</caption>
<tr style="text-align:center">
<th>Doc. No.</th>
<th>Title</th>
<th>Primary<br/>Section</th>
<th>Macro Name Suffix</th>
<th>Value</th>
<th>Header</th>
</tr>
<tr>
<td colspan="6" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>N3916</td>
<td>Type-erased allocator for std::function</td>
<td>4.2</td>
<td><tt>function_erased_allocator</tt></td>
<td><tt>201406</tt></td>
<td><tt>&lt;experimental/functional&gt;</tt></td>
</tr>

<tr>
<td><ins>N3916</ins></td>
<td><ins>Polymorphic Memory Resources</ins></td>
<td><ins>5.4 [fund.ts.v3::memory.resource.syn]</ins></td>
<td><ins><tt>memory_resources</tt></ins></td>
<td><ins><i>[new value]</i></ins></td>
<td><ins><tt>&lt;experimental/memory_resource&gt;</tt></ins></td>
</tr>

<tr>
<td>N4282</td>
<td>The World's Dumbest Smart Pointer</td>
<td>8.12</td>
<td><tt>observer_ptr</tt></td>
<td><tt>201411</tt></td>
<td><tt>&lt;experimental/memory&gt;</tt></td>
</tr>

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

</ol>





<hr>
<h3><a name="3650" href="https://cplusplus.github.io/LWG/lwg-active.html#3650">3650</a>. Are <tt>std::basic_string</tt>'s <tt>iterator</tt> and <tt>const_iterator</tt> constexpr iterators?</h3>
<p><b>Section:</b> 21.3.3.1 <a href="https://wg21.link/basic.string.general">[basic.string.general]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jiang An <b>Opened:</b> 2021-12-04 <b>Last modified:</b> 2022-01-30</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::vector</tt>'s <tt>iterator</tt> and <tt>const_iterator</tt> are required to meet constexpr iterator 
requirements in C++20 per <a href="https://wg21.link/P1004R2">P1004R2</a>, but it seems that the similar wording is missing for 
<tt>std::basic_string</tt> in both <a href="https://wg21.link/P0980R1">P0980R1</a> and the current working draft.
<p/>
I think we should add a bullet "The types <tt>iterator</tt> and <tt>const_iterator</tt> meet the constexpr 
iterator requirements (23.3.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a>)." to 21.3.3.1 <a href="https://wg21.link/basic.string.general">[basic.string.general]</a>.
</p>

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

<ol>

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

<blockquote>
<p>
-3- In all cases, <tt>[data(), data() + size()]</tt> is a valid range, <tt>data() + size()</tt> 
points at an object with value <tt>charT()</tt> (a "null terminator"), and <tt>size() &lt;= capacity()</tt>
is <tt>true</tt>.
<p/>
-4- A <tt>size_type</tt> parameter type in a <tt>basic_string</tt> deduction guide refers to the 
<tt>size_type</tt> member type of the type deduced by the deduction guide.
<p/>
<ins>-?- The types <tt>iterator</tt> and <tt>const_iterator</tt> meet the constexpr iterator requirements 
(23.3.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a>).</ins>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3654" href="https://cplusplus.github.io/LWG/lwg-active.html#3654">3654</a>. <tt>basic_format_context::arg(size_t)</tt> should be <tt>noexcept</tt></h3>
<p><b>Section:</b> 20.20.6.4 <a href="https://wg21.link/format.context">[format.context]</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-12-26 <b>Last modified:</b> 2022-01-30</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.context">issues</a> in [format.context].</p>
<p><b>Discussion:</b></p>
<p>
<tt>basic_format_context::arg(size_t)</tt> simply returns <tt>args_.get(id)</tt> to get the elements of 
<tt>args_</tt>, where the type of <tt>args_</tt> is <tt>basic_format_args&lt;basic_format_context&gt;</tt>. 
Since <tt>basic_format_args</tt>'s <tt>get(size_t)</tt> is <tt>noexcept</tt>, this function can also be 
<tt>noexcept</tt>.
</p>

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

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

<blockquote>
<blockquote>
<pre>
namespace std {
  template&lt;class Out, class charT&gt;
  class basic_format_context {
    basic_format_args&lt;basic_format_context&gt; args_; <i>// exposition only</i>
    Out out_; <i>// exposition only</i>
  public:
    using iterator = Out;
    using char_type = charT;
    template&lt;class T&gt; using formatter_type = formatter&lt;T, charT&gt;;
    
    basic_format_arg&lt;basic_format_context&gt; arg(size_t id) const <ins>noexcept</ins>;
    std::locale locale();

    iterator out();
    void advance_to(iterator it);
  };
}
</pre>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
basic_format_arg&lt;basic_format_context&gt; arg(size_t id) const <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-5- <i>Returns:</i> <tt>args_.get(id)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3657" href="https://cplusplus.github.io/LWG/lwg-active.html#3657">3657</a>. <tt>std::hash&lt;std::filesystem::path&gt;</tt> is not enabled</h3>
<p><b>Section:</b> 29.12.6 <a href="https://wg21.link/fs.class.path">[fs.class.path]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jiang An <b>Opened:</b> 2022-01-02 <b>Last modified:</b> 2022-01-30</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="https://cplusplus.github.io/LWG/lwg-index.html#fs.class.path">issues</a> in [fs.class.path].</p>
<p><b>Discussion:</b></p>
<p>
The hash support of <tt>std::filesystem::path</tt> is provided by <tt>std::filesystem::hash_value</tt>, 
but the specialization <tt>std::hash&lt;std::filesystem::path&gt;</tt> is currently disabled. IMO the 
specialization should be enabled, and its <tt>operator()</tt> should return the same value as <tt>hash_value</tt>.
</p>

<p><i>[2022-01-15; Daniel provides wording]</i></p>


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

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

<blockquote>
<pre>
#include &lt;compare&gt; <i>// see 17.11.1 <a href="https://wg21.link/compare.syn">[compare.syn]</a></i>

namespace std::filesystem {
  <i>// 29.12.6 <a href="https://wg21.link/fs.class.path">[fs.class.path]</a>, paths</i>
  class path;

  <i>// 29.12.6.8 <a href="https://wg21.link/fs.path.nonmember">[fs.path.nonmember]</a>, path non-member functions</i>
  void swap(path&amp; lhs, path&amp; rhs) noexcept;
  size_t hash_value(const path&amp; p) noexcept;

  [&hellip;]
}

<ins><i>// [fs.path.hash], hash support</i>
namespace std {
  template&lt;class T&gt; struct hash;
  template&lt;&gt; struct hash&lt;filesystem::path&gt;;
}
</ins>
</pre>
</blockquote>
</li>

<li><p>Following subclause 29.12.6.8 <a href="https://wg21.link/fs.path.nonmember">[fs.path.nonmember]</a>, introduce a new subclause [fs.path.hash], as indicated:</p>

<blockquote>
<p>
<ins><b>29.12.6.? Hash support [fs.path.hash]</b></ins>
</p>
<pre>
<ins>template&lt;&gt; struct hash&lt;filesystem::path&gt;;</ins>
</pre>
<blockquote>
<p>
<ins>-?- For an object <tt>p</tt> of type <tt>filesystem::path</tt>, <tt>hash&lt;filesystem::path&gt;()(p)</tt> 
shall evaluate to the same result as <tt>hash_value(p)</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2022-01-18; Daniel improves wording based on reflector discussion feedback]</i></p>


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

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

<blockquote>
<pre>
#include &lt;compare&gt; <i>// see 17.11.1 <a href="https://wg21.link/compare.syn">[compare.syn]</a></i>

namespace std::filesystem {
  <i>// 29.12.6 <a href="https://wg21.link/fs.class.path">[fs.class.path]</a>, paths</i>
  class path;

  <i>// 29.12.6.8 <a href="https://wg21.link/fs.path.nonmember">[fs.path.nonmember]</a>, path non-member functions</i>
  void swap(path&amp; lhs, path&amp; rhs) noexcept;
  size_t hash_value(const path&amp; p) noexcept;

  [&hellip;]
}

<ins><i>// [fs.path.hash], hash support</i>
namespace std {
  template&lt;class T&gt; struct hash;
  template&lt;&gt; struct hash&lt;filesystem::path&gt;;
}
</ins>
</pre>
</blockquote>
</li>

<li><p>Following subclause 29.12.6.8 <a href="https://wg21.link/fs.path.nonmember">[fs.path.nonmember]</a>, introduce a new subclause [fs.path.hash], as indicated:</p>

<blockquote>
<p>
<ins><b>29.12.6.? Hash support [fs.path.hash]</b></ins>
</p>
<pre>
<ins>template&lt;&gt; struct hash&lt;filesystem::path&gt;;</ins>
</pre>
<blockquote>
<p>
<ins>-?- For an object <tt>p</tt> of type <tt>filesystem::path</tt>, <tt>hash&lt;filesystem::path&gt;()(p)</tt> 
evaluates to the same result as <tt>filesystem::hash_value(p)</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3660" href="https://cplusplus.github.io/LWG/lwg-active.html#3660">3660</a>. <tt>iterator_traits&lt;common_iterator&gt;::pointer</tt> should conform to &sect;[iterator.traits]</h3>
<p><b>Section:</b> 23.5.4.2 <a href="https://wg21.link/common.iter.types">[common.iter.types]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2022-01-20 <b>Last modified:</b> 2022-01-30</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
23.3.2.3 <a href="https://wg21.link/iterator.traits">[iterator.traits]</a>/1 says:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
[&hellip;] In addition, the types
</p>
<blockquote><pre>
iterator_traits&lt;I&gt;::pointer
iterator_traits&lt;I&gt;::reference
</pre></blockquote>
<p>
shall be defined as the iterator's pointer and reference types; that is, for an iterator object <tt>a</tt> of class
type, the same type as <tt>decltype(a.operator-&gt;())</tt> and <tt>decltype(*a)</tt>, respectively. The type 
<tt>iterator_traits&lt;I&gt;::pointer</tt> shall be <tt>void</tt> for an iterator of class type <tt>I</tt> 
that does not support <tt>operator-&gt;</tt>. [&hellip;]
</p>
</blockquote>
<p>
23.5.4.2 <a href="https://wg21.link/common.iter.types">[common.iter.types]</a>/1 slightly contradicts this:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
The nested <i>typedef-name</i>s of the specialization of <tt>iterator_traits</tt> for 
<tt>common_iterator&lt;I, S&gt;</tt> are defined as follows.
</p>
<ol style="list-style-type:none">
<li><p>[&hellip;]</p></li>
<li><p>(1.3) &mdash; If the expression <tt>a.operator-&gt;()</tt> is well-formed, where <tt>a</tt> is an lvalue of 
type <tt>const common_iterator&lt;I, S&gt;</tt>, then <tt>pointer</tt> denotes the type of that expression. Otherwise, 
<tt>pointer</tt> denotes <tt>void</tt>.</p></li>
</ol>
</blockquote>
<p>
"The type of <tt>a.operator-&gt;()</tt>" is not necessarily the same as <tt>decltype(a.operator-&gt;())</tt>: 
when the expression is an lvalue or xvalue of type <tt>T</tt>, "the type of <tt>a.operator-&gt;()</tt>" is <tt>T</tt> 
but <tt>decltype(a.operator-&gt;())</tt> is either <tt>T&amp;</tt> or <tt>T&amp;&amp;</tt>. An implementation 
therefore cannot conform to the requirements of both cited paragraphs for some specializations of <tt>common_iterator</tt>.
<p/>
The most likely explanation for this contradiction is that the writer of the phrase 
"type of <tt>a.operator-&gt;()</tt>" was not cognizant of the difference in meaning and intended to actually write 
<tt>decltype(a.operator-&gt;())</tt>.
</p>

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

<blockquote class="note">
<p>
[<i>Drafting Note:</i> The wording change below includes an additional drive-by fix that ensures that the last
sentence "Otherwise, <tt>pointer</tt> denotes <tt>void</tt>" cannot be misinterpreted (due to the leading "If") 
to apply also for a situation when the outcome of the expression <tt>a.operator-&gt;()</tt> for a non-<tt>const</tt> 
<tt>common_iterator&lt;I, S&gt;</tt> is reflected upon.] 
</p>
</blockquote>


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

<blockquote>
<p>
-1- The nested <i>typedef-name</i>s of the specialization of <tt>iterator_traits</tt> for 
<tt>common_iterator&lt;I, S&gt;</tt> are defined as follows.
</p>
<ol style="list-style-type:none">
<li><p>[&hellip;]</p></li>
<li><p>(1.3) &mdash; <ins>Let <tt>a</tt> denote an lvalue of type <tt>const common_iterator&lt;I, 
S&gt;</tt>.</ins> If the expression <tt>a.operator-&gt;()</tt> is well-formed, <del>where <tt>a</tt> 
is an lvalue of type <tt>const common_iterator&lt;I, S&gt;</tt>,</del> then <tt>pointer</tt> denotes 
<ins><tt>decltype(a.operator-&gt;())</tt></ins><del>the type of that expression</del>. Otherwise, 
<tt>pointer</tt> denotes <tt>void</tt>.</p></li>
</ol>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3661" href="https://cplusplus.github.io/LWG/lwg-active.html#3661">3661</a>. <tt>constinit atomic&lt;shared_ptr&lt;T&gt;&gt; a(nullptr);</tt> should work</h3>
<p><b>Section:</b> 31.8.7.2 <a href="https://wg21.link/util.smartptr.atomic.shared">[util.smartptr.atomic.shared]</a> <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2022-01-21 <b>Last modified:</b> 2022-01-30</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p>
All the following are valid except for the last line:
</p>
<blockquote>
<pre>
constinit int i1{};
constinit std::atomic&lt;int&gt; a1{};
constinit int i2{0};
constinit std::atomic&lt;int&gt; a2{0};
constinit std::shared_ptr&lt;int&gt; i3{};
constinit std::atomic&lt;std::shared_ptr&lt;int&gt;&gt; a3{};
constinit std::shared_ptr&lt;int&gt; i4{nullptr};
constinit std::atomic&lt;std::shared_ptr&lt;int&gt;&gt; a4{nullptr}; <span style="color:red;font-weight:bolder">// error</span>
</pre>
</blockquote>
<p>
The initializer for <tt>a4</tt> will create a <tt>shared_ptr&lt;int&gt;</tt> temporary (using the same constructor 
as <tt>i4</tt>) but then try to use <tt>atomic(shared_ptr&lt;int&gt;)</tt> which is not <tt>constexpr</tt>.
<p/>
This is an unnecessary inconsistency in the API for <tt>atomic&lt;shared_ptr&lt;T&gt;&gt;</tt> that can 
easily be fixed. The proposed resolution has been implemented in libstdc++.
<p/>
There is no need to also change <tt>atomic&lt;weak_ptr&lt;T&gt;&gt;</tt> because <tt>weak_ptr</tt> doesn't have a 
constructor taking <tt>nullptr</tt>.
</p>

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

<ol>
<li><p>Modify 31.8.7.2 <a href="https://wg21.link/util.smartptr.atomic.shared">[util.smartptr.atomic.shared]</a>, class template partial specialization 
<tt>atomic&lt;shared_ptr&lt;T&gt;&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
constexpr atomic() noexcept;
<ins>constexpr atomic(nullptr_t) noexcept : atomic() { }</ins>
atomic(shared_ptr&lt;T&gt; desired) noexcept;
atomic(const atomic&amp;) = delete;
void operator=(const atomic&amp;) = delete;
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





</body>
</html>
