Skip to content

Commit 90f3235

Browse files
jwakelyjwakely
committed
Set some priorities after reflector polls
1 parent e0355e1 commit 90f3235

File tree

7 files changed

+89
-8
lines changed

7 files changed

+89
-8
lines changed

‎xml/issue4138.xml‎

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
<section><sref ref="[meta.const.eval]"/></section>
77
<submitter>Corentin</submitter>
88
<date>09 Aug 2024</date>
9-
<priority>99</priority>
9+
<priority>3</priority>
1010

1111
<discussion>
1212
<blockquote><pre>
@@ -20,6 +20,21 @@ of a non-object does not make sense, and the lack of constraint makes the
2020
implementation and use of that function and underlying built-in more
2121
convoluted than necessary.
2222
</p>
23+
24+
<note>2025-10-14; Reflector poll</note>
25+
<p>
26+
Set priority to 3 after reflector poll.
27+
</p>
28+
<p>
29+
"What about `void*`, should that be allowed? The compiler should know which
30+
union member the `void*` came from, as this is only using during constant
31+
evaluation."
32+
</p>
33+
<p>
34+
"NAD, a function could have its lifetime constrained by a dynamic loader,
35+
so it seems wrong to assume that taling of function lifetimes makes no sense."
36+
</p>
37+
2338
</discussion>
2439

2540
<resolution>

‎xml/issue4267.xml‎

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
<section><sref ref="[tuple.cnstr]"/></section>
77
<submitter>Jiang An</submitter>
88
<date>24 May 2025</date>
9-
<priority>99</priority>
9+
<priority>3</priority>
1010

1111
<discussion>
1212
<p>
@@ -19,6 +19,16 @@ deleted according to <sref ref="[tuple.cnstr]"/>/33. However, it's confusing tha
1919
sometimes non-deleted when the tuple contains a reference, while there are hard errors in an instantiation
2020
instead.
2121
</p>
22+
23+
<note>2025-10-14; Reflector poll</note>
24+
<p>
25+
Set priority to 3 after reflector poll.
26+
</p>
27+
<p>
28+
"There is a defect, but the right fix is to just define uses-allocator
29+
construction of references as equivalent to normal construction."
30+
</p>
31+
2232
</discussion>
2333

2434
<resolution>

‎xml/issue4279.xml‎

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
</section>
99
<submitter>Jonathan Wakely</submitter>
1010
<date>16 Jun 2025</date>
11-
<priority>99</priority>
11+
<priority>4</priority>
1212

1313
<discussion>
1414
<p>
@@ -25,6 +25,15 @@ The part about `!exists(p)` not being an error could definitely be a <i>Recommen
2525
Referring to "secondary storage" might need to be phrased differently to be normative (maybe with a note
2626
clarifying that the normative wording is referring to "secondary storage").
2727
</p>
28+
29+
<note>2025-10-14; Reflector poll</note>
30+
<p>
31+
Set priority to 4 after reflector poll.
32+
</p>
33+
<p>
34+
Could the `!exists(p)` part be implementation-defined?
35+
</p>
36+
2837
</discussion>
2938

3039
<resolution>

‎xml/issue4313.xml‎

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
</section>
99
<submitter>Jiang An</submitter>
1010
<date>07 Aug 2025</date>
11-
<priority>99</priority>
11+
<priority>3</priority>
1212

1313
<discussion>
1414
<p>
@@ -104,6 +104,12 @@ of behavior, is more likely to fix bugs than to create them. It is exactly this
104104
restatement of uses-allocator construction for `pair` that I hoped to fix with P0591, even
105105
though I missed `tuple` in my exposition.
106106
</p>
107+
108+
<note>2025-10-14; Reflector poll</note>
109+
<p>
110+
Set priority to 3 after reflector poll.
111+
</p>
112+
107113
</discussion>
108114

109115
<resolution>

‎xml/issue4319.xml‎

Lines changed: 17 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
</section>
99
<submitter>Tomasz Kamiński</submitter>
1010
<date>19 Aug 2025</date>
11-
<priority>99</priority>
11+
<priority>3</priority>
1212

1313
<discussion>
1414
<p>
@@ -60,6 +60,22 @@ The suggested changes by this issue have been
6060
<a href="https://gcc.gnu.org/pipermail/libstdc++/2025-August/062992.html">implemented in libstdc++</a>
6161
for `bind_front/bind_back`.
6262
</p>
63+
64+
<note>2025-10-14; Reflector poll</note>
65+
<p>
66+
Set priority to 3 after reflector poll.
67+
</p>
68+
<p>
69+
The submitter prefers to withdraw the issue because the proposed resolution
70+
changes the result of overload resolution in unspecified ways. It would
71+
no longer be specified whether `bind_front(F{})({})` works or not,
72+
as it would depend whether `bind_front(F{})` returned a call wrapper or the
73+
`F` object without wrapping. It would also make the effects of
74+
`bind_front(S{})(0, 0)` unspecified if the call could resolve to either
75+
`S::operator()(long, long)` or `S::operator()(int, void*)`, depending on
76+
whether `bind_front(S{})` returns a call wrapper or the `S` object.
77+
</p>
78+
6379
</discussion>
6480

6581
<resolution>

‎xml/issue4325.xml‎

Lines changed: 20 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@
99
</section>
1010
<submitter>Hewill Kang</submitter>
1111
<date>24 Aug 2025</date>
12-
<priority>99</priority>
12+
<priority>2</priority>
1313

1414
<discussion>
1515
<p>
@@ -38,6 +38,25 @@ This makes `operator==` not SFINAE-friendly for incomplete types, which defeats
3838
Also, checking `noexcept(*lhs == *rhs)` seems insufficient because the result of `*lhs == *rhs`
3939
might still throw during conversion to `bool`.
4040
</p>
41+
<p>
42+
We could add a note similar to <sref ref="[refwrap.general]"/>.
43+
</p>
44+
45+
<note>2025-10-14; Reflector poll</note>
46+
<p>
47+
Set priority to 2 after reflector poll.
48+
</p>
49+
<p>
50+
Even if we don't want to support incomplete types, we still need to fix
51+
the noexcept-specifier to consider whether the conversion to `bool` throws,
52+
e.g. <tt>noexcept(noexcept(<ins>bool(</ins>*lhs == *rhs<ins>)</ins>))</tt>.
53+
</p>
54+
<p>
55+
"The proposed resolution may result in the noexcept operator giving different
56+
results when evaluated in different translation units where the type `T` of
57+
`indirect` was incomplete or not. Ill-formed seems safer than inconsistent."
58+
</p>
59+
4160
</discussion>
4261

4362
<resolution>

‎xml/issue4400.xml‎

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
<section><sref ref="[time.format]"/></section>
77
<submitter>Tomasz Kamiński</submitter>
88
<date>02 Oct 2025</date>
9-
<priority>99</priority>
9+
<priority>3</priority>
1010

1111
<discussion>
1212
<p>
@@ -30,7 +30,7 @@ template&lt;class Rep, class Period&gt;
3030
= is_arithmetic_v&lt;Rep&gt;;
3131
</pre></blockquote>
3232
<p>
33-
Furtheremore, for all types that are currently templated on `Duration` (`hh_mm_ss`, `sys_time`,
33+
Furthermore, for all types that are currently templated on `Duration` (`hh_mm_ss`, `sys_time`,
3434
`local_time`, etc.), we `enable_nonlocking_formatter_optimization` by default. This again does
3535
not take into consideration the arithmetic operations performed as duration. We should specialize
3636
`enable_nonlocking_formatter_optimization` for all of them to be enabled if
@@ -49,6 +49,12 @@ Durations with there custom representation types.
4949
The proposed wording has recently been implemented in
5050
<a href="https://gcc.gnu.org/pipermail/libstdc++/2025-October/063758.html">gcc's libstdc++</a>.
5151
</p>
52+
53+
<note>2025-10-14; Reflector poll</note>
54+
<p>
55+
Set priority to 3 after reflector poll.
56+
</p>
57+
5258
</discussion>
5359

5460
<resolution>

0 commit comments

Comments
 (0)