Set some priorities based on reflector polls

Author: jwakely

xml/issue4160.xml

@@ -6,7 +6,7 @@
 <section><sref ref="[futures.task.general]"/></section>
 <submitter>Casey Carter</submitter>
 <date>28 Sep 2024</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -21,6 +21,15 @@ Presumably the design intent &mdash; which the implementers all inferred &mdash;
 should be ill-formed when `get_future` is not instantiable. The spec should say so explicitly rather than 
 relying on the fact that one of the basis operations is unusable.
 </p>
+
+<note>2025-02-07; Reflector poll</note>
+<p>
+Set priority to 3 after reflector poll.
+</p>
+<p>
+"Shouldn't it be ill-formed only if instantiated?"
+</p>
+
 </discussion>
 
 <resolution>

xml/issue4182.xml

@@ -6,7 +6,7 @@
 <section><sref ref="[support.types.nullptr]"/></section>
 <submitter>Janet Cobb</submitter>
 <date>09 Dec 2024</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -19,6 +19,13 @@ Together, these imply that `#define NULL (::std::unreachable(), nullptr)` is a c
 a prvalue of type `std::nullptr_t`, so it is a null pointer constant. This makes it implementation-defined whether 
 any program that evaluates `NULL` has undefined behavior.
 </p>
+
+<note>2025-02-07; Reflector poll</note>
+<p>
+Set priority to 3 after reflector poll.
+</p>
+<p>"I'd very much like to see `nullptr` added to the footnote."</p>
+
 </discussion>
 
 <resolution>

xml/issue4193.xml

@@ -6,7 +6,7 @@
 <section><sref ref="[time.zone.db]"/></section>
 <submitter>S. B. Tam</submitter>
 <date>16 Jan 2025</date>
-<priority>99</priority>
+<priority>3</priority>
 
 <discussion>
 <p>
@@ -40,6 +40,18 @@ Does it mean that "concurrent calls do not introduce data races", or does it add
 total order on these operations? In either case, it should be specified clearly.
 </p>
 
+
+<note>2025-02-07; Reflector poll</note>
+<p>
+Set priority to 3 after reflector poll.
+</p>
+<p>
+"We're missing a guarantee that `reload_tzdb()` strongly happens before
+a call to `get_tzdb_list().front()` that retrieves a newly added element.
+Otherwise accessing any `time_zone` obtained from `get_tzdb_list().front()`
+could race with the call to `reload_tzdb()` that writes the front of the list."
+</p>
+
 </discussion>
 
 <resolution>