Skip to content

Set priorities for 4405,4271,4171,4307,4389,4220,4401,4116 (ranges) #496

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jwakely merged 8 commits into from
Oct 23, 2025
Merged

Set priorities for 4405,4271,4171,4307,4389,4220,4401,4116 (ranges) #496

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
bf35271
Set 4405 to P3
tomaszkam Oct 23, 2025
a01bd43
Set 4271 to Tentatively NAD
tomaszkam Oct 23, 2025
d4702d4
Set 4171 to Tentatively NAD
tomaszkam Oct 23, 2025
fc953ca
Set 4307 to P4
tomaszkam Oct 23, 2025
97f6ee3
Set 4389 to SG9/P2
tomaszkam Oct 23, 2025
b1b7d87
Set 4220 to P3
tomaszkam Oct 23, 2025
b6fc4f5
Set 4401 to LEWG/P3
tomaszkam Oct 23, 2025
40cc9c2
Set 4166 to Tentatively Ready
tomaszkam Oct 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion xml/issue4166.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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>
Expand Down Expand Up @@ -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>
Expand Down
9 changes: 8 additions & 1 deletion xml/issue4171.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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>
Expand Down Expand Up @@ -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 pool; 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>
Expand Down
11 changes: 10 additions & 1 deletion xml/issue4220.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
</section>
<submitter>Hewill Kang</submitter>
<date>06 Mar 2025</date>
<priority>99</priority>
<priority>3</priority>

<discussion>
<p>
Expand Down Expand Up @@ -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>
Expand Down
13 changes: 12 additions & 1 deletion xml/issue4271.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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>
Expand Down Expand Up @@ -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>
Expand Down
11 changes: 10 additions & 1 deletion xml/issue4307.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand All @@ -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>
Expand Down
11 changes: 9 additions & 2 deletions xml/issue4389.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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>
Expand All @@ -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>
Expand Down
13 changes: 11 additions & 2 deletions xml/issue4401.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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]"/>
Expand All @@ -10,7 +10,7 @@
</section>
<submitter>Hewill Kang</submitter>
<date>02 Oct 2025</date>
<priority>99</priority>
<priority>3</priority>

<discussion>
<p>
Expand All @@ -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>
Expand Down
12 changes: 11 additions & 1 deletion xml/issue4405.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
</section>
<submitter>Hewill Kang</submitter>
<date>05 Oct 2025</date>
<priority>99</priority>
<priority>3</priority>

<discussion>
<p>
Expand All @@ -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>
Expand Down