Set priorities based on reflector polls

Author: jwakely

xml/issue4109.xml

@@ -6,7 +6,7 @@
 <section><sref ref="[rand.req.genl]"/></section>
 <submitter>Peter Dimov</submitter>
 <date>25 May 2024</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -60,6 +60,31 @@ and (1.6) to corresponding <i>extended floating point</i> types and <i>extended
 or to the minimum make these extended types conditionally-supported with implementation-defined 
 semantics (A word of power that is used at several places).
 </p>
+
+<note>2025-10-21; Reflector poll.</note>
+<p>
+Set priority to 3 after reflector poll.
+</p>
+<p>
+"The only benefit of making it UB is allowing it as an extension."
+</p>
+<p>
+"Does anybody actually want to support a BigInt as an extension?
+If not, non-integral types should be ill-formed and integral types
+not in the list should be conditionally-supported."
+</p>
+<p>
+"I'd like extended arithmetic types to work in general,
+it's useful for writing generic math libraries to be able to
+generate random numbers of any arithmetic type that the implementation
+provides, including short integers and all floating-point types."
+</p>
+<p>
+"Can have overflows here, differences between whether `char` is signed or
+unsigned lead to subtle bugs. Most users are better off picking `int` or
+`unsigned int` (which is what they get from integral promotions anyway)
+and just using values that are in range for their intended destination type."
+</p>
 </discussion>
 
 <resolution>

xml/issue4221.xml

@@ -8,7 +8,7 @@
 </section>
 <submitter>Hewill Kang</submitter>
 <date>06 Mar 2025</date>
-<priority>99</priority>
+<priority>2</priority>
 
 <discussion>
 <p>
@@ -50,6 +50,15 @@ int main() {
 Although such type might be relatively rare, it does reflect an inconsistency in the general usage of formatting
 ranges, which do not support all valid ranges.
 </p>
+
+<note>2025-10-21; Reflector poll.</note>
+<p>
+Set priority to 2 after reflector poll.
+</p>
+<p>
+The majority voted NAD, because the range shown in the issue is nonsensical.
+But enough people voted P2 that we should not close it without more discussion.
+</p>
 </discussion>
 
 <resolution>

xml/issue4273.xml

@@ -8,7 +8,7 @@
 </section>
 <submitter>Jiang An</submitter>
 <date>03 Jun 2025</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -19,6 +19,22 @@ which possibly enables more desired usages.
 Currently, libc++ makes these types non-movable, which is arguable undesired per the decision made in 
 <paper num="P3136R1"/>.
 </p>
+
+<note>2025-10-21; Reflector poll.</note>
+<p>
+Set priority to 3 after reflector poll.
+</p>
+<p>
+"Not seeing the point of this change. For code dealing with generic policies,
+it shouldn't be constructing new objects of the policy type (there could be
+implementation-defined policies, or ones added in future standards, which
+are not default-constructible). For code using a specific policy, just using
+the named variable is strictly less typing than constructing the type.
+Maybe NAD or LEWG."
+"Making them tag types helps e.g. <paper num="P3481"/> where we have to
+store execution policies, and in <paper num="P2500"/>."
+"Don't you want copy constructible, not default constructible?"
+</p>
 </discussion>
 
 <resolution>

xml/issue4277.xml

@@ -8,7 +8,7 @@
 </section>
 <submitter>Jan Schultke</submitter>
 <date>08 Jun 2025</date>
-<priority>99</priority>
+<priority>4</priority>
 
 <discussion>
 <p>
@@ -29,6 +29,18 @@ The <i>Remarks</i> specifications in <sref ref="[alg.min.max]"/> providing exemp
 <sref ref="[algorithms.requirements]"/> paragraph 15 suggest that even function templates not 
 accepting iterators are considered algorithms.
 </p>
+
+<note>2025-10-21; Reflector poll.</note>
+<p>
+Set priority to 4 after reflector poll.
+</p>
+<p>
+"NAD, I don't think people are confused about what an algorithm is."
+</p>
+<p>
+"I'd rather the fix would define 'algorithm', as even the Note below
+the change uses that term."
+</p>
 </discussion>
 
 <resolution>

xml/issue4284.xml

@@ -1,14 +1,14 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4284" status="New">
+<issue num="4284" status="LEWG">
 <title>Integer-class types should be formattable</title>
 <section>
 <sref ref="[format.formatter.spec]"/>
 </section>
 <submitter>Jiang An</submitter>
 <date>27 Jun 2025</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -66,6 +66,19 @@ This wording is relative to <paper num="N5008"/>.
 </superseded>
 
 <note>2025-09-18; Jiang An improves wording</note>
+
+<note>2025-10-21; Reflector poll. Status changed: NEW &rarr; LEWG.</note>
+<p>
+Set priority to 3 after reflector poll. Send to LEWG.
+</p>
+<p>
+"Which additional operations integer-class types should be required to support
+is a design question.
+Why `format` but not iostreams? What about `to_chars`/`from_chars`?
+All the stuff in <code>&lt;bit&gt;</code>? <code>&lt;utility&gt;</code>?
+<code>&lt;cmath&gt;</code>?
+You can show examples using any of these and claim 'uncertainty and inconsistency'."
+</p>
 </discussion>
 
 <resolution>

xml/issue4350.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="4350" status="New">
+<issue num="4350" status="LEWG">
 <title>Should flat adaptors use `insert_range` when available?</title>
 <section>
 <sref ref="[flat.map]"/>
@@ -29,12 +29,12 @@ with those names must behave as expected, but we already require that for
 `std::queue`.
 </p>
 
-<note>2025-10-21; Reflector poll.</note>
+<note>2025-10-21; Reflector poll. Status changed: New &rarr; LEWG.</note>
 <p>
 Set priority to 2 after reflector poll.
 </p>
 <p>
-Use <tt>append_range</tt> to be consitient with other adapters.
+Use <tt>append_range</tt> to be consistent with other adapters.
 Send to LEWG for confirmation.
 </p>
 </discussion>