Remaining issue updates from 2026-08-28 LWG telecon

xml/issue3628.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="3628" status="New">
+<issue num="3628" status="Ready">
 <title>"<i>Effects:</i> Equivalent to:" and uninitialized memory algorithms</title>
 <section><sref ref="[specialized.algorithms]"/></section>
 <submitter>Jiang An</submitter>
@@ -42,6 +42,8 @@ but not actual core-language constraints."
 <p>I believe that a careful reading of the existing wording already shows that "Equivalent to:" has
 no effect of the sort claimed. But since that appears to be a common misinterpretation,
 this wording adds a note to put it to rest.</p>
+
+<note>2026-08-28 LWG telecon; Status changed: New &rarr; Ready.</note>
 </discussion>
 
 <resolution>

xml/issue3832.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="3832" status="New">
+<issue num="3832" status="Ready">
 <title>Missing change for <tt>element_view::<i>iterator</i></tt> in LWG 3798</title>
 <section><sref ref="[range.elements.iterator]"/></section>
 <submitter>Jiang An</submitter>
@@ -10,9 +10,9 @@
 
 <discussion>
 <p>
-In LWG <iref ref="3798"/> (voted into WP in November 2022), iterator types of several range adaptors may have 
-<tt>forward_iterator_tag</tt> or stronger iterator tag types as their <tt>iterator_category</tt> type when 
-their <tt>operator*</tt> returns rvalue references. However, the proposed resolution missed the similar change 
+In LWG <iref ref="3798"/> (voted into WP in November 2022), iterator types of several range adaptors may have
+<tt>forward_iterator_tag</tt> or stronger iterator tag types as their <tt>iterator_category</tt> type when
+their <tt>operator*</tt> returns rvalue references. However, the proposed resolution missed the similar change
 for <tt>element_view::<i>iterator</i></tt>.
 </p>
 
@@ -36,14 +36,14 @@ This wording is relative to <paper num="N4917"/>.
 
 <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: Let <tt>C</tt> 
+-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: Let <tt>C</tt>
 denote the type <tt>iterator_traits&lt;iterator_t&lt;<i>Base</i>&gt;&gt;::iterator_category</tt>.
 </p>
 <ol style="list-style-type: none">
-<li><p>(2.1) &mdash; If <tt>std::get&lt;N&gt;(*<i>current_</i>)</tt> is a<del>n</del> <ins>p</ins>rvalue, 
+<li><p>(2.1) &mdash; If <tt>std::get&lt;N&gt;(*<i>current_</i>)</tt> is a<del>n</del> <ins>p</ins>rvalue,
 <tt>iterator_category</tt> denotes <tt>input_iterator_tag</tt>.</p></li>
-<li><p>(2.2) &mdash; Otherwise, if <tt>C</tt> models <tt>derived_from&lt;random_access_iterator_tag&gt;</tt>, 
+<li><p>(2.2) &mdash; Otherwise, if <tt>C</tt> models <tt>derived_from&lt;random_access_iterator_tag&gt;</tt>,
 <tt>iterator_category</tt> denotes <tt>random_access_iterator_tag</tt>.</p></li>
 <li><p>(2.3) &mdash; Otherwise, <tt>iterator_category</tt> denotes <tt>C</tt>.</p></li>
 </ol>
@@ -55,7 +55,7 @@ denote the type <tt>iterator_traits&lt;iterator_t&lt;<i>Base</i>&gt;&gt;::iterat
 
 <note>2023-01-22; Jiang An comments and provides improved wording</note>
 <p>
-The old proposed resolution was incorrect. I think the correct criteria could be that determined from the return type of 
+The old proposed resolution was incorrect. I think the correct criteria could be that determined from the return type of
 <tt><i>get-element</i></tt>.
 </p>
 
@@ -69,16 +69,16 @@ This wording is relative to <paper num="N4928"/>.
 
 <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: Let <tt>C</tt> 
+-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: Let <tt>C</tt>
 denote the type <tt>iterator_traits&lt;iterator_t&lt;<i>Base</i>&gt;&gt;::iterator_category</tt>.
 </p>
 <ol style="list-style-type: none">
-<li><p>(2.1) &mdash; If <ins><tt>range_reference_t&lt;<i>Base</i>&gt;</tt> is a reference type and</ins> 
-<tt>std::get&lt;N&gt;(*<i>current_</i>)</tt> is a<del>n</del> <ins>p</ins>rvalue <ins>or neither 
-<tt>range_reference_t&lt;<i>Base</i>&gt;</tt> nor <tt>tuple_element_t&lt;N, range_reference_t&lt;<i>Base</i>&gt;</tt> 
+<li><p>(2.1) &mdash; If <ins><tt>range_reference_t&lt;<i>Base</i>&gt;</tt> is a reference type and</ins>
+<tt>std::get&lt;N&gt;(*<i>current_</i>)</tt> is a<del>n</del> <ins>p</ins>rvalue <ins>or neither
+<tt>range_reference_t&lt;<i>Base</i>&gt;</tt> nor <tt>tuple_element_t&lt;N, range_reference_t&lt;<i>Base</i>&gt;</tt>
 is a reference type</ins>, <tt>iterator_category</tt> denotes <tt>input_iterator_tag</tt>.</p></li>
-<li><p>(2.2) &mdash; Otherwise, if <tt>C</tt> models <tt>derived_from&lt;random_access_iterator_tag&gt;</tt>, 
+<li><p>(2.2) &mdash; Otherwise, if <tt>C</tt> models <tt>derived_from&lt;random_access_iterator_tag&gt;</tt>,
 <tt>iterator_category</tt> denotes <tt>random_access_iterator_tag</tt>.</p></li>
 <li><p>(2.3) &mdash; Otherwise, <tt>iterator_category</tt> denotes <tt>C</tt>.</p></li>
 </ol>
@@ -89,6 +89,9 @@ is a reference type</ins>, <tt>iterator_category</tt> denotes <tt>input_iterator
 </superseded>
 
 <note>2024-07-08; Hewill Kang provides improved wording</note>
+
+<note>2026-08-28 LWG telecon; Status changed: New &rarr; Ready.</note>
+
 </discussion>
 
 <resolution>
@@ -101,14 +104,14 @@ This wording is relative to <paper num="N4986"/>.
 
 <blockquote>
 <p>
--2- The member <i>typedef-name</i> <code>iterator_category</code> is defined if and only if <code><i>Base</i></code> 
-models <code>forward_range</code>. In that case, <code>iterator_category</code> is defined as follows: Let <code>C</code> 
+-2- The member <i>typedef-name</i> <code>iterator_category</code> is defined if and only if <code><i>Base</i></code>
+models <code>forward_range</code>. In that case, <code>iterator_category</code> is defined as follows: Let <code>C</code>
 denote the type <code>iterator_traits&lt;iterator_t&lt;<i>Base</i>&gt;&gt;::iterator_category</code>.
 </p>
 <ol style="list-style-type: none">
-<li><p>(2.1) &mdash; If <del><code>std::get&lt;N&gt;(*<i>current_</i>)</code></del><ins><tt>is_reference_v&lt;decltype(<i>get-element</i>(<i>current_</i>))&gt;</tt></ins> 
+<li><p>(2.1) &mdash; If <del><code>std::get&lt;N&gt;(*<i>current_</i>)</code></del><ins><tt>is_reference_v&lt;decltype(<i>get-element</i>(<i>current_</i>))&gt;</tt></ins>
 is <del>an rvalue</del><ins><tt>false</tt></ins>, <code>iterator_category</code> denotes <code>input_iterator_tag</code>.</p></li>
-<li><p>(2.2) &mdash; Otherwise, if <code>C</code> models <code>derived_from&lt;random_access_iterator_tag&gt;</code>, 
+<li><p>(2.2) &mdash; Otherwise, if <code>C</code> models <code>derived_from&lt;random_access_iterator_tag&gt;</code>,
 <code>iterator_category</code> denotes <code>random_access_iterator_tag</code>.</p></li>
 <li><p>(2.3) &mdash; Otherwise, <code>iterator_category</code> denotes <code>C</code>.</p></li>
 </ol>

xml/issue3889.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="3889" status="New">
+<issue num="3889" status="Ready">
 <title><tt>std::(ranges::)destroy_at</tt> should destroy array elements in the decreasing index order</title>
 <section><sref ref="[specialized.destroy]"/></section>
 <submitter>Jiang An</submitter>
@@ -10,9 +10,9 @@
 
 <discussion>
 <p>
-Currently, <tt>std::(ranges::)destroy_at</tt> is specified to destroy array elements in the increasing index order 
-(<sref ref="[specialized.destroy]"/>/1.1), which is inconsistent with the decreasing order specified in the core language 
-(<sref ref="[class.dtor]"/>/13) and the order for arrays created by <tt>std::make_shared</tt> and 
+Currently, <tt>std::(ranges::)destroy_at</tt> is specified to destroy array elements in the increasing index order
+(<sref ref="[specialized.destroy]"/>/1.1), which is inconsistent with the decreasing order specified in the core language
+(<sref ref="[class.dtor]"/>/13) and the order for arrays created by <tt>std::make_shared</tt> and
 <tt>std::allocate_shared</tt> (mandated by LWG <iref ref="3005"/>).
 </p>
 
@@ -54,12 +54,12 @@ namespace ranges {
 <note>2023-02-26; Daniel comments and provides alternative wording</note>
 <p>
 The suggested fix indeed corrects an inconsistency, but also implies a silent behaviour change at runtime, since at least MSVC STL and
-libstdc++ implement the array destruction order as specified (others not tested). 
+libstdc++ implement the array destruction order as specified (others not tested).
 The below wording therefore suggests to introduce a specific feature macro for this, so that user code can potentially react on this,
-regardless of potential vendor API breakage hesitations. 
-The natural feature macro to increase would be that which introduced the specific array destruction behavior of <tt>destroy_at</tt>, 
-which was <paper num="P0896R4"/>, and which introduced <tt>__cpp_lib_ranges</tt>, on the other hand the specification change affects 
-both the <tt>std::ranges</tt> and the <tt>std</tt> forms of <tt>destroy_at</tt>, so it seems plausible to suggest a new, specific feature 
+regardless of potential vendor API breakage hesitations.
+The natural feature macro to increase would be that which introduced the specific array destruction behavior of <tt>destroy_at</tt>,
+which was <paper num="P0896R4"/>, and which introduced <tt>__cpp_lib_ranges</tt>, on the other hand the specification change affects
+both the <tt>std::ranges</tt> and the <tt>std</tt> forms of <tt>destroy_at</tt>, so it seems plausible to suggest a new, specific feature
 macro for both <tt>destroy_at</tt> function templates. This is what the proposed wording does.
 <p/>
 LWG should clarify whether an entry to <sref ref="[diff.cpp20]"/> should be added as well.
@@ -70,6 +70,8 @@ LWG should clarify whether an entry to <sref ref="[diff.cpp20]"/> should be adde
 Set priority to 3 after reflector poll.
 </p>
 
+<note>2026-08-28 LWG telecon; Status changed: New &rarr; Ready.</note>
+<p> The chairs will give LEWG a heads-up that we are making this change.</p>
 </discussion>
 
 <resolution>

xml/issue4094.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4094" status="New">
+<issue num="4094" status="NAD">
 <title><tt>ranges::fold_<i>meow</i></tt> is overconstrained</title>
 <section><sref ref="[alg.fold]"/></section>
 <submitter>Hewill Kang</submitter>
@@ -10,14 +10,14 @@
 
 <discussion>
 <p>
-The two <tt>convertible_to</tt> constraints required by <tt>ranges::fold_<i>meow</i></tt> mainly 
-check whether the decayed result type of the binary operator can be constructed by both the invoke type 
+The two <tt>convertible_to</tt> constraints required by <tt>ranges::fold_<i>meow</i></tt> mainly
+check whether the decayed result type of the binary operator can be constructed by both the invoke type
 and the initial value type.
 <p/>
-However, using <tt>constructible_from</tt> seems more appropriate here because we don't need to care whether 
+However, using <tt>constructible_from</tt> seems more appropriate here because we don't need to care whether
 the two types can be converted implicitly and explicitly.
-Taking <tt>string</tt> and <tt>string_view</tt> as examples, the former can only be explicitly constructed by 
-the latter and can be assigned by the latter, which makes <tt>ranges::fold_<i>meow</i></tt> unable to fold 
+Taking <tt>string</tt> and <tt>string_view</tt> as examples, the former can only be explicitly constructed by
+the latter and can be assigned by the latter, which makes <tt>ranges::fold_<i>meow</i></tt> unable to fold
 ranges whose elements are of type <tt>string</tt> with an initial value of type <tt>string_view</tt>:
 </p>
 <blockquote><pre>
@@ -26,8 +26,8 @@ string_view init{"d"};
 auto result = ranges::fold_right(vs, init, plus{}); // <span style="color:red;font-weight:bolder">still ill-formed after <paper num="P2591R5"/> as the constraint is not satisfied</span>
 </pre></blockquote>
 <p>
-In addition, the two <tt>movable</tt> constraints in the function signature seem to be too strict as well since we 
-only need to check that the decayed result type and the initial type can be move-constructible (one for returned by 
+In addition, the two <tt>movable</tt> constraints in the function signature seem to be too strict as well since we
+only need to check that the decayed result type and the initial type can be move-constructible (one for returned by
 elidable move and one for move into other overloads) instead of whether they can be move-assignable.
 </p>
 
@@ -42,6 +42,8 @@ it would also allow <code>vector&lt;string&gt;</code>/<code>int</code>,
 which is much less so."
 </p>
 
+<note>2026-08-28 LWG telecon; NAD for the reasons discussed above. Status changed: New &rarr; NAD.</note>
+
 </discussion>
 
 <resolution>
@@ -135,7 +137,7 @@ return {std::move(first), std::move(accum)};
 </pre></blockquote>
 <p>
 -8- <i>Remarks</i>: The return type is <tt>fold_left_with_iter_result&lt;I, U&gt;</tt>
-for the first overload and <tt>fold_left_with_iter_result&lt;borrowed_iterator_t&lt;R&gt;, U&gt;</tt> 
+for the first overload and <tt>fold_left_with_iter_result&lt;borrowed_iterator_t&lt;R&gt;, U&gt;</tt>
 for the second overload.
 </p>
 </blockquote>

xml/issue4116.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4116" status="New">
+<issue num="4116" status="Ready">
 <title><tt>enumerate_view::<i>iterator</i></tt> and <tt>cartesian_product_view::<i>iterator</i></tt> should not
     always provide <tt>iterator_category</tt></title>
 <section><sref ref="[range.enumerate.iterator]"/><sref ref="[range.cartesian.iterator]"/></section>
@@ -22,6 +22,8 @@ Set priority to 3 after reflector poll.
 <p>
 Six votes for Tentatively Ready, but not unanimous.
 </p>
+
+<note>2026-08-28 LWG telecon; Status changed: New &rarr; Ready.</note>
 </discussion>
 
 <resolution>

xml/issue4120.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4120" status="New">
+<issue num="4120" status="NAD">
 <title><code>move_iterator</code> should provide <code>iterator_category</code> only when it models
 <code>forward_iterator</code></title>
 <section><sref ref="[move.iterator]"/></section>
@@ -29,6 +29,8 @@ Should have a note here indicating that the rule is broken for good reason,
 and that you should do as the Standard says and not as the Standard does."
 </p>
 
+<note>2026-08-28 LWG telecon; NAD for the reasons discussed above. Status changed: New &rarr; NAD.</note>
+
 </discussion>
 
 <resolution>