From 94200042990257cd0dc76f5004182f83cf7ebf2e Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Sat, 29 Aug 2026 15:26:18 -0500 Subject: [PATCH 1/6] Move 3628 to ready --- xml/issue3628.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xml/issue3628.xml b/xml/issue3628.xml index f322da8cd3..d42cb48260 100644 --- a/xml/issue3628.xml +++ b/xml/issue3628.xml @@ -1,7 +1,7 @@ - + "<i>Effects:</i> Equivalent to:" and uninitialized memory algorithms
Jiang An @@ -42,6 +42,8 @@ but not actual core-language constraints."

I believe that a careful reading of the existing wording already shows that "Equivalent to:" has no effect of the sort claimed. But since that appears to be a common misinterpretation, this wording adds a note to put it to rest.

+ +2026-08-28 LWG telecon; Status changed: New → Ready. From 78bee09cc35e496876e35b93c7b6bc8a4351e7d0 Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Sat, 29 Aug 2026 15:27:27 -0500 Subject: [PATCH 2/6] Move 4094 to NAD --- xml/issue4094.xml | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/xml/issue4094.xml b/xml/issue4094.xml index 31a2cbc0fe..2b1b9a9d9e 100644 --- a/xml/issue4094.xml +++ b/xml/issue4094.xml @@ -1,7 +1,7 @@ - + <tt>ranges::fold_<i>meow</i></tt> is overconstrained
Hewill Kang @@ -10,14 +10,14 @@

-The two convertible_to constraints required by ranges::fold_meow mainly -check whether the decayed result type of the binary operator can be constructed by both the invoke type +The two convertible_to constraints required by ranges::fold_meow mainly +check whether the decayed result type of the binary operator can be constructed by both the invoke type and the initial value type.

-However, using constructible_from seems more appropriate here because we don't need to care whether +However, using constructible_from seems more appropriate here because we don't need to care whether the two types can be converted implicitly and explicitly. -Taking string and string_view as examples, the former can only be explicitly constructed by -the latter and can be assigned by the latter, which makes ranges::fold_meow unable to fold +Taking string and string_view as examples, the former can only be explicitly constructed by +the latter and can be assigned by the latter, which makes ranges::fold_meow unable to fold ranges whose elements are of type string with an initial value of type string_view: 

@@ -26,8 +26,8 @@ string_view init{"d"};
 auto result = ranges::fold_right(vs, init, plus{}); // still ill-formed after  as the constraint is not satisfied

-In addition, the two movable constraints in the function signature seem to be too strict as well since we -only need to check that the decayed result type and the initial type can be move-constructible (one for returned by +In addition, the two movable constraints in the function signature seem to be too strict as well since we +only need to check that the decayed result type and the initial type can be move-constructible (one for returned by elidable move and one for move into other overloads) instead of whether they can be move-assignable.

@@ -42,6 +42,8 @@ it would also allow vector<string>/int, which is much less so."

+2026-08-28 LWG telecon; NAD for the reasons discussed above. Status changed: New → NAD. + @@ -135,7 +137,7 @@ return {std::move(first), std::move(accum)};

-8- Remarks: The return type is fold_left_with_iter_result<I, U> -for the first overload and fold_left_with_iter_result<borrowed_iterator_t<R>, U> +for the first overload and fold_left_with_iter_result<borrowed_iterator_t<R>, U> for the second overload.

From 32279379080ad23f2b13aefae1ee9f89767c2672 Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Sat, 29 Aug 2026 15:28:02 -0500 Subject: [PATCH 3/6] Move 4116 to ready --- xml/issue4116.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xml/issue4116.xml b/xml/issue4116.xml index c9e4a8d3f6..667f7a75ea 100644 --- a/xml/issue4116.xml +++ b/xml/issue4116.xml @@ -1,7 +1,7 @@ - + <tt>enumerate_view::<i>iterator</i></tt> and <tt>cartesian_product_view::<i>iterator</i></tt> should not always provide <tt>iterator_category</tt>
@@ -22,6 +22,8 @@ Set priority to 3 after reflector poll.

Six votes for Tentatively Ready, but not unanimous.

+ +2026-08-28 LWG telecon; Status changed: New → Ready. From 81a949d1d13f32576d775c6aecccfce16558c7fe Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Sat, 29 Aug 2026 15:28:34 -0500 Subject: [PATCH 4/6] Move 4120 to NAD --- xml/issue4120.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xml/issue4120.xml b/xml/issue4120.xml index 54a1925eb9..1674e877d2 100644 --- a/xml/issue4120.xml +++ b/xml/issue4120.xml @@ -1,7 +1,7 @@ - + <code>move_iterator</code> should provide <code>iterator_category</code> only when it models <code>forward_iterator</code>
@@ -29,6 +29,8 @@ Should have a note here indicating that the rule is broken for good reason, and that you should do as the Standard says and not as the Standard does."

+2026-08-28 LWG telecon; NAD for the reasons discussed above. Status changed: New → NAD. + From 4ec95ab7826042b78eb02a463b537c569352cddf Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Sat, 29 Aug 2026 15:29:57 -0500 Subject: [PATCH 5/6] Move 3832 to ready --- xml/issue3832.xml | 41 ++++++++++++++++++++++------------------- 1 file changed, 22 insertions(+), 19 deletions(-) diff --git a/xml/issue3832.xml b/xml/issue3832.xml index 2995b0aaf4..203e730eee 100644 --- a/xml/issue3832.xml +++ b/xml/issue3832.xml @@ -1,7 +1,7 @@ - + Missing change for <tt>element_view::<i>iterator</i></tt> in LWG 3798
Jiang An @@ -10,9 +10,9 @@

-In LWG (voted into WP in November 2022), iterator types of several range adaptors may have -forward_iterator_tag or stronger iterator tag types as their iterator_category type when -their operator* returns rvalue references. However, the proposed resolution missed the similar change +In LWG (voted into WP in November 2022), iterator types of several range adaptors may have +forward_iterator_tag or stronger iterator tag types as their iterator_category type when +their operator* returns rvalue references. However, the proposed resolution missed the similar change for element_view::iterator.

@@ -36,14 +36,14 @@ This wording is relative to .

--2- The member typedef-name iterator_category is defined if and only if Base -models forward_range. In that case, iterator_category is defined as follows: Let C +-2- The member typedef-name iterator_category is defined if and only if Base +models forward_range. In that case, iterator_category is defined as follows: Let C denote the type iterator_traits<iterator_t<Base>>::iterator_category.

    -

  1. (2.1) — If std::get<N>(*current_) is an prvalue, +

  2. (2.1) — If std::get<N>(*current_) is an prvalue, iterator_category denotes input_iterator_tag.

    3. -

  3. (2.2) — Otherwise, if C models derived_from<random_access_iterator_tag>, +

  4. (2.2) — Otherwise, if C models derived_from<random_access_iterator_tag>, iterator_category denotes random_access_iterator_tag.

  5. (2.3) — Otherwise, iterator_category denotes C.

@@ -55,7 +55,7 @@ denote the type iterator_traits<iterator_t<Base>>::iterat 2023-01-22; Jiang An comments and provides improved wording

-The old proposed resolution was incorrect. I think the correct criteria could be that determined from the return type of +The old proposed resolution was incorrect. I think the correct criteria could be that determined from the return type of get-element.

@@ -69,16 +69,16 @@ This wording is relative to .

--2- The member typedef-name iterator_category is defined if and only if Base -models forward_range. In that case, iterator_category is defined as follows: Let C +-2- The member typedef-name iterator_category is defined if and only if Base +models forward_range. In that case, iterator_category is defined as follows: Let C denote the type iterator_traits<iterator_t<Base>>::iterator_category.

    -

  1. (2.1) — If range_reference_t<Base> is a reference type and -std::get<N>(*current_) is an prvalue or neither -range_reference_t<Base> nor tuple_element_t<N, range_reference_t<Base> +

  2. (2.1) — If range_reference_t<Base> is a reference type and +std::get<N>(*current_) is an prvalue or neither +range_reference_t<Base> nor tuple_element_t<N, range_reference_t<Base> is a reference type, iterator_category denotes input_iterator_tag.

    3. -

  3. (2.2) — Otherwise, if C models derived_from<random_access_iterator_tag>, +

  4. (2.2) — Otherwise, if C models derived_from<random_access_iterator_tag>, iterator_category denotes random_access_iterator_tag.

  5. (2.3) — Otherwise, iterator_category denotes C.

@@ -89,6 +89,9 @@ is a reference type, iterator_category denotes input_iterator 2024-07-08; Hewill Kang provides improved wording + +2026-08-28 LWG telecon; Status changed: New → Ready. + @@ -101,14 +104,14 @@ This wording is relative to .

--2- The member typedef-name iterator_category is defined if and only if Base -models forward_range. In that case, iterator_category is defined as follows: Let C +-2- The member typedef-name iterator_category is defined if and only if Base +models forward_range. In that case, iterator_category is defined as follows: Let C denote the type iterator_traits<iterator_t<Base>>::iterator_category.

    -

  1. (2.1) — If std::get<N>(*current_)is_reference_v<decltype(get-element(current_))> +

  2. (2.1) — If std::get<N>(*current_)is_reference_v<decltype(get-element(current_))> is an rvaluefalse, iterator_category denotes input_iterator_tag.

    3. -

  3. (2.2) — Otherwise, if C models derived_from<random_access_iterator_tag>, +

  4. (2.2) — Otherwise, if C models derived_from<random_access_iterator_tag>, iterator_category denotes random_access_iterator_tag.

  5. (2.3) — Otherwise, iterator_category denotes C.

From b6b0cd66074d1cdb92f1221de2cdd1d2fe9cc247 Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Sat, 29 Aug 2026 15:31:34 -0500 Subject: [PATCH 6/6] Move 3889 to Ready --- xml/issue3889.xml | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/xml/issue3889.xml b/xml/issue3889.xml index faa43df67c..6410f8ea8d 100644 --- a/xml/issue3889.xml +++ b/xml/issue3889.xml @@ -1,7 +1,7 @@ - + <tt>std::(ranges::)destroy_at</tt> should destroy array elements in the decreasing index order
Jiang An @@ -10,9 +10,9 @@

-Currently, std::(ranges::)destroy_at is specified to destroy array elements in the increasing index order -(/1.1), which is inconsistent with the decreasing order specified in the core language -(/13) and the order for arrays created by std::make_shared and +Currently, std::(ranges::)destroy_at is specified to destroy array elements in the increasing index order +(/1.1), which is inconsistent with the decreasing order specified in the core language +(/13) and the order for arrays created by std::make_shared and std::allocate_shared (mandated by LWG ).

@@ -54,12 +54,12 @@ namespace ranges { 2023-02-26; Daniel comments and provides alternative wording

The suggested fix indeed corrects an inconsistency, but also implies a silent behaviour change at runtime, since at least MSVC STL and -libstdc++ implement the array destruction order as specified (others not tested). +libstdc++ implement the array destruction order as specified (others not tested). The below wording therefore suggests to introduce a specific feature macro for this, so that user code can potentially react on this, -regardless of potential vendor API breakage hesitations. -The natural feature macro to increase would be that which introduced the specific array destruction behavior of destroy_at, -which was , and which introduced __cpp_lib_ranges, on the other hand the specification change affects -both the std::ranges and the std forms of destroy_at, so it seems plausible to suggest a new, specific feature +regardless of potential vendor API breakage hesitations. +The natural feature macro to increase would be that which introduced the specific array destruction behavior of destroy_at, +which was , and which introduced __cpp_lib_ranges, on the other hand the specification change affects +both the std::ranges and the std forms of destroy_at, so it seems plausible to suggest a new, specific feature macro for both destroy_at function templates. This is what the proposed wording does.

LWG should clarify whether an entry to should be added as well. @@ -70,6 +70,8 @@ LWG should clarify whether an entry to should be adde Set priority to 3 after reflector poll.

+2026-08-28 LWG telecon; Status changed: New → Ready. +

The chairs will give LEWG a heads-up that we are making this change.