Merge branch 'cplusplus:master' into tk/misc-priorities

tomaszkam · web-flow · commit 580e5147957f · 2025-10-23T12:52:21.000+02:00
diff --git a/bin/set_priority.sh b/bin/set_priority.sh
@@ -47,7 +47,15 @@ then
   sed -i -e '/^<issue /s/ status=".*">$/ status="Tentatively Ready">/' $xml
   bin/add_note.sh $issue "Reflector poll" - <<< "Set status to Tentatively Ready after $votes votes in favour during reflector poll."
 
-  do_commit=$([[ $3 == --commit ]] && echo yes)
+  do_commit=$([[ $3 == --commit ]] && echo Ready)
+
+elif [[ $priority = NAD ]]
+then
+
+  sed -i -e '/^<issue /s/ status=".*">$/ status="Tentatively NAD">/' $xml
+  bin/add_note.sh $issue "Reflector poll. Status &rarr; Tentatively NAD "
+
+  do_commit=$([[ $3 == --commit ]] && echo NAD)
 
 else
 
@@ -64,7 +72,7 @@ then
   bin/add_note.sh $issue -
 fi
 
-if [[ $priority = 0 ]] && [[ $do_commit == yes ]]
+if [[ $do_commit != no ]]
 then
-  git commit -m "Set $issue to Tentatively Ready" $xml
+  git commit -m "Set $issue to Tentatively $do_commit" $xml
 fi
diff --git a/xml/issue4166.xml b/xml/issue4166.xml
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4166" status="New">
+<issue num="4166" status="Tentatively Ready">
 <title>`concat_view::end()` should be more constrained in order to support noncopyable iterators</title>
 <section><sref ref="[range.concat.view]"/></section>
 <submitter>Yaito Kakeyama &amp; Nana Sakisaka</submitter>
@@ -96,6 +96,12 @@ if constexpr (<ins>(semiregular&lt;iterator_t&lt;<i>maybe-const</i>&lt;<i>is-con
 </superseded>
 
 <note>2025-03-05; Hewill Kang provides improved wording</note>
+
+<note>2025-10-23; Reflector poll.</note>
+<p>
+Set status to Tentatively Ready after seven votes in favour during reflector poll.
+</p>
+
 </discussion>
 
 <resolution>
diff --git a/xml/issue4171.xml b/xml/issue4171.xml
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4171" status="New">
+<issue num="4171" status="Tentatively NAD">
 <title>P2609R3 breaks code that uses `views::zip` and <tt>get&lt;T&gt;</tt></title>
 <section><sref ref="[indirectcallable.indirectinvocable]"/></section>
 <submitter>S. B. Tam</submitter>
@@ -39,6 +39,13 @@ an explicit return type to `fun`.
 <p/>
 Did LWG foresee this impact of <paper num="P2609R3"/>? Could P2609R3 be reverted to unbreak this code pattern?
 </p>
+
+<note>2025-10-23; Reflector poll; Status changed: New &rarr; Tentatively NAD.</note>
+<p>
+The range concepts are over-constrained by design, and `indirect_unary_invocable`
+always required invocability with `iter_value_t`. The P2609 changes enforced this 
+requirement properly for iterators returning proxy references, including `zip_iterator`.
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4220.xml b/xml/issue4220.xml
@@ -8,7 +8,7 @@
 </section>
 <submitter>Hewill Kang</submitter>
 <date>06 Mar 2025</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -38,6 +38,15 @@ The proposed resolution preserves the inner range's original qualifiers, which i
 <code>cache_latest_view</code> stores the reference when it is a prvalue.
 The same goes for <code>join_with_view</code>.
 </p>
+
+<note>2025-10-23; Reflector poll.</note>
+<p>
+Set priority to 3 after reflector poll.
+</p>
+<p>
+Lot of NAD votes. This type satisfies, but does not model
+range.
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4271.xml b/xml/issue4271.xml
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4271" status="New">
+<issue num="4271" status="Tentatively NAD">
 <title>Caching range views claim amortized amortized &#x1d4aa;(1) runtime
 complexity for algorithms that are in fact &#x1d4aa;(n)</title>
 <section>
@@ -42,6 +42,17 @@ views (such as hypothetical non-caching variants of the affected views)
 that were previously considered invalid will become valid with these
 changes.
 </p>
+
+<note>2025-10-23; Reflector poll; Status changed: New &rarr; Tentatively NAD.</note>
+<p>
+Relaxing complexity of `ranges::begin`/`ranges::end` is design change,
+and not direction we want to pursue.
+<p>
+</p>
+The "amortized constant" are not quite right words to describe
+intended requirements. A rework preserving the intent of current wording
+would be welcomed.
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4307.xml b/xml/issue4307.xml
@@ -15,7 +15,7 @@ in <code>&lt;ranges&gt;</code></title>
 </section>
 <submitter>Hewill Kang</submitter>
 <date>28 Jul 2025</date>
-<priority>99</priority>
+<priority>4</priority>
 
 <discussion>
 <p>
@@ -36,6 +36,15 @@ which would also allow newly introduced adapters or other library features to ta
 Note that since some of these simplifications change the order in which the concepts are spelled, they may not be
 purely editorial.
 </p>
+
+<note>2025-10-23; Reflector poll.</note>
+<p>
+Set priority to 4 after reflector poll.
+</p>
+<p>
+Use of exposition-only concepts is not necessary improving readability
+or produced error messages.
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4337.xml b/xml/issue4337.xml
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4337" status="New">
+<issue num="4337" status="Tentatively NAD">
 <title><code>co_await change_coroutine_scheduler(s)</code> requires assignable</title>
 <section><sref ref="[task.promise]"/></section>
 <submitter>Dietmar Kühl</submitter>
@@ -17,6 +17,11 @@ The problem is that <code>std::exchange(x, v)</code> expects
 <code>x</code> to be assignable from <code>v</code> but there is
 no requirement for scheduler to be assignable.
 </p>
+
+<note>2025-10-23; Reflector poll. Status &rarr; Tentatively NAD .</note>
+<p>
+"`scheduler` requires `copyable` which requires assignment."
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4389.xml b/xml/issue4389.xml
@@ -1,12 +1,12 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4389" status="New">
+<issue num="4389" status="SG9">
 <title>`ranges::for_each` possibly behaves differently from range-based `for`</title>
 <section><sref ref="[range.range]"/></section>
 <submitter>Jiang An</submitter>
 <date>28 Sep 2025</date>
-<priority>99</priority>
+<priority>2</priority>
 
 <discussion>
 <p>
@@ -29,6 +29,13 @@ implementation to tell whether a class has member `begin/end` but the correspond
 call is ill-formed with C++20 core language rules, and such determination is critical for 
 eliminating the semantic differences between `ranges::for_each` and range-for.
 </p>
+
+<note>2025-10-23; Reflector poll; Status changed: New &rarr; SG9 and P2.</note>
+<p>
+This is certainly evoluationary question and should go to LEWG/SG9.
+It would disallow having unrelated begin/end members, where the range
+interface is provided by hidden friends instead of those members.
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4401.xml b/xml/issue4401.xml
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4401" status="New">
+<issue num="4401" status="LEWG">
 <title>`join_view` should be `sized_range` when applied to ranges of `simd::vec`</title>
 <section>
 <sref ref="[range.join.view]"/>
@@ -10,7 +10,7 @@
 </section>
 <submitter>Hewill Kang</submitter>
 <date>02 Oct 2025</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -33,6 +33,15 @@ In <code>&lt;ranges&gt;</code>, we use the <code><i>tiny-range</i></code> concep
 to consider types that can obtain static sizes specifically, and `simd::vec` 
 seems to be a good fit.
 </p>
+
+<note>2025-10-23; Reflector poll; Status changed: New &rarr; LEWG and P3.</note>
+<p>
+Introducting statically sized ranges and handling them in views, should be
+handle as a paper.
+</p>
+<p>
+The proposed change is also relevant to fixed-size <tt>span</tt>.
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4405.xml b/xml/issue4405.xml
@@ -8,7 +8,7 @@
 </section>
 <submitter>Hewill Kang</submitter>
 <date>05 Oct 2025</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -32,6 +32,16 @@ Given that we intend to reject object slicing for both `default_accessor` and
 `aligned_accessor`, there seems no reason not to reject this invalid pointer 
 arithmetic for `mdspan`.
 </p>
+
+<note>2025-10-23; Reflector poll.</note>
+<p>
+Set priority to 3 after reflector poll.
+</p>
+<p>
+Even if `data_handle_type` is a pointer to `value_type`, this does not mean
+that it points to contiguous range of `value_type` objects. Accessor may
+provide different access parttern.
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4415.xml b/xml/issue4415.xml
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4415" status="New">
+<issue num="4415" status="Tentatively Ready">
 <title>`task::promise_type::uncaught_exception` seems to be misnamed</title>
 <section><sref ref="[task.promise]"/></section>
 <submitter>Jiang An</submitter>
@@ -20,6 +20,11 @@ In <paper num="P3552R3"/>, `unhandled_exception` was discussed, but the wording
 the status of `uncaught_exception` in the zombie name list ([tab:zombie.names.std]). 
 Perhaps `unhandled_exception` is the correct function name.
 </p>
+
+<note>2025-10-23; Reflector poll.</note>
+<p>
+Set status to Tentatively Ready after five votes in favour during reflector poll.
+</p>
 </discussion>
 
 <resolution>
diff --git a/xml/issue4422.xml b/xml/issue4422.xml
@@ -6,7 +6,7 @@
 <section><sref ref="[meta.reflection.access.context]"/></section>
 <submitter>Jakub Jelinek</submitter>
 <date>20 Oct 2025</date>
-<priority>99</priority>
+<priority>2</priority>
 
 <discussion>
 <p>
@@ -15,6 +15,17 @@ objects, which would make it a consteval-only type. But we don't actually
 specify any members, so nothing in the current specification says you can't
 persist one until runtime.
 </p>
+
+<note>2025-10-23; Reflector poll. Adjust proposed wording.</note>
+<p>
+Set priority to 2 after reflector poll.
+</p>
+<p>
+Reflector discussion requested that 'non-aggregate' and 'consteval-only' both
+be put in paragraph 3, adjacent to 'structural'.
+Also added a drive-by editorial change to paragraph 1.
+</p>
+
 </discussion>
 
 <resolution>
@@ -28,11 +39,38 @@ This wording is relative to <paper num="N5014"/>.
 
 <blockquote>
 <p>-1-
-The access_context class is a non-aggregate<ins>, consteval-only</ins> type
-that represents a namespace, class, or function from which queries pertaining
+The <ins>class</ins> `access_context`
+<del>class is a non-aggregate type that</del>
+represents a namespace, class, or function from which queries pertaining
 to access rules may be performed, as well as the designating class
 (<sref ref="[class.access.base]"/>), if any.
 </p>
+<p>-2-
+An `access_context` has an associated scope and designating class.
+<blockquote>
+<pre>namespace std::meta {
+  struct access_context {
+    access_context() = delete;
+
+    consteval info scope() const;
+    consteval info designating_class() const;
+
+    static consteval access_context current() noexcept;
+    static consteval access_context unprivileged() noexcept;
+    static consteval access_context unchecked() noexcept;
+    consteval access_context via(info cls) const;
+  };
+}</pre>
+</blockquote>
+</p>
+<p>-3-
+`access_context` is a structural<ins>, consteval-only, non-aggregate</ins> type.
+Two values `ac1` and `ac2` of type `access_context` are
+template-argument-equivalent (<sref ref="[temp.type]"/>) if
+`ac1.scope()` and `ac2.scope()` are template-argument-equivalent
+and `ac1.designating_class()` and `ac2.designating_class()` are
+template-argument-equivalent.
+</p>
 </blockquote>
 </li>
 </ol>
