From 01de7574573f67bde4513c98301a4a4ef24e1bd4 Mon Sep 17 00:00:00 2001 From: github-actions Date: Tue, 14 Nov 2023 21:01:39 +0000 Subject: [PATCH] Automatic update from GitHub Actions workflow --- issue2392.html | 12 +- issue2768.html | 1 - issue2769.html | 1 - issue3102.html | 1 - issue3144.html | 1 - issue3203.html | 13 +- issue3292.html | 1 - issue3302.html | 1 - issue3305.html | 13 +- issue3335.html | 1 - issue3351.html | 1 - issue3369.html | 1 - issue3379.html | 1 - issue3398.html | 1 - issue3423.html | 1 - issue3431.html | 12 +- issue3523.html | 1 - issue3597.html | 1 - issue3610.html | 1 - issue3614.html | 1 - issue3729.html | 1 - issue3748.html | 4 +- issue3749.html | 12 +- issue3768.html | 1 - issue3770.html | 1 - issue3776.html | 2 +- issue3809.html | 12 +- issue3813.html | 1 - issue3860.html | 1 - issue3892.html | 12 +- issue3897.html | 12 +- issue3903.html | 1 - issue3913.html | 3 +- issue3914.html | 1 - issue3946.html | 13 +- issue3947.html | 12 +- issue3948.html | 13 +- issue3949.html | 12 +- issue3951.html | 12 +- issue3953.html | 12 +- issue3957.html | 13 +- issue3965.html | 12 +- issue3970.html | 12 +- issue3973.html | 12 +- issue3974.html | 12 +- issue3976.html | 1 - issue3987.html | 12 +- issue3990.html | 12 +- issue4001.html | 13 +- lwg-active.html | 2850 +--------------------------------- lwg-closed.html | 34 +- lwg-defects.html | 2897 ++++++++++++++++++++++++++++++++++- lwg-immediate.html | 2 +- lwg-index-open.html | 2 +- lwg-index.html | 168 +- lwg-ready.html | 2 +- lwg-status-date.html | 414 +++-- lwg-status.html | 426 +++-- lwg-tentative.html | 2 +- lwg-toc.html | 90 +- lwg-unresolved.html | 11 +- unresolved-index.html | 70 +- unresolved-prioritized.html | 454 +++--- unresolved-status-date.html | 70 +- unresolved-status.html | 70 +- unresolved-toc.html | 58 +- votable-index.html | 254 +-- votable-status-date.html | 204 +-- votable-status.html | 202 +-- votable-toc.html | 200 +-- 70 files changed, 3933 insertions(+), 4850 deletions(-) diff --git a/issue2392.html b/issue2392.html index 0c51e056ed..e1187699a5 100644 --- a/issue2392.html +++ b/issue2392.html @@ -44,13 +44,13 @@
-

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-

2392. "character type" is used but not defined

-

Section: 3.36 [defns.ntcts], 30.3.1.2.1 [locale.category], 31.2.3 [iostreams.limits.pos], 31.7.6.3.1 [ostream.formatted.reqmts], 31.7.6.3.4 [ostream.inserters.character] Status: Voting - Submitter: Jeffrey Yasskin Opened: 2014-06-01 Last modified: 2023-11-07

+

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+

2392. "character type" is used but not defined

+

Section: 3.36 [defns.ntcts], 30.3.1.2.1 [locale.category], 31.2.3 [iostreams.limits.pos], 31.7.6.3.1 [ostream.formatted.reqmts], 31.7.6.3.4 [ostream.inserters.character] Status: WP + Submitter: Jeffrey Yasskin Opened: 2014-06-01 Last modified: 2023-11-13

Priority: 3

-

View all issues with Voting status.

+

View all issues with WP status.

Discussion:

The term "character type" is used in 3.36 [defns.ntcts], 30.3.1.2.1 [locale.category], @@ -117,6 +117,8 @@

2392. "character type" is use given their current position expressed here to eliminate the specification of the affected components as suggested by P2871.

+

[Kona 2023-11-11; Status changed: Voting → WP.]

+

Proposed resolution:

diff --git a/issue2768.html b/issue2768.html index 4886210b05..1bfb60b4c0 100644 --- a/issue2768.html +++ b/issue2768.html @@ -50,7 +50,6 @@

2768. any_cast and Submitter: Casey Carter Opened: 2016-08-27 Last modified: 2017-07-30

Priority: 0

-

View other active issues in [any.nonmembers].

View all other issues in [any.nonmembers].

View all issues with C++17 status.

Discussion:

diff --git a/issue2769.html b/issue2769.html index fcdc389851..20157f349d 100644 --- a/issue2769.html +++ b/issue2769.html @@ -50,7 +50,6 @@

2769. Redundant constSubmitter: Casey Carter Opened: 2016-09-02 Last modified: 2017-07-30

Priority: 0

-

View other active issues in [any.nonmembers].

View all other issues in [any.nonmembers].

View all issues with C++17 status.

Discussion:

diff --git a/issue3102.html b/issue3102.html index c1c68861c3..e6a0058600 100644 --- a/issue3102.html +++ b/issue3102.html @@ -50,7 +50,6 @@

3102. Clarify span itera Submitter: Stephan T. Lavavej Opened: 2018-04-12 Last modified: 2021-02-25

Priority: 0

-

View other active issues in [span.overview].

View all other issues in [span.overview].

View all issues with C++20 status.

Discussion:

diff --git a/issue3144.html b/issue3144.html index d9eac61c5b..73f790d2a6 100644 --- a/issue3144.html +++ b/issue3144.html @@ -50,7 +50,6 @@

3144. span does not Submitter: Louis Dionne Opened: 2018-07-23 Last modified: 2021-02-25

Priority: 0

-

View other active issues in [span.overview].

View all other issues in [span.overview].

View all issues with C++20 status.

Discussion:

diff --git a/issue3203.html b/issue3203.html index 64402d9de4..32191fbfb6 100644 --- a/issue3203.html +++ b/issue3203.html @@ -44,15 +44,14 @@
-

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-

3203. span element access invalidation

-

Section: 24.7.2.2.1 [span.overview] Status: Voting - Submitter: Johel Ernesto Guerrero Peña Opened: 2019-05-04 Last modified: 2023-11-07

+

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+

3203. span element access invalidation

+

Section: 24.7.2.2.1 [span.overview] Status: WP + Submitter: Johel Ernesto Guerrero Peña Opened: 2019-05-04 Last modified: 2023-11-13

Priority: 2

-

View other active issues in [span.overview].

View all other issues in [span.overview].

-

View all issues with Voting status.

+

View all issues with WP status.

Discussion:

span doesn't explicitly point out when its accessed elements are invalidated like string_view @@ -105,6 +104,8 @@

3203. span element a

[2023-06-14 Varna; Move to Ready]

+

[Kona 2023-11-11; Status changed: Voting → WP.]

+

Proposed resolution:

diff --git a/issue3292.html b/issue3292.html index 657e65d936..5a0ab9f1a3 100644 --- a/issue3292.html +++ b/issue3292.html @@ -50,7 +50,6 @@

3292. iota_view is Submitter: Barry Revzin Opened: 2019-09-13 Last modified: 2021-02-25

Priority: Not Prioritized

-

View other active issues in [range.iota.view].

View all other issues in [range.iota.view].

View all issues with C++20 status.

Discussion:

diff --git a/issue3302.html b/issue3302.html index 348265af8d..ff90ab7702 100644 --- a/issue3302.html +++ b/issue3302.html @@ -50,7 +50,6 @@

3302. Range adaptor objects Submitter: Michel Morin Opened: 2019-10-04 Last modified: 2021-02-25

Priority: 1

-

View other active issues in [ranges.syn].

View all other issues in [ranges.syn].

View all issues with C++20 status.

Discussion:

diff --git a/issue3305.html b/issue3305.html index bf15c43385..f3bee5b1e0 100644 --- a/issue3305.html +++ b/issue3305.html @@ -44,15 +44,14 @@
-

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-

3305. any_cast<void>

-

Section: 22.7.5 [any.nonmembers] Status: Voting - Submitter: John Shaw Opened: 2019-10-16 Last modified: 2023-11-07

+

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+

3305. any_cast<void>

+

Section: 22.7.5 [any.nonmembers] Status: WP + Submitter: John Shaw Opened: 2019-10-16 Last modified: 2023-11-13

Priority: 2

-

View other active issues in [any.nonmembers].

View all other issues in [any.nonmembers].

-

View all issues with Voting status.

+

View all issues with WP status.

Discussion:

 any foo;
@@ -110,6 +109,8 @@ 
3305. any_cast<void>
 
 
Poll: 7-0-1

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3335.html b/issue3335.html
index 9e5ac55005..df95319918 100644
--- a/issue3335.html
+++ b/issue3335.html
@@ -50,7 +50,6 @@ 
3335. Resolve C++20 NB comme
  Submitter: United States/Great Britain Opened: 2019-11-08 Last modified: 2021-02-25

 
Priority: 1
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with C++20 status.

 
Discussion:

diff --git a/issue3351.html b/issue3351.html
index 2375bc9b49..b56f7580f7 100644
--- a/issue3351.html
+++ b/issue3351.html
@@ -50,7 +50,6 @@ 
3351. ranges::enable_saf
  Submitter: Jonathan Wakely Opened: 2019-12-05 Last modified: 2021-02-25

 
Priority: 0
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with C++20 status.

 
Discussion:

diff --git a/issue3369.html b/issue3369.html
index 355938c9a5..6758789fbf 100644
--- a/issue3369.html
+++ b/issue3369.html
@@ -50,7 +50,6 @@ 
3369. span's deduct
  Submitter: Stephan T. Lavavej Opened: 2020-01-08 Last modified: 2021-02-25

 
Priority: 0
 

-
View other active issues in [span.overview].

 
View all other issues in [span.overview].

 
View all issues with C++20 status.

 
Discussion:

diff --git a/issue3379.html b/issue3379.html
index fd86c07d2f..86d7975c25 100644
--- a/issue3379.html
+++ b/issue3379.html
@@ -50,7 +50,6 @@ 
3379. "safe" in sev
  Submitter: Casey Carter Opened: 2020-01-21 Last modified: 2021-02-25

 
Priority: 1
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with C++20 status.

 
Discussion:

diff --git a/issue3398.html b/issue3398.html
index 347154fb83..504cdcf5ac 100644
--- a/issue3398.html
+++ b/issue3398.html
@@ -50,7 +50,6 @@ 
3398. tuple_element_tSubmitter: Casey Carter Opened: 2019-02-13 Last modified: 2021-02-25

 
Priority: 0
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with C++20 status.

 
Discussion:

diff --git a/issue3423.html b/issue3423.html
index 004e02db7e..bb9d1da834 100644
--- a/issue3423.html
+++ b/issue3423.html
@@ -50,7 +50,6 @@ 
3423. std::any_cast
  Submitter: Casey Carter Opened: 2020-04-02 Last modified: 2020-09-06

 
Priority: 3
 

-
View other active issues in [any.nonmembers].

 
View all other issues in [any.nonmembers].

 
View all issues with New status.

 
Discussion:

diff --git a/issue3431.html b/issue3431.html
index 144584bbd9..268dd55fd1 100644
--- a/issue3431.html
+++ b/issue3431.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3431. <=> for containers should require three_way_comparable<T> instead of <=>

-
Section: 24.2.2.4 [container.opt.reqmts] Status: Voting
- Submitter: Jonathan Wakely Opened: 2020-04-17 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3431. <=> for containers should require three_way_comparable<T> instead of <=>

+
Section: 24.2.2.4 [container.opt.reqmts] Status: WP
+ Submitter: Jonathan Wakely Opened: 2020-04-17 Last modified: 2023-11-13

 
Priority: 2
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 The precondition for <=> on containers is:
@@ -227,6 +227,8 @@ 
3431. <=> for
 

 
[2023-06-14 Varna; Move to Ready]

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3523.html b/issue3523.html
index 313da97dfd..0ecfeef839 100644
--- a/issue3523.html
+++ b/issue3523.html
@@ -50,7 +50,6 @@ 
3523. iota_view::sent
  Submitter: Tim Song Opened: 2021-02-17 Last modified: 2021-06-07

 
Priority: Not Prioritized
 

-
View other active issues in [range.iota.view].

 
View all other issues in [range.iota.view].

 
View all issues with WP status.

 
Discussion:

diff --git a/issue3597.html b/issue3597.html
index 1f842067df..1f3cf1352c 100644
--- a/issue3597.html
+++ b/issue3597.html
@@ -50,7 +50,6 @@ 
3597. Unsigned integer types
  Submitter: Jiang An Opened: 2021-09-23 Last modified: 2022-11-17

 
Priority: 3
 

-
View other active issues in [range.iota.view].

 
View all other issues in [range.iota.view].

 
View all issues with WP status.

 
Discussion:

diff --git a/issue3610.html b/issue3610.html
index cae502b4e4..70a461de56 100644
--- a/issue3610.html
+++ b/issue3610.html
@@ -50,7 +50,6 @@ 
3610. iota_view::sizeSubmitter: Jiang An Opened: 2021-09-29 Last modified: 2022-02-10

 
Priority: Not Prioritized
 

-
View other active issues in [range.iota.view].

 
View all other issues in [range.iota.view].

 
View all issues with WP status.

 
Discussion:

diff --git a/issue3614.html b/issue3614.html
index df163af31f..a688fc31cd 100644
--- a/issue3614.html
+++ b/issue3614.html
@@ -50,7 +50,6 @@ 
3614. iota_view::sizeSubmitter: Jiang An Opened: 2021-10-01 Last modified: 2021-10-14

 
Priority: 3
 

-
View other active issues in [range.iota.view].

 
View all other issues in [range.iota.view].

 
View all issues with New status.

 
Discussion:

diff --git a/issue3729.html b/issue3729.html
index cd7b8758c9..073537b6f7 100644
--- a/issue3729.html
+++ b/issue3729.html
@@ -50,7 +50,6 @@ 
3729. std::tuple_element_
  Submitter: Jiang An Opened: 2022-06-30 Last modified: 2022-07-08

 
Priority: 4
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with New status.

 
Discussion:

diff --git a/issue3748.html b/issue3748.html
index edb013f58f..d1a7a34906 100644
--- a/issue3748.html
+++ b/issue3748.html
@@ -93,8 +93,8 @@ 
3748. common_iterator
 

 

-This issue shouldn't we voted until a decision for LWG 3749 has been made, because the first part of
-it overlaps with LWG 3749's second part.
+This issue shouldn't we voted until a decision for LWG 3749 has been made, because the first part of
+it overlaps with LWG 3749's second part.
 

 

 
diff --git a/issue3749.html b/issue3749.html
index d2f9b9c3ef..1fe303b9b9 100644
--- a/issue3749.html
+++ b/issue3749.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3749. common_iterator should handle integer-class difference types

-
Section: 25.5.5 [iterators.common] Status: Voting
- Submitter: Hewill Kang Opened: 2022-08-01 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3749. common_iterator should handle integer-class difference types

+
Section: 25.5.5 [iterators.common] Status: WP
+ Submitter: Hewill Kang Opened: 2022-08-01 Last modified: 2023-11-13

 
Priority: 2
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 The partial specialization of iterator_traits for common_iterator is defined in 
@@ -204,6 +204,8 @@ 
3749. common_iterator[2023-06-14 Varna; Move to Ready]

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3768.html b/issue3768.html
index df442861be..12cafb040c 100644
--- a/issue3768.html
+++ b/issue3768.html
@@ -50,7 +50,6 @@ 
3768. possibly-const-r
  Submitter: Hewill Kang Opened: 2022-09-08 Last modified: 2022-11-30

 
Priority: Not Prioritized
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with NAD status.

 
Discussion:

diff --git a/issue3770.html b/issue3770.html
index 27f91a3837..571e61f6d9 100644
--- a/issue3770.html
+++ b/issue3770.html
@@ -50,7 +50,6 @@ 
3770. const_sentinel_tSubmitter: Hewill Kang Opened: 2022-09-05 Last modified: 2022-11-17

 
Priority: 3
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with WP status.

 
Discussion:

diff --git a/issue3776.html b/issue3776.html
index a7c152535c..93ed47acfa 100644
--- a/issue3776.html
+++ b/issue3776.html
@@ -121,7 +121,7 @@ 
3776. Avoid parsing format
 
[Varna 2023-06-16; Status changed: LEWG → NAD.]

 
 

-Resolved differently by LWG 3892.
+Resolved differently by LWG 3892.
 

 
 
diff --git a/issue3809.html b/issue3809.html
index c1cbac190f..cd06199456 100644
--- a/issue3809.html
+++ b/issue3809.html
@@ -44,14 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3809. Is std::subtract_with_carry_engine<uint16_t> supposed to work?

-
Section: 28.5.4.4 [rand.eng.sub] Status: Voting
- Submitter: Jonathan Wakely Opened: 2022-11-02 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3809. Is std::subtract_with_carry_engine<uint16_t> supposed to work?

+
Section: 28.5.4.4 [rand.eng.sub] Status: WP
+ Submitter: Jonathan Wakely Opened: 2022-11-02 Last modified: 2023-11-13

 
Priority: 3
 

 
View all other issues in [rand.eng.sub].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 The standard requires subtract_with_carry_engine<T> to use:
@@ -81,6 +81,8 @@ 
3809. Is std::subtract_wi
 
 
Status to Tentatively Ready after six votes in favour.

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3813.html b/issue3813.html
index a86eeb3346..689f559990 100644
--- a/issue3813.html
+++ b/issue3813.html
@@ -50,7 +50,6 @@ 
3813. std::span<volati
  Submitter: Jiang An Opened: 2022-11-06 Last modified: 2022-11-12

 
Priority: 2
 

-
View other active issues in [span.overview].

 
View all other issues in [span.overview].

 
View all issues with New status.

 
Discussion:

diff --git a/issue3860.html b/issue3860.html
index 1d1d547607..900ebb68b2 100644
--- a/issue3860.html
+++ b/issue3860.html
@@ -50,7 +50,6 @@ 
3860. range_common_refer
  Submitter: Hewill Kang Opened: 2023-01-24 Last modified: 2023-02-13

 
Priority: Not Prioritized
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with WP status.

 
Discussion:

diff --git a/issue3892.html b/issue3892.html
index 055f4c51af..89eb4ddda7 100644
--- a/issue3892.html
+++ b/issue3892.html
@@ -44,14 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3892. Incorrect formatting of nested ranges and tuples

-
Section: 22.14.7.2 [format.range.formatter], 22.14.9 [format.tuple] Status: Voting
- Submitter: Victor Zverovich Opened: 2023-02-20 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3892. Incorrect formatting of nested ranges and tuples

+
Section: 22.14.7.2 [format.range.formatter], 22.14.9 [format.tuple] Status: WP
+ Submitter: Victor Zverovich Opened: 2023-02-20 Last modified: 2023-11-13

 
Priority: 2
 

 
View all other issues in [format.range.formatter].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 formatter specializations for ranges and tuples set debug format for underlying element formatters in their 
@@ -207,6 +207,8 @@ 
3892. Incorrect formatting of
 This would allow resolving LWG 3776 as NAD.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3897.html b/issue3897.html
index b46fdd1f65..563d60a61f 100644
--- a/issue3897.html
+++ b/issue3897.html
@@ -44,14 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3897. inout_ptr will not update raw pointer to 0

-
Section: 20.3.4.3 [inout.ptr.t] Status: Voting
- Submitter: Doug Cook Opened: 2023-02-27 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3897. inout_ptr will not update raw pointer to 0

+
Section: 20.3.4.3 [inout.ptr.t] Status: WP
+ Submitter: Doug Cook Opened: 2023-02-27 Last modified: 2023-11-13

 
Priority: 2
 

 
View all other issues in [inout.ptr.t].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 inout_ptr seems useful for two purposes:
@@ -115,6 +115,8 @@ 
3897. inout_ptr will
 
[Varna 2023-06-16; Move to Ready]

 
 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3903.html b/issue3903.html
index 89e939663a..8848951dd3 100644
--- a/issue3903.html
+++ b/issue3903.html
@@ -50,7 +50,6 @@ 
3903. span destruct
  Submitter: Ben Craig Opened: 2023-03-11 Last modified: 2023-06-19

 
Priority: Not Prioritized
 

-
View other active issues in [span.overview].

 
View all other issues in [span.overview].

 
View all issues with WP status.

 
Discussion:

diff --git a/issue3913.html b/issue3913.html
index 01bac0a1a8..af629b993e 100644
--- a/issue3913.html
+++ b/issue3913.html
@@ -50,7 +50,6 @@ 
3913. ranges::const_ite
  Submitter: Arthur O'Dwyer Opened: 2023-03-28 Last modified: 2023-11-07

 
Priority: 3
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with NAD status.

 
Discussion:

@@ -76,7 +75,7 @@ 
3913. ranges::const_ite
 
[Kona 2023-11-07; SG9]

 
 

-SG9 considered this and noted it's obsolete due to LWG 3946.
+SG9 considered this and noted it's obsolete due to LWG 3946.
 To support this case now would require changing ranges::cbegin
 to add a special case for arrays of unknown bound, which would require a paper.
 

diff --git a/issue3914.html b/issue3914.html
index b8c8da6f89..85a6407091 100644
--- a/issue3914.html
+++ b/issue3914.html
@@ -50,7 +50,6 @@ 
3914. Inconsistent templa
  Submitter: Johel Ernesto Guerrero Peña Opened: 2023-03-30 Last modified: 2023-06-19

 
Priority: Not Prioritized
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

 
View all issues with WP status.

 
Discussion:

diff --git a/issue3946.html b/issue3946.html
index 7c13781948..765a263afc 100644
--- a/issue3946.html
+++ b/issue3946.html
@@ -44,15 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3946. The definition of const_iterator_t should be reworked

-
Section: 26.2 [ranges.syn] Status: Voting
- Submitter: Christopher Di Bella Opened: 2023-06-13 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3946. The definition of const_iterator_t should be reworked

+
Section: 26.2 [ranges.syn] Status: WP
+ Submitter: Christopher Di Bella Opened: 2023-06-13 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 During the reflector discussion of P2836, consensus was reached that const_iterator_t<R> 
@@ -62,6 +61,8 @@ 
3946. The definition of c
 
 
[Varna 2023-06-14; Move to Ready]

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3947.html b/issue3947.html
index 2d0f8b6cf9..245ccd3d8b 100644
--- a/issue3947.html
+++ b/issue3947.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3947. Unexpected constraints on adjacent_transform_view::base()

-
Section: 26.7.27.2 [range.adjacent.transform.view] Status: Voting
- Submitter: Bo Persson Opened: 2023-06-17 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3947. Unexpected constraints on adjacent_transform_view::base()

+
Section: 26.7.27.2 [range.adjacent.transform.view] Status: WP
+ Submitter: Bo Persson Opened: 2023-06-17 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 In section 26.7.27.2 [range.adjacent.transform.view] the class
@@ -76,6 +76,8 @@ 
3947. Unexpected constraints
 Set status to Tentatively Ready after five votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3948.html b/issue3948.html
index f99b9679d6..686996cc5f 100644
--- a/issue3948.html
+++ b/issue3948.html
@@ -44,15 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3948. possibly-const-range and as-const-pointer should be noexcept

-
Section: 26.2 [ranges.syn], 26.3.14 [range.prim.cdata] Status: Voting
- Submitter: Jiang An Opened: 2023-06-20 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3948. possibly-const-range and as-const-pointer should be noexcept

+
Section: 26.2 [ranges.syn], 26.3.14 [range.prim.cdata] Status: WP
+ Submitter: Jiang An Opened: 2023-06-20 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View other active issues in [ranges.syn].

 
View all other issues in [ranges.syn].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 As of P2278R4, several range access CPOs are specified with possibly-const-range 
@@ -68,6 +67,8 @@ 
3948. possibly-const-r
 Set status to Tentatively Ready after five votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3949.html b/issue3949.html
index 6ef27126b4..1eb4a1e6c8 100644
--- a/issue3949.html
+++ b/issue3949.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3949. std::atomic<bool>'s trivial destructor dropped in C++17 spec wording

-
Section: 33.5.8.1 [atomics.types.generic.general] Status: Voting
- Submitter: Jeremy Hurwitz Opened: 2023-06-20 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3949. std::atomic<bool>'s trivial destructor dropped in C++17 spec wording

+
Section: 33.5.8.1 [atomics.types.generic.general] Status: WP
+ Submitter: Jeremy Hurwitz Opened: 2023-06-20 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 std::atomic<bool> was originally required to have a trivial default constructor and a trivial destructor 
@@ -73,6 +73,8 @@ 
3949. std::atomic<bool
 Set status to Tentatively Ready after eight votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3951.html b/issue3951.html
index d9042ae404..78efe531a8 100644
--- a/issue3951.html
+++ b/issue3951.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3951. §[expected.object.swap]: Using value() instead of has_value()

-
Section: 22.8.6.5 [expected.object.swap], 22.8.7.5 [expected.void.swap] Status: Voting
- Submitter: Ben Craig Opened: 2023-06-25 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3951. §[expected.object.swap]: Using value() instead of has_value()

+
Section: 22.8.6.5 [expected.object.swap], 22.8.7.5 [expected.void.swap] Status: WP
+ Submitter: Ben Craig Opened: 2023-06-25 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 22.8.6.5 [expected.object.swap] p2 has the following text in it:
@@ -72,6 +72,8 @@ 
3951. §[expected.object.
 Set status to Tentatively Ready after seven votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3953.html b/issue3953.html
index d6a906473e..3f89ed7c89 100644
--- a/issue3953.html
+++ b/issue3953.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3953. iter_move for common_iterator and counted_iterator should return decltype(auto)

-
Section: 25.5.5.7 [common.iter.cust], 25.5.7.7 [counted.iter.cust] Status: Voting
- Submitter: Hewill Kang Opened: 2023-06-30 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3953. iter_move for common_iterator and counted_iterator should return decltype(auto)

+
Section: 25.5.5.7 [common.iter.cust], 25.5.7.7 [counted.iter.cust] Status: WP
+ Submitter: Hewill Kang Opened: 2023-06-30 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 Although the customized iter_move of both requires the underlying iterator I to be input_iterator, 
@@ -68,6 +68,8 @@ 
3953. iter_move for
 Set status to Tentatively Ready after six votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3957.html b/issue3957.html
index f78dfb388b..d6675bed72 100644
--- a/issue3957.html
+++ b/issue3957.html
@@ -44,15 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3957. §[container.alloc.reqmts] The value category of v should be claimed

-
Section: 24.2.2.5 [container.alloc.reqmts] Status: Voting
- Submitter: jim x Opened: 2023-07-10 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3957. §[container.alloc.reqmts] The value category of v should be claimed

+
Section: 24.2.2.5 [container.alloc.reqmts] Status: WP
+ Submitter: jim x Opened: 2023-07-10 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View other active issues in [container.alloc.reqmts].

 
View all other issues in [container.alloc.reqmts].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 24.2.2.5 [container.alloc.reqmts] p2 says:
@@ -96,6 +95,8 @@ 
3957. §[container.alloc.
 Set status to Tentatively Ready after five votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3965.html b/issue3965.html
index c33d5e2db8..f22a64f4d1 100644
--- a/issue3965.html
+++ b/issue3965.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3965. Incorrect example in [format.string.escaped] p3 for formatting of combining characters

-
Section: 22.14.6.4 [format.string.escaped] Status: Voting
- Submitter: Tom Honermann Opened: 2023-07-31 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3965. Incorrect example in [format.string.escaped] p3 for formatting of combining characters

+
Section: 22.14.6.4 [format.string.escaped] Status: WP
+ Submitter: Tom Honermann Opened: 2023-07-31 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 The C++23 DIS contains the following example in 22.14.6.4 [format.string.escaped] p3. (This example does 
@@ -118,6 +118,8 @@ 
3965. Incorrect example in [f
 Set status to Tentatively Ready after six votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3970.html b/issue3970.html
index 340a0c9478..4f02a0df6e 100644
--- a/issue3970.html
+++ b/issue3970.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3970. §[mdspan.syn] Missing definition of full_extent_t and full_extent

-
Section: 24.7.3.2 [mdspan.syn] Status: Voting
- Submitter: S. B. Tam Opened: 2023-08-16 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3970. §[mdspan.syn] Missing definition of full_extent_t and full_extent

+
Section: 24.7.3.2 [mdspan.syn] Status: WP
+ Submitter: S. B. Tam Opened: 2023-08-16 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 submdspan uses a type called full_extent_t, but there isn't a definition for that type.
@@ -66,6 +66,8 @@ 
3970. §[mdspan.syn] Miss
 Set status to Tentatively Ready after nine votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3973.html b/issue3973.html
index aca9a43ff7..ba8406c47f 100644
--- a/issue3973.html
+++ b/issue3973.html
@@ -44,14 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3973. Monadic operations should be ADL-proof

-
Section: 22.8.6.7 [expected.object.monadic], 22.5.3.7 [optional.monadic] Status: Voting
- Submitter: Jiang An Opened: 2023-08-10 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3973. Monadic operations should be ADL-proof

+
Section: 22.8.6.7 [expected.object.monadic], 22.5.3.7 [optional.monadic] Status: WP
+ Submitter: Jiang An Opened: 2023-08-10 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

 
View all other issues in [expected.object.monadic].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 LWG 3938 switched to use **this to access the value stored in std::expected. 
@@ -78,6 +78,8 @@ 
3973. Monadic operations shou
 Set status to Tentatively Ready after five votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3974.html b/issue3974.html
index 9fe213ae6f..2d813548b7 100644
--- a/issue3974.html
+++ b/issue3974.html
@@ -44,13 +44,13 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3974. mdspan::operator[] should not copy OtherIndexTypes

-
Section: 24.7.3.6.3 [mdspan.mdspan.members] Status: Voting
- Submitter: Casey Carter Opened: 2023-08-12 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3974. mdspan::operator[] should not copy OtherIndexTypes

+
Section: 24.7.3.6.3 [mdspan.mdspan.members] Status: WP
+ Submitter: Casey Carter Opened: 2023-08-12 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 The wording for mdspan's operator[] overloads that accept span and array is in 
@@ -105,6 +105,8 @@ 
3974. mdspan::operator[]<
 Set status to Tentatively Ready after eight votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3976.html b/issue3976.html
index 015fec920c..7ecaeb5b69 100644
--- a/issue3976.html
+++ b/issue3976.html
@@ -50,7 +50,6 @@ 
3976. What does it mean for a
  Submitter: Alisdair Meredith Opened: 2023-08-14 Last modified: 2023-09-17

 
Priority: Not Prioritized
 

-
View other active issues in [container.alloc.reqmts].

 
View all other issues in [container.alloc.reqmts].

 
View all issues with New status.

 
Discussion:

diff --git a/issue3987.html b/issue3987.html
index 716af6a1cd..3e112611c5 100644
--- a/issue3987.html
+++ b/issue3987.html
@@ -44,15 +44,15 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3987. Including <flat_foo> doesn't provide std::begin/end

-
Section: 25.7 [iterator.range] Status: Voting
- Submitter: Hewill Kang Opened: 2023-08-27 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3987. Including <flat_foo> doesn't provide std::begin/end

+
Section: 25.7 [iterator.range] Status: WP
+ Submitter: Hewill Kang Opened: 2023-08-27 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

 
View other active issues in [iterator.range].

 
View all other issues in [iterator.range].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 It seems that 25.7 [iterator.range] should also add <flat_foo> to the list as the 
@@ -65,6 +65,8 @@ 
3987. Including <flat_
 Set status to Tentatively Ready after nine votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue3990.html b/issue3990.html
index a9c8cd2415..ea08c0b6d8 100644
--- a/issue3990.html
+++ b/issue3990.html
@@ -44,14 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
3990. Program-defined specializations of std::tuple and std::variant can't be properly supported

-
Section: 22.4.4 [tuple.tuple], 22.6.3.1 [variant.variant.general] Status: Voting
- Submitter: Jiang An Opened: 2023-08-29 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
3990. Program-defined specializations of std::tuple and std::variant can't be properly supported

+
Section: 22.4.4 [tuple.tuple], 22.6.3.1 [variant.variant.general] Status: WP
+ Submitter: Jiang An Opened: 2023-08-29 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

 
View all other issues in [tuple.tuple].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 Currently, program-defined specializations of std::tuple and std::variant are not explicitly disallowed. 
@@ -68,6 +68,8 @@ 
3990. Program-defined special
 Set status to Tentatively Ready after five votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/issue4001.html b/issue4001.html
index 6bc4faebd4..cfde668771 100644
--- a/issue4001.html
+++ b/issue4001.html
@@ -44,15 +44,14 @@
 
 
 

-
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Voting status.

-
4001. iota_view should provide empty

-
Section: 26.6.4.2 [range.iota.view] Status: Voting
- Submitter: Hewill Kang Opened: 2023-10-27 Last modified: 2023-11-07

+
This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

+
4001. iota_view should provide empty

+
Section: 26.6.4.2 [range.iota.view] Status: WP
+ Submitter: Hewill Kang Opened: 2023-10-27 Last modified: 2023-11-13

 
Priority: Not Prioritized
 

-
View other active issues in [range.iota.view].

 
View all other issues in [range.iota.view].

-
View all issues with Voting status.

+
View all issues with WP status.

 
Discussion:

 

 When iota_view's template parameter is not an integer type and does not model advanceable, 
@@ -88,6 +87,8 @@ 
4001. iota_view shou
 Set status to Tentatively Ready after seven votes in favour during reflector poll.
 

 
+
[Kona 2023-11-11; Status changed: Voting → WP.]

+
 
 
 
Proposed resolution:

diff --git a/lwg-active.html b/lwg-active.html
index 784c4ee473..fbf8f42470 100644
--- a/lwg-active.html
+++ b/lwg-active.html
@@ -50,7 +50,7 @@
 
 
   Date:
-  2023-11-13
+  2023-11-14
 
 
   Project:
@@ -62,7 +62,7 @@
 
 
 
C++ Standard Library Active Issues List (Revision D125)

-
Revised 2023-11-13 at 13:15:08 UTC

+
Revised 2023-11-14 at 21:01:33 UTC

 

   
Reference ISO/IEC IS 14882:2020(E)

   
Also see:

@@ -182,23 +182,23 @@ 
Revision History

 
    
 
  • D125: 2023-06-09 Post-Varna
      
 
    • Summary:
        
-
      • 473 open issues, up by 43.
        • 
-
      • 3021 closed issues, up by 21.
        • 
+
      • 451 open issues, up by 21.
        • 
+
      • 3043 closed issues, up by 43.
        • 
 
      • 35 reassigned issues, down by 1.
        • 
 
      • 3529 issues total, up by 63.
        • 
 
      • 
 
    • Details:
        
-
      • Added the following 14 Voting issues: 3946, 3947, 3948, 3949, 3951, 3953, 3957, 3965, 3970, 3973, 3974, 3987, 3990, 4001.
        • 
 
      • Added the following 4 Ready issues: 3950, 3975, 3984, 3988.
        • 
 
      • Added the following 6 Tentatively NAD issues: 3958, 3980, 3981, 3982, 3996, 4003.
        • 
 
      • Added the following 38 New issues: 3945, 3952, 3954, 3955, 3956, 3959, 3960, 3961, 3962, 3963, 3964, 3966, 3967, 3968, 3969, 3972, 3976, 3977, 3978, 3979, 3983, 3985, 3986, 3989, 3991, 3992, 3993, 3994, 3995, 3997, 3998, 3999, 4000, 4002, 4004, 4005, 4006, 4007.
        • 
 
      • Added the following SG9 issue: 3971.
        • 
-
      • Changed the following 7 issues to Voting (from New): 2392, 3203, 3431, 3749, 3809, 3892, 3897.
        • 
-
      • Changed the following issue to Voting (from Open): 3305.
        • 
+
      • Added the following 14 WP issues: 3946, 3947, 3948, 3949, 3951, 3953, 3957, 3965, 3970, 3973, 3974, 3987, 3990, 4001.
        • 
 
      • Changed the following issue to Ready (from New): 3919.
        • 
 
      • Changed the following issue to Ready (from Open): 3767.
        • 
 
      • Changed the following issue to Open (from New): 3343.
        • 
 
      • Changed the following 17 issues to WP (from Tentatively Ready): 2994, 3884, 3885, 3887, 3893, 3894, 3903, 3904, 3905, 3912, 3914, 3915, 3925, 3927, 3935, 3938, 3940.
        • 
+
      • Changed the following 7 issues to WP (from New): 2392, 3203, 3431, 3749, 3809, 3892, 3897.
        • 
+
      • Changed the following issue to WP (from Open): 3305.
        • 
 
      • Changed the following issue to Resolved (from New): 3861.
        • 
 
      • Changed the following issue to NAD (from New): 2413.
        • 
 
      • Changed the following issue to NAD (from LEWG): 3776.
        • 
@@ -218,7 +218,7 @@ 
        Revision History
        
 
      • Details:
          
 
        • Added the following 16 Tentatively Ready issues: 3884, 3885, 3887, 3893, 3894, 3903, 3904, 3905, 3912, 3914, 3915, 3925, 3927, 3935, 3938, 3940.
          • 
 
        • Added the following 5 Tentatively NAD issues: 3901, 3908, 3909, 3930, 3936.
          • 
-
        • Added the following 52 New issues: 3832, 3835, 3837, 3838, 3845, 3846, 3852, 3854, 3855, 3856, 3861, 3863, 3864, 3873, 3882, 3883, 3886, 3888, 3889, 3890, 3891, 3892, 3895, 3896, 3897, 3898, 3899, 3900, 3902, 3906, 3907, 3910, 3911, 3916, 3917, 3919, 3920, 3921, 3922, 3923, 3924, 3926, 3928, 3929, 3931, 3932, 3933, 3934, 3937, 3939, 3942, 3943.
          • 
+
        • Added the following 52 New issues: 3832, 3835, 3837, 3838, 3845, 3846, 3852, 3854, 3855, 3856, 3861, 3863, 3864, 3873, 3882, 3883, 3886, 3888, 3889, 3890, 3891, 3892, 3895, 3896, 3897, 3898, 3899, 3900, 3902, 3906, 3907, 3910, 3911, 3916, 3917, 3919, 3920, 3921, 3922, 3923, 3924, 3926, 3928, 3929, 3931, 3932, 3933, 3934, 3937, 3939, 3942, 3943.
          • 
 
        • Added the following 2 Open issues: 3840, 3844.
          • 
 
        • Added the following 2 LEWG issues: 3868, 3918.
          • 
 
        • Added the following SG1 issue: 3941.
          • 
@@ -259,7 +259,7 @@ 
          Revision History
          
 
        • Added the following 7 Ready issues: 3720, 3756, 3769, 3807, 3811, 3820, 3825.
          • 
 
        • Added the following Tentatively Ready issue: 3819.
          • 
 
        • Added the following 11 Tentatively NAD issues: 3726, 3727, 3735, 3739, 3740, 3741, 3752, 3768, 3779, 3789, 3800.
          • 
-
        • Added the following 51 New issues: 3681, 3682, 3684, 3685, 3686, 3688, 3689, 3690, 3691, 3693, 3694, 3696, 3697, 3699, 3700, 3706, 3716, 3718, 3722, 3723, 3725, 3728, 3729, 3730, 3731, 3734, 3744, 3748, 3749, 3758, 3763, 3772, 3783, 3787, 3790, 3791, 3793, 3794, 3797, 3799, 3802, 3803, 3804, 3805, 3806, 3809, 3812, 3813, 3829, 3830, 3831.
          • 
+
        • Added the following 51 New issues: 3681, 3682, 3684, 3685, 3686, 3688, 3689, 3690, 3691, 3693, 3694, 3696, 3697, 3699, 3700, 3706, 3716, 3718, 3722, 3723, 3725, 3728, 3729, 3730, 3731, 3734, 3744, 3748, 3749, 3758, 3763, 3772, 3783, 3787, 3790, 3791, 3793, 3794, 3797, 3799, 3802, 3803, 3804, 3805, 3806, 3809, 3812, 3813, 3829, 3830, 3831.
          • 
 
        • Added the following 6 Open issues: 3698, 3733, 3742, 3777, 3786, 3821.
          • 
 
        • Added the following 5 LEWG issues: 3714, 3776, 3810, 3827, 3828.
          • 
 
        • Added the following 2 SG16 issues: 3767, 3780.
          • 
@@ -302,7 +302,7 @@ 
          Revision History
          
 
        • Details:
          • 
 
        • Details:
            
 
          • Added the following 6 Ready issues: 2396, 2399, 2400, 2401, 2404, 2408.
            • 
-
          • Added the following 15 New issues: 2391, 2392, 2393, 2394, 2398, 2402, 2403, 2406, 2407, 2410, 2411, 2412, 2413, 2414, 2415.
            • 
+
          • Added the following 15 New issues: 2391, 2392, 2393, 2394, 2398, 2402, 2403, 2406, 2407, 2410, 2411, 2412, 2413, 2414, 2415.
            • 
 
          • Added the following Open issue: 2397.
            • 
 
          • Added the following 3 WP issues: 2390, 2395, 2409.
            • 
 
          • Added the following NAD issue: 2405.
            • 
@@ -11663,214 +11663,6 @@ 
            23832392(i). "character type" is used but not defined
            
-
            Section: 3.36 [defns.ntcts], 30.3.1.2.1 [locale.category], 31.2.3 [iostreams.limits.pos], 31.7.6.3.1 [ostream.formatted.reqmts], 31.7.6.3.4 [ostream.inserters.character] Status: Voting
- Submitter: Jeffrey Yasskin Opened: 2014-06-01 Last modified: 2023-11-07
            
-
            Priority: 3
-
            
-
            View all issues with Voting status.
            
-
            Discussion:
            
-
            
-The term "character type" is used in 3.36 [defns.ntcts], 30.3.1.2.1 [locale.category],
-31.2.3 [iostreams.limits.pos], 31.7.6.3.1 [ostream.formatted.reqmts], and
-31.7.6.3.4 [ostream.inserters.character], but the core language only defines
-"narrow character types" (6.8.2 [basic.fundamental]).
-
            
-"wide-character type" is used in D.26 [depr.locale.stdcvt], but the core
-language only defines a "wide-character set" and "wide-character literal".
-
            
-
-
            [2023-06-14; Varna; Daniel comments and provides wording]
            
-
-
            
-Given the resolution of P2314 which had introduced to
-6.8.2 [basic.fundamental] p11 a definition of "character type":
-
            
-
            
-The types char, wchar_t, char8_t, char16_t, char32_t are collectively
-called character types.
-
            
-
            
-one might feel tempted to have most parts of this issue resolved here, but I think that this
-actually is a red herring.
-
            
-First, as Jonathan already pointed out, for two places, 31.7.6.3.1 [ostream.formatted.reqmts] and
-31.7.6.3.4 [ostream.inserters.character], this clearly doesn't work, instead it seems as if we 
-should replace "character type of the stream" here by "char_type of the stream".
-
            
-To me "char_type of the stream" sounds a bit odd (we usually refer to char_type
-in terms of a qualified name such as X::char_type instead unless we are specifying
-a member of some X, where we can omit the qualification) and in the suggested
-wording below I'm taking advantage of the already defined term "character container type"
-(3.10 [defns.character.container]) instead, which seems to fit its intended purpose here.
-
            
-Second, on further inspection it turns out that actually only one usage of the
-term "character type" seems to be intended to refer to the actual core language meaning (See
-the unchanged wording for 30.4.3.3.3 [facet.num.put.virtuals] in the proposed wording
-below), all other places quite clearly must refer to the above mentioned
-"character container type".
-
            
-For the problem related to the missing definition of "wide-character type" (used two times in
-D.26 [depr.locale.stdcvt]) I would like to suggest a less general and less inventive
-approach to solve the definition problem here, because it only occurs in an already deprecated
-component specification: My suggestion is to simply get rid of that term
-by just identifying Elem with being one of wchar_t, char16_t, or, 
-char32_t. (This result is identical to identifying "wide-character type" with
-a "character type that is not a narrow character type (6.8.2 [basic.fundamental])", but this
-seemingly more general definition doesn't provide a real advantage.)
-
            
-
-
            [Varna 2023-06-14; Move to Ready]
            
-
-
-
            [2023-06-25; Daniel comments]
            
-
-
            
-During the Varna LWG discussions of this issue it had been pointed out that the wording change applied to
-D.26.3 [depr.locale.stdcvt.req] bullet (1.1) could exclude now the previously allowed support
-of narrow character types as a "wide-character" with e.g. a Maxcode value of 255. First,
-I don't think that the revised wording really forbids this. Second, the originating proposal
-N2401 doesn't indicate what the actual intend here was and it seems questionable to
-assign LEWG to this issue given that the relevant wording is part of deprecated components, especially
-given their current position expressed here
-to eliminate the specification of the affected components as suggested by P2871.
-
            
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4950.
-
            
-
-
            
-
            
-[Drafting note: All usages of "character type" in 22.14 [format] seem to be without problems.]
-
            
-
            
-
-
              
-
            1. Modify 30.3.1.2.1 [locale.category] as indicated:
              
-
-
              
-
              
-[Drafting note: The more general interpretation of "character container type" instead of character type by
-the meaning of the core language seems safe here. It seems reasonable that an implementation allows more than
-the core language character types, but still could impose additional constraints imposed on them. Even if an implementation
-does never intend to support anything beyond char and wchar_t, the wording below is harmless.
-One alternative could be here to use the even more general term "char-like types" from 23.1 [strings.general], 
-but I'm unconvinced that this buys us much]
-
              
-
              
-
-
              
-
              
--6- […] A template parameter with name C represents the
-set of types containing char, wchar_t, and any other implementation-defined 
-character container types (3.10 [defns.character.container]) that meet the
-requirements for a character on which any of the iostream components can be instantiated. […]
-
              
-
              
-
-
              2. 
-
-
            2. Keep 30.4.3.3.3 [facet.num.put.virtuals] of Stage 1 following p4 unchanged:
              
-
-
              
-
              
-[Drafting note: The wording here seems to refer to the pure core language wording meaning of a character type.]
-
              
-
              
-
-
              
-
              
-[…] For conversion from an integral type other than a character type, the function determines the
-integral conversion specifier as indicated in Table 110.
-
              
-
              
-
-
              3. 
-
-
            3. Modify 31.2.3 [iostreams.limits.pos] as indicated:
              
-
-
              
-
              
-[Drafting note: Similar to 30.3.1.2.1 [locale.category] above the more general interpretation of "character container type" 
-instead of character type by the meaning of the core language seems safe here. ]
-
              
-
              
-
-
              
-
              
--3- In the classes of Clause 31, a template parameter with name charT represents a member of the set of types
-containing char, wchar_t, and any other implementation-defined character container types 
-(3.10 [defns.character.container]) that meet the requirements
-for a character on which any of the iostream components can be instantiated.
-
              
-
              
-
-
              4. 
-
-
            4. Modify 31.7.6.3.1 [ostream.formatted.reqmts] as indicated:
              
-
-
              
-
              
--3- If a formatted output function of a stream os determines padding, it does so as follows. Given a charT
-character sequence seq where charT is the character container type of the stream, […]
-
              
-
              
-
-
              5. 
-
-
            5. Modify 31.7.6.3.4 [ostream.inserters.character] as indicated:
              
-
-
              -template<class charT, class traits>
-  basic_ostream<charT, traits>& operator<<(basic_ostream<charT, traits>& out, charT c);
-template<class charT, class traits>
-  basic_ostream<charT, traits>& operator<<(basic_ostream<charT, traits>& out, char c);
-// specialization
-template<class traits>
-  basic_ostream<char, traits>& operator<<(basic_ostream<char, traits>& out, char c);
-// signed and unsigned
-template<class traits>
-  basic_ostream<char, traits>& operator<<(basic_ostream<char, traits>& out, signed char c);
-template<class traits>
-  basic_ostream<char, traits>& operator<<(basic_ostream<char, traits>& out, unsigned char c);
-
              
-
              
-
              
--1- Effects: Behaves as a formatted output function (31.7.6.3.1 [ostream.formatted.reqmts]) of out. 
-Constructs a character sequence seq. If c has type char and the character container 
-type of the stream is not char, then seq consists of out.widen(c); otherwise seq 
-consists of c. Determines padding for seq as described in 31.7.6.3.1 [ostream.formatted.reqmts]. 
-Inserts seq into out. Calls os.width(0).
-
              
-
              
-
              
-
-
              6. 
-
-
            6. Modify D.26.3 [depr.locale.stdcvt.req] as indicated:
              
-
-
              
-
                
-
              1. (1.1) — Elem is one ofthe wide-character type, such as 
-wchar_t, char16_t, or char32_t.
                2. 
-
              2. (1.2) — Maxcode is the largest wide-character code 
-value of Elem converted to unsigned long that the facet will read or 
-write without reporting a conversion error.
                3. 
-
              3. […]
                4. 
-
              
-
              
-
-
              7. 
-
            
-
-
-
-
-
 
            
 
            2398(i). type_info's destructor shouldn't be required to be virtual
            
 
            Section: 17.7.3 [type.info] Status: Open
@@ -27509,108 +27301,6 @@ 
            31973203(i). span element access invalidation
            
-
            Section: 24.7.2.2.1 [span.overview] Status: Voting
- Submitter: Johel Ernesto Guerrero Peña Opened: 2019-05-04 Last modified: 2023-11-07
            
-
            Priority: 2
-
            
-
            View other active issues in [span.overview].
            
-
            View all other issues in [span.overview].
            
-
            View all issues with Voting status.
            
-
            Discussion:
            
-
            
-span doesn't explicitly point out when its accessed elements are invalidated like string_view 
-does in 23.3.3.4 [string.view.iterators] p2.
-
            
-
-
            [2019-06-12 Priority set to 2 after reflector discussion]
            
-
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            This wording is relative to N4910.
            
-
-
              
-
            1. Modify 24.7.2.2.1 [span.overview] as indicated:
              
-
-
              
-
              
--4- ElementType is required to be a complete object type that is not an abstract class type.
-
              
--?- For a span s, any operation that invalidates a pointer in the range 
-[s.data(), s.data() + s.size()) invalidates pointers, iterators, and references other than 
-*this returned from s's member functions.
-
              
-
              
-
              2. 
-
            
-
            
-
-
            [2023-06-13; Varna]
            
-
-
            
-The reference to N4910 23.3.3.4 [string.view.iterators] p2 is located now in
-N4950 23.3.3.1 [string.view.template.general] p2 where its says:
-
            
-
            
-For a basic_string_view str, any operation that invalidates a pointer in the range
-
            
-
            -[str.data(), str.data() + str.size())
-
            
-
            
-invalidates pointers, iterators, and references returned from str's member functions.
-
            
-
            
-The group also suggested to adjust 23.3.3.1 [string.view.template.general] p2 similarly.
-
            
-
-
            [2023-06-14 Varna; Move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            This wording is relative to N4950.
            
-
-
              
-
            1. Modify 23.3.3.1 [string.view.template.general] as indicated:
              
-
-
              
-
              
-[Drafting note: The proposed wording also removes the extra code block that previously
-defined the range]
-
              
-
              
-
-
              
-
              
--2- For a basic_string_view str, any operation that invalidates a pointer in the range
-[str.data(), str.data() + str.size()) invalidates pointers, iterators, and references 
-to elements of strreturned from str's member functions.
-
              
-
              
-
              2. 
-
-
            2. Modify 24.7.2.2.1 [span.overview] as indicated:
              
-
-
              
-
              
--4- ElementType is required to be a complete object type that is not an abstract class type.
-
              
--?- For a span s, any operation that invalidates a pointer in the range 
-[s.data(), s.data() + s.size()) invalidates pointers, iterators, and references to elements 
-of s.
-
              
-
              
-
              3. 
-
            
-
-
-
-
 
            
 
            3205(i). decay_t in the new common_type fallback should be remove_cvref_t
            
 
            Section: 21.3.8.7 [meta.trans.other] Status: New
@@ -29951,112 +29641,6 @@ 
            32973305(i). any_cast<void>
            
-
            Section: 22.7.5 [any.nonmembers] Status: Voting
- Submitter: John Shaw Opened: 2019-10-16 Last modified: 2023-11-07
            
-
            Priority: 2
-
            
-
            View other active issues in [any.nonmembers].
            
-
            View all other issues in [any.nonmembers].
            
-
            View all issues with Voting status.
            
-
            Discussion:
            
-
            -any foo;
-void* p = any_cast<void>(&foo);
-
            
-
            
-Per 22.7.5 [any.nonmembers]/9, since the operand isn't nullptr and 
-operand->type() == typeid(T) (because T = void in this case), we should 
-return a pointer to the object contained by operand. But there is no such object.
-
            
-We need to handle the T = void case, probably by just explicitly returning nullptr.
-
            
-
-
            [2019-11 Priority to 2 during Monday issue prioritization in Belfast. There is implementation divergence here.]
            
-
-
            [2020-02 LWG discussion in Prague did not reach consensus. Status to Open.]
            
-
-
            There was discussion about whether or not any_cast<void>(a) should be ill-formed, or return nullptr.
            
-
            Poll "should it return nullptr" was 0-4-5-5-1.
            
-
            [2022-02 Currently ill-formed in MSVC ("error C2338: std::any cannot contain void") and returns null pointer in libstdc++ and libc++.]
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            This wording is relative to N4835.
            
-
-
              
-
            1. Modify 22.7.5 [any.nonmembers] as indicated:
              
-
-
              
-
              -template<class T>
-  const T* any_cast(const any* operand) noexcept;
-template<class T>
-  T* any_cast(any* operand) noexcept;
-
              
-
              
-
              
--9- Returns: If operand != nullptr && operand->type() == typeid(T) && 
-is_object_v<T>, a pointer to the object contained by operand; otherwise, 
-nullptr.
-
              
-[…]
-
              
-
              
-
              
-
              2. 
-
            
-
-
            
-
-
            [2023-06-14 Varna; Jonathan provides improved wording]
            
-
-
            [2023-06-14 Varna; Move to Ready]
            
-
-
            Poll: 7-0-1
            
-
-
-
-
            Proposed resolution:
            
-
-
            This wording is relative to N4950.
            
-
-
              
-
            1. Modify 22.7.5 [any.nonmembers] as indicated:
              
-
-
              
-
              -template<class T>
-  const T* any_cast(const any* operand) noexcept;
-template<class T>
-  T* any_cast(any* operand) noexcept;
-
              
-
              
-
              
-
--8-
-Mandates:
-is_void_v<T> is false.
-
-
              
-
              
--9-
-Returns: If operand != nullptr && operand->type() == typeid(T) is true, a pointer to the object contained by operand; otherwise,
-nullptr.
-
              
-[…]
-
              
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
 
            
 
            3308(i). vector and deque iterator erase invalidates elements even when no change occurs
            
 
            Section: 24.3.8.4 [deque.modifiers], 24.3.11.5 [vector.modifiers] Status: New
@@ -31851,7 +31435,6 @@ 
            3423active issues in [any.nonmembers].
            
 
            View all other issues in [any.nonmembers].
            
 
            View all issues with New status.
            
 
            Discussion:
            
@@ -32175,227 +31758,6 @@ 
            34293431(i). <=> for containers should require three_way_comparable<T> instead of <=>
            
-
            Section: 24.2.2.4 [container.opt.reqmts] Status: Voting
- Submitter: Jonathan Wakely Opened: 2020-04-17 Last modified: 2023-11-07
            
-
            Priority: 2
-
            
-
            View all issues with Voting status.
            
-
            Discussion:
            
-
            
-The precondition for <=> on containers is:
-
            
-"Either <=> is defined for values of type (possibly const) T, 
-or < is defined for values of type (possibly const) T and 
-< is a total ordering relationship."
-
            
-I don't think <=> is sufficient, because synth-three-way won't 
-use <=> unless three_way_comparable<T> is satisfied, which requires
-weakly-equality-comparable-with<T, T> as well as <=>.
-
            
-So to use <=> I think the type also requires ==, or more precisely, it
-must satisfy three_way_comparable.
-
            
-The problem becomes clearer with the following example:
-
            
-
            -#include <compare>
-#include <vector>
-
-struct X
-{
-  friend std::strong_ordering operator<=>(X, X) { return std::strong_ordering::equal; }
-};
-
-std::vector<X> v(1);
-std::strong_ordering c = v <=> v;
-
            
-
            
-This doesn't compile, because despite X meeting the preconditions for <=> in 
-[tab:container.opt], synth-three-way will return std::weak_ordering.
-
            
-Here is another example:
-
            
-
            -#include <compare>
-#include <vector>
-
-struct X
-{
-  friend bool operator<(X, X) { return true; } // The return value is intentional, see below
-  friend std::strong_ordering operator<=>(X, X) { return std::strong_ordering::equal; }
-};
-
-std::vector<X> v(1);
-std::weak_ordering c = v <=> v;
-
            
-
            
-This meets the precondition because it defines <=>, but the result of <=> 
-on vector<X> will be nonsense, because synth-three-way will use 
-operator< not operator<=> and that defines a broken ordering.
-
            
-So we're stating a precondition which implies "if you do this, you don't get garbage results" and 
-then we give garbage results anyway.
-
            
-The proposed resolution is one way to fix that, by tightening the precondition so that it matches 
-what synth-three-way actually does.
-
            
-
-
            [2020-04-25 Issue Prioritization]
            
-
-
            Priority to 2 after reflector discussion.
            
-
-
            
-Previous resolution [SUPERSEDED]:
-
            
-
            
-
            
-This wording is relative to N4861.
-
            
-
-
              
-
            1. Modify 24.2.2 [container.requirements.general], Table [tab:container.opt], as indicated:
              
-
-
              
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
              Table 75: Optional container operations [tab:container.opt]
              ExpressionReturn typeOperational
              semantics              		Assertion/note
              pre-/post-condition              		Complexity
              
-…
-
              
-a <=> b
-
-synth-three-way-result<value_type>
-
-lexicographical_compare_three_way(
              
-a.begin(), a.end(), b.begin(), b.end(),
              
-synth-three-way)              
-              		
-Preconditions: Either
-<=> is defined for
              
-values of type (possibly const)
              
-T satisfies three_way_comparable,
              
-or < is defined for values of type
              
-(possibly const) T and
               
-< is a total ordering relationship.
-              		
-linear
-
              
-…
-
              
-
-
              
-
              2. 
-
            
-
            
-
-
            [2022-04-24; Daniel rebases wording on N4910]
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4910.
-
            
-
-
              
-
            1. Modify 24.2.2.4 [container.opt.reqmts] as indicated:
              
-
-
              
-
              -a <=> b
-
              
-
              
-
              
--2- Result: synth-three-way-result<X::value_type>.
-
              
--3- Preconditions: Either <=> is defined for values of type (possibly const) 
-T satisfies three_way_comparable, or < is defined for values of type 
-(possibly const) T and < is a total ordering relationship.
-
              
--4- Returns: lexicographical_compare_three_way(a.begin(), a.end(), b.begin(), b.end(),
-synth-three-way)
-
              
-[Note 1: The algorithm lexicographical_compare_three_way is defined in Clause 27. — end note]
-
              
--5- Complexity: Linear.
-
              
-
              
-
              
-
-
              2. 
-
            
-
            
-
-
            [2023-06-13; Varna]
            
-
-
            
-The group liked the previously suggested wording but would prefer to say "models" instead of "satisfies"
-in preconditions.
-
            
-
            [2023-06-14 Varna; Move to Ready]
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4950.
-
            
-
-
              
-
            1. Modify 24.2.2.4 [container.opt.reqmts] as indicated:
              
-
-
              
-
              -a <=> b
-
              
-
              
-
              
--2- Result: synth-three-way-result<X::value_type>.
-
              
--3- Preconditions: Either <=> is defined for values of type (possibly const) 
-T models three_way_comparable, or < is defined for values of type 
-(possibly const) T and < is a total ordering relationship.
-
              
--4- Returns: lexicographical_compare_three_way(a.begin(), a.end(), b.begin(), b.end(),
-synth-three-way)
-
              
-[Note 1: The algorithm lexicographical_compare_three_way is defined in Clause 27. — end note]
-
              
--5- Complexity: Linear.
-
              
-
              
-
              
-
-
              2. 
-
            
-
-
-
-
 
            
 
            3436(i). std::construct_at should support arrays
            
 
            Section: 27.11.8 [specialized.construct] Status: New
@@ -36849,7 +36211,6 @@ 
            3614active issues in [range.iota.view].
            
 
            View all other issues in [range.iota.view].
            
 
            View all issues with New status.
            
 
            Discussion:
            
@@ -41987,7 +41348,6 @@ 
            3729active issues in [ranges.syn].
            
 
            View all other issues in [ranges.syn].
            
 
            View all issues with New status.
            
 
            Discussion:
            
@@ -42835,8 +42195,8 @@ 
            3748
 
            
-This issue shouldn't we voted until a decision for LWG 3749 has been made, because the first part of
-it overlaps with LWG 3749's second part.
+This issue shouldn't we voted until a decision for LWG 3749 has been made, because the first part of
+it overlaps with LWG 3749's second part.
@@ -42916,228 +42276,6 @@

37483749(i). common_iterator should handle integer-class difference types

-

Section: 25.5.5 [iterators.common] Status: Voting - Submitter: Hewill Kang Opened: 2022-08-01 Last modified: 2023-11-07

-

Priority: 2 -

-

View all issues with Voting status.

-

Discussion:

-

-The partial specialization of iterator_traits for common_iterator is defined in -25.5.5.1 [common.iterator] as -

-
-template<input_iterator I, class S>
-struct iterator_traits<common_iterator<I, S>> {
-  using iterator_concept = see below;
-  using iterator_category = see below;
-  using value_type = iter_value_t<I>;
-  using difference_type = iter_difference_t<I>;
-  using pointer = see below;
-  using reference = iter_reference_t<I>;
-};
-
-

-where difference_type is defined as iter_difference_t<I> and iterator_category -is defined as at least input_iterator_tag. However, when difference_type is an -integer-class type, common_iterator does not satisfy Cpp17InputIterator, which makes -iterator_category incorrectly defined as input_iterator_tag. -

-

-Since the main purpose of common_iterator is to be compatible with the legacy iterator system, -which is reflected in its efforts to try to provide the operations required by C++17 iterators even if -the underlying iterator does not support it. We should handle this case of difference type incompatibility -as well. -

-The proposed solution is to provide a C++17 conforming difference type by clamping the integer-class type -to ptrdiff_t. -

-Daniel: -

-
-

-The second part of this issue provides an alternative resolution for the first part of -LWG 3748 and solves the casting problem mentioned in LWG 3748 as well. -

-
- -

[2022-08-23; Reflector poll]

- -

-Set priority to 2 after reflector poll. -

-

-"I think common_iterator should reject iterators with -integer-class difference types since it can't possibly achieve the design intent -of adapting them to Cpp17Iterators." -

-

-"I'm not yet convinced that we need to outright reject such uses, -but I'm pretty sure that we shouldn't mess with the difference type -and that the PR is in the wrong direction." -

- -

Previous resolution [SUPERSEDED]:

-
- -

-This wording is relative to N4910. -

- -
    -

  1. Modify 25.5.5.1 [common.iterator] as indicated:

    - -
    -

    -[Drafting note: common_iterator requires iterator type I must model -input_or_output_iterator which ensures that iter_difference_t<I> -is a signed-integer-like type. The modification of common_iterator::operator- is to ensure -that the pair of common_iterator<I, S> models sized_sentinel_for when -sized_sentinel_for<I, S> is modeled for iterator type I with an -integer-class difference type and its sentinel type S.] -

    -
    - -
    -
    -namespace std {
-  template<class D>
-    requires is-signed-integer-like<D>
-  using make-cpp17-diff-t = conditional_t<signed_integral<D>, D, ptrdiff_t>;  // exposition only
-
-  template<input_or_output_iterator I, sentinel_for<I> S>
-    requires (!same_as<I, S> && copyable<I>)
-  class common_iterator {
-  public:
-    […]
-    template<sized_sentinel_for<I> I2, sized_sentinel_for<I> S2>
-      requires sized_sentinel_for<S, I2>
-    friend constexpr make-cpp17-diff-t<iter_difference_t<I2>> operator-(
-      const common_iterator& x, const common_iterator<I2, S2>& y);
-    […]
-  };
-  
-  template<class I, class S>
-  struct incrementable_traits<common_iterator<I, S>> {
-    using difference_type = make-cpp17-diff-t<iter_difference_t<I>>;
-  };
-
-  template<input_iterator I, class S>
-  struct iterator_traits<common_iterator<I, S>> {
-    using iterator_concept = see below;
-    using iterator_category = see below;
-    using value_type = iter_value_t<I>;
-    using difference_type = make-cpp17-diff-t<iter_difference_t<I>>;
-    using pointer = see below;
-    using reference = iter_reference_t<I>;
-  };
-}
-
    -
    -
    2. - -

  2. Modify 25.5.5.6 [common.iter.cmp] as indicated:

    - -
    -

    -[Drafting note: If this issue is voted in at the same time as LWG 3748, the editor -is kindly informed that the changes indicated below supersede those of the before mentioned issues first -part.] -

    -
    - -
    -
    -template<sized_sentinel_for<I> I2, sized_sentinel_for<I> S2>
-  requires sized_sentinel_for<S, I2>
-friend constexpr make-cpp17-diff-t<iter_difference_t<I2>> operator-(
-  const common_iterator& x, const common_iterator<I2, S2>& y);
-
    -
    -

    --5- Preconditions: x.v_.valueless_by_exception() and y.v_.valueless_by_exception() are -each false. -

    --6- Returns: 0 if i and j are each 1, and -otherwise static_cast<make-cpp17-diff-t<iter_difference_t<I2>>>(get<i>(x.v_) -- get<j>(y.v_)), where i is x.v_.index() -and j is y.v_.index(). -

    -
    -
    -
    3. - -
-
- -

[2023-06-13; Varna; Tomasz provides wording]

- -

[2023-06-14 Varna; Move to Ready]

- - - -

Proposed resolution:

-

-This wording is relative to N4950. -

- -
    -

  1. Modify 25.5.5.1 [common.iterator] as indicated:

    - -
    -
    -namespace std {
-  […]
-
-  template<input_iterator I, class S>
-  struct iterator_traits<common_iterator<I, S>> {
-    using iterator_concept = see below;
-    using iterator_category = see below; // not always present
-    using value_type = iter_value_t<I>;
-    using difference_type = iter_difference_t<I>;
-    using pointer = see below;
-    using reference = iter_reference_t<I>;
-  };
-}
-
    -
    -
    2. - -

  2. Modify 25.5.5.2 [common.iter.types] as indicated:

    - -
    -

    --?- The nested typedef-name iterator_category of the specialization of iterator_traits for -common_iterator<I, S> is defined if and only if iter_difference_t<I> is an integral type. -In that case, iterator_category denotes forward_iterator_tag if the qualified-id -iterator_traits<I>::iterator_category is valid and denotes a type that models -derived_from<forward_iterator_tag>; otherwise it denotes input_iterator_tag. -

    -

    --1- The remaining nested typedef-names of the specialization of iterator_traits -for common_iterator<I, S> are defined as follows.: -

    -
      -

    1. (1.1) — iterator_concept denotes forward_iterator_tag if I models -forward_iterator; otherwise it denotes input_iterator_tag.

      2. -

    2. (1.2) — iterator_category denotes -forward_iterator_tag if the qualified-id iterator_traits<I>::iterator_category is valid -and denotes a type that models derived_from<forward_iterator_tag>; otherwise it denotes input_iterator_tag.

      3. -

    3. (1.3) — Let a denote an lvalue of type const common_iterator<I, S>. -If the expression a.operator->() is well-formed, then pointer denotes decltype(a.operator->()). -Otherwise, pointer denotes void.

      4. -
    -
    -
    3. - -
- - - - -

3758(i). Element-relocating operations of std::vector and std::deque should conditionally require Cpp17CopyInsertable in their preconditions

@@ -44409,162 +43547,6 @@

38053809(i). Is std::subtract_with_carry_engine<uint16_t> supposed to work?

-

Section: 28.5.4.4 [rand.eng.sub] Status: Voting - Submitter: Jonathan Wakely Opened: 2022-11-02 Last modified: 2023-11-07

-

Priority: 3 -

-

View all other issues in [rand.eng.sub].

-

View all issues with Voting status.

-

Discussion:

-

-The standard requires subtract_with_carry_engine<T> to use: -

-
-linear_congruential_engine<T, 40014u, 0u, 2147483563u>
-
-

-where each of those values is converted to T. -

-This appears to mean subtract_with_carry_engine cannot be used with uint16_t, because -2147483563u cannot be converted to uint16_t without narrowing. -

-What is the intention here? Should it be ill-formed? Should the seed engine be -linear_congruential_engine<uint_least32_t, …> instead? The values from the -linear_congruential_engine are used modulo 2^32 so getting 64-bit values from it is pointless, -and getting 16-bit values from it doesn't compile. -

- -

[Kona 2022-11-12; Set priority to 3]

- - -

[Kona 2022-11-25; Jonathan provides wording]

- - -

[2023-05; reflector poll]

- -

Status to Tentatively Ready after six votes in favour.

- - - -

Proposed resolution:

- -

This wording is relative to N4917.

- -
    -
  1. -

    Modify the class synopsis in 28.5.4.4 [rand.eng.sub] as indicated:

    -
    -namespace std {
-  template<class UIntType, size_t w, size_t s, size_t r>
-  class subtract_with_carry_engine {
-  public:
-    // types
-    using result_type = UIntType;
-    // engine characteristics
-    static constexpr size_t word_size = w;
-    static constexpr size_t short_lag = s;
-    static constexpr size_t long_lag = r;
-    static constexpr result_type min() { return 0; }
-    static constexpr result_type max() { return m − 1; }
-    static constexpr result_typeuint_least32_t default_seed = 19780503u;
-    // constructors and seeding functions
-    subtract_with_carry_engine() : subtract_with_carry_engine(default_seed0u) {}
-    explicit subtract_with_carry_engine(result_type value);
-    template<class Sseq> explicit subtract_with_carry_engine(Sseq& q);
-    void seed(result_type value = default_seed0u);
-    template<class Sseq> void seed(Sseq& q);
-
    -
    2. -
  2. -

    Modify 28.5.4.4 [rand.eng.sub] p7 as indicated:

    -
    -
    explicit subtract_with_carry_engine(result_type value);
    -

    -7- Effects: -Sets the values of - - - X − r - , - … - , - X − 1 - -, -in that order, as specified below. If - - - X − 1 - - -is then 0 , -sets c to 1 ; -otherwise sets c to 0 . -

    -

         -To set the values - X k , -first construct e, a linear_congruential_engine object, -as if by the following definition: -

    -
    -linear_congruential_engine<result_typeuint_least32_t,
-                           40014u,0u,2147483563u> e(value == 0u ? default_seed : value);
-
    -

         -Then, to set each - X k , -obtain new values - - - z 0 - , - … - , - z n − 1 - - -from - - - n = - ⌈ - w ⁄ 32 - ⌉ - - -successive invocations of e. -Set - X k -to - - - - ( - - ∑ - j = 0 - n − 1 - - z j - ⋅ - 2 32 j - ) - - mod - m - -. -

    -
    -
    3. -
- - - - -

3812(i). [fund.ts.v3] Incorrect constraint on propagate_const conversion function

Section: 3.2.2.5 [fund.ts.v3::propagate_const.const_observers] Status: New @@ -44647,7 +43629,6 @@

3813active issues in [span.overview].

View all other issues in [span.overview].

View all issues with New status.

Discussion:

@@ -48034,267 +47015,6 @@

38913892(i). Incorrect formatting of nested ranges and tuples

-

Section: 22.14.7.2 [format.range.formatter], 22.14.9 [format.tuple] Status: Voting - Submitter: Victor Zverovich Opened: 2023-02-20 Last modified: 2023-11-07

-

Priority: 2 -

-

View all other issues in [format.range.formatter].

-

View all issues with Voting status.

-

Discussion:

-

-formatter specializations for ranges and tuples set debug format for underlying element formatters in their -parse functions e.g. 22.14.7.2 [format.range.formatter] p9: -

-
-template<class ParseContext>
-  constexpr typename ParseContext::iterator
-    parse(ParseContext& ctx);
-
-
-

-Effects: Parses the format specifier as a range-format-spec and stores the parsed specifiers in *this. - The values of opening-bracket_, closing-bracket_, and separator_ are modified - if and only if required by the range-type or the n option, if present. If: -

-
    -

  1. — the range-type is neither s nor ?s,

    2. -

  2. — underlying_.set_debug_format() is a valid expression, and

    3. -

  3. — there is no range-underlying-spec,

    4. -
-

-then calls underlying_.set_debug_format(). -

-
-
-

-However, they don't say anything about calling parse functions of those formatters. As as result, -formatting of nested ranges can be incorrect, e.g. -

-
-std::string s = std::format("{}", std::vector<std::vector<std::string>>{{"a, b", "c"}});
-
-

-With the current specification s is [[a, b, c]] instead of [["a, b", "c"]], i.e. strings -in the output are not correctly escaped. The same is true for nested tuples and combinations of tuples and ranges. -

-The fix approved by LEWG as part of P2733 (which was trying to address a different issue) is to -always call parse for underlying formatter. -Additionally the standard should clarify that format-spec cannot start with '}' because that's the -implicit assumption in range formatting and what happens when format-spec is not present. -

- -

[2023-03-22; Reflector poll]

- -

-Set priority to 2 after reflector poll. -

- -

Previous resolution [SUPERSEDED]:

-
- -

-This wording is relative to N4928. -

- -
    - -

  1. Modify 22.14.2.1 [format.string.general] p1 as indicated:

    - -
    -
    -
    […]
    -
    format-specifier:
    -
    : format-spec
    -
    format-spec:
    -
    as specified by the formatter specialization for the argument type; cannot start with }
    -
    -
    - -
    2. - -

  2. Modify 22.14.6.1 [formatter.requirements] as indicated:

    - -
    -

    --3- Given character type charT, output iterator type Out, and formatting argument type T, in -Table 74 [tab:formatter.basic] and Table 75 [tab:formatter]: -

    -[…] -

    -pc.begin() points to the beginning of the format-spec (22.14.2 [format.string]) of the -replacement field being formatted in the format string. If format-spec is not present or empty then -either pc.begin() == pc.end() or *pc.begin() == '}'. -

    -
    - -
    3. - -

  3. Modify 22.14.7.2 [format.range.formatter] as indicated:

    - -
    -
    -template<class ParseContext>
-  constexpr typename ParseContext::iterator
-    parse(ParseContext& ctx);
-
    -
    -

    --9- Effects: Parses the format specifiers as a range-format-spec and stores the parsed specifiers in *this. -Calls underlying_.parse(ctx) to parse format-spec in range-format-spec or, if the latter is not present, -empty format-spec. The values of opening-bracket_, closing-bracket_, and separator_ -are modified if and only if required by the range-type or the n option, if present. If: -

    -
      -

    1. (9.1) — the range-type is neither s nor ?s,

      2. -

    2. (9.2) — underlying_.set_debug_format() is a valid expression, and

      3. -

    3. (9.3) — there is no range-underlying-spec,

      4. -
    -

    -then calls underlying_.set_debug_format(). -

    -
    -
    - -
    4. - -

  4. Modify 22.14.9 [format.tuple] as indicated:

    - -
    -
    -template<class ParseContext>
-  constexpr typename ParseContext::iterator
-    parse(ParseContext& ctx);
-
    -
    -

    --7- Effects: Parses the format specifiers as a tuple-format-spec and stores the parsed specifiers -in *this. The values of opening-bracket_, closing-bracket_, and separator_ -are modified if and only if required by the tuple-type, if present. For each element e in -underlying_, calls e.parse(ctx) to parse empty format-spec and, -if e.set_debug_format() is a valid expression, calls e.set_debug_format(). -

    -
    -
    - - -
    5. - - -
-
- -

[Varna 2023-06-16; Jonathan provides tweaked wording]

- -

-Add "an" in two places. -

- -

[Varna 2023-06-16; Move to Ready]

- -

-This would allow resolving LWG 3776 as NAD. -

- - - -

Proposed resolution:

- -

-This wording is relative to N4928. -

- -
    - -

  1. Modify 22.14.2.1 [format.string.general] p1 as indicated:

    - -
    -
    -
    […]
    -
    format-specifier:
    -
    : format-spec
    -
    format-spec:
    -
    as specified by the formatter specialization for the argument type; cannot start with }
    -
    -
    - -
    2. - -

  2. Modify 22.14.6.1 [formatter.requirements] as indicated:

    - -
    -

    --3- Given character type charT, output iterator type Out, and formatting argument type T, in -Table 74 [tab:formatter.basic] and Table 75 [tab:formatter]: -

    -[…] -

    -pc.begin() points to the beginning of the format-spec (22.14.2 [format.string]) of the -replacement field being formatted in the format string. If format-spec is not present or empty then -either pc.begin() == pc.end() or *pc.begin() == '}'. -

    -
    - -
    3. - -

  3. Modify 22.14.7.2 [format.range.formatter] as indicated:

    - -
    -
    -template<class ParseContext>
-  constexpr typename ParseContext::iterator
-    parse(ParseContext& ctx);
-
    -
    -

    --9- Effects: Parses the format specifiers as a range-format-spec and stores the parsed specifiers in *this. -Calls underlying_.parse(ctx) to parse format-spec in range-format-spec or, if the latter is not present, -an empty format-spec. The values of opening-bracket_, closing-bracket_, and separator_ -are modified if and only if required by the range-type or the n option, if present. If: -

    -
      -

    1. (9.1) — the range-type is neither s nor ?s,

      2. -

    2. (9.2) — underlying_.set_debug_format() is a valid expression, and

      3. -

    3. (9.3) — there is no range-underlying-spec,

      4. -
    -

    -then calls underlying_.set_debug_format(). -

    -
    -
    - -
    4. - -

  4. Modify 22.14.9 [format.tuple] as indicated:

    - -
    -
    -template<class ParseContext>
-  constexpr typename ParseContext::iterator
-    parse(ParseContext& ctx);
-
    -
    -

    --7- Effects: Parses the format specifiers as a tuple-format-spec and stores the parsed specifiers -in *this. The values of opening-bracket_, closing-bracket_, and separator_ -are modified if and only if required by the tuple-type, if present. For each element e in -underlying_, calls e.parse(ctx) to parse an empty format-spec and, -if e.set_debug_format() is a valid expression, calls e.set_debug_format(). -

    -
    -
    - - -
    5. - - -
- - - - -

3895(i). Various relation concepts are missing default values of the second template parameters

Section: 18.3 [concepts.syn], 25.2 [iterator.synopsis] Status: New @@ -48553,150 +47273,6 @@

38963897(i). inout_ptr will not update raw pointer to 0

-

Section: 20.3.4.3 [inout.ptr.t] Status: Voting - Submitter: Doug Cook Opened: 2023-02-27 Last modified: 2023-11-07

-

Priority: 2 -

-

View all other issues in [inout.ptr.t].

-

View all issues with Voting status.

-

Discussion:

-

-inout_ptr seems useful for two purposes: -

-
    -

  1. Using smart pointers with C-style APIs.

    2. -

  2. Annotating raw pointers for use with C-style APIs.

    3. -
-

-Unfortunately, as presently specified, it is not safe for developers to use inout_ptr for the second purpose. -It is not safe to change code from -

-
-void* raw_ptr1;
-InitSomething(&raw_ptr1);
-UpdateSomething(&raw_ptr1); // In some cases may set raw_ptr1 = nullptr.
-CleanupSomething(raw_ptr1);
-
-

-to -

-
-void* raw_ptr2;
-InitSomething(std::out_ptr(raw_ptr2));
-UpdateSomething(std::inout_ptr(raw_ptr2)); // May leave dangling pointer
-CleanupSomething(raw_ptr2);                // Possible double-delete
-
-

-In the case where UpdateSomething would set raw_ptr1 = nullptr, the currently-specified inout_ptr -implementation will leave raw_ptr2 at its old value. This would likely lead to a double-delete in CleanupSomething. -

-The issue occurs because inout_ptr is specified as follows: -

-
    -

  1. Constructor: If the user's pointer is a smart pointer, perform a "release" operation.

    2. -

  2. (C-style API executes)

    3. -

  3. If the C-style API returns a non-NULL pointer, propagate the returned value to the user's pointer.

    4. -
-

-If the user's pointer is not a smart pointer, no "release" operation occurs, and if the C-style API returns a -NULL pointer, no propagation of the NULL occurs. We're left with a dangling raw pointer which is -different from the original behavior using &. -

-I see two potential solutions: -

-
    -

  1. Make the "release" operation unconditional (i.e. it applies to both smart and raw pointers). For raw pointers, -define the "release" operation as setting the raw pointer to nullptr.

    2. -

  2. Make the return value propagation unconditional for raw pointers.

    3. -
-

-Solution #2 seems likely to lead to more optimal code as it avoids an unnecessary branch. -

- -

[2023-03-22; Reflector poll]

- -

-Set priority to 2 after reflector poll. -

- -

[Varna 2023-06-16; Move to Ready]

- - - - -

Proposed resolution:

-

-This wording is relative to N4928. -

- -
    - -

  1. Modify 20.3.4.3 [inout.ptr.t] as indicated:

    - -
    -
    -~inout_ptr_t();
-
    -
    -

    --9- Let SP be POINTER_OF_OR(Smart, Pointer) (20.2.1 [memory.general]). -

    --10- Let release-statement be s.release(); if an implementation does not call s.release() in the -constructor. Otherwise, it is empty. -

    --11- Effects: Equivalent to: -

    -
      -

    1. (11.1) —

      -
      -if (p) {
-  apply([&](auto&&... args) {
-    s = Smart( static_cast<SP>(p), std::forward<Args>(args)...); }, std::move(a));
-}
-
      -

      -if is_pointer_v<Smart> is true; -

      2. -

    2. (11.2) — otherwise,

      -
      -release-statement;
-if (p) {
-  apply([&](auto&&... args) {
-    s.reset(static_cast<SP>(p), std::forward<Args>(args)...); }, std::move(a));
-}
-
      -

      -if the expression s.reset(static_cast<SP>(p), std::forward<Args>(args)...) is well-formed; -

      -
      3. -

    3. (11.3) — otherwise,

      -
      -release-statement;
-if (p) {
-  apply([&](auto&&... args) {
-    s = Smart(static_cast<SP>(p), std::forward<Args>(args)...); }, std::move(a));
-}
-
      -

      -if is_constructible_v<Smart, SP, Args...> is true; -

      -
      4. -

    4. (11.4) — otherwise, the program is ill-formed.

      5. -
    - -
    -
    - -
    2. - -
- - - - -

3898(i). Possibly unintended preconditions for completion functions of std::barrier

Section: 33.9.3.3 [thread.barrier.class] Status: New @@ -52087,246 +50663,6 @@

39453946(i). The definition of const_iterator_t should be reworked

-

Section: 26.2 [ranges.syn] Status: Voting - Submitter: Christopher Di Bella Opened: 2023-06-13 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View other active issues in [ranges.syn].

-

View all other issues in [ranges.syn].

-

View all issues with Voting status.

-

Discussion:

-

-During the reflector discussion of P2836, consensus was reached that const_iterator_t<R> -doesn't necessarily provide the same type as decltype(ranges::cbegin(r)), and that it should be changed to -the proposed resolution below so that they're consistent. -

- -

[Varna 2023-06-14; Move to Ready]

- - - -

Proposed resolution:

-

-This wording is relative to N4950. -

- -
    -

  1. Modify 26.2 [ranges.syn], header <ranges> synopsis, as indicated:

    - -
    -
    -[…]
-template<range R>
-  using const_iterator_t = decltype(ranges::cbegin(declval<R&>()))const_iterator<iterator_t<R>>; // freestanding
-template<range R>
-  using const_sentinel_t = decltype(ranges::cend(declval<R&>()))const_sentinel<sentinel_t<R>>;   // freestanding
-[…]
-
    -
    -
    2. - -
- - - - - -
-

3947(i). Unexpected constraints on adjacent_transform_view::base()

-

Section: 26.7.27.2 [range.adjacent.transform.view] Status: Voting - Submitter: Bo Persson Opened: 2023-06-17 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all issues with Voting status.

-

Discussion:

-

-In section 26.7.27.2 [range.adjacent.transform.view] the class -ranges::adjacent_transform_view got two new base() members from -3848. -

-The first one looks like -

-
-constexpr V base() const & requires copy_constructible<InnerView>
-{ return inner_.base(); }
-
-

-Here the requirement is that InnerView is copy constructible, when it in -fact returns an object of type V. That seems odd. -

-I would expect the constraint to instead be copy_constructible<V>. -

- -

[2023-10-27; Reflector poll]

- -

-Set status to Tentatively Ready after five votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4950. -

- -
    -

  1. Modify 26.7.27.2 [range.adjacent.transform.view], class template -adjacent_transform_view synopsis, as indicated:

    - -
    -
    -namespace std::ranges {
-  template<forward_range V, move_constructible F, size_t N>
-    requires view<V> && (N > 0) && is_object_v<F> &&
-      regular_invocable<F&, REPEAT(range_reference_t<V>, N)...> &&
-      can-reference<invoke_result_t<F&, REPEAT(range_reference_t<V>, N)...>>
-  class adjacent_transform_view : public view_interface<adjacent_transform_view<V, F, N>> {
-    […]
-    adjacent_view<V, N> inner_; // exposition only
-    
-    using InnerView = adjacent_view<V, N>; // exposition only
-    […]
-  public:
-    […]
-    constexpr V base() const & requires copy_constructible<VInnerView> { return inner_.base(); }
-    constexpr V base() && { return std::move(inner_).base(); }
-    […]
-  };
-}
-
    -
    -
    2. - -
- - - - - -
-

3948(i). possibly-const-range and as-const-pointer should be noexcept

-

Section: 26.2 [ranges.syn], 26.3.14 [range.prim.cdata] Status: Voting - Submitter: Jiang An Opened: 2023-06-20 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View other active issues in [ranges.syn].

-

View all other issues in [ranges.syn].

-

View all issues with Voting status.

-

Discussion:

-

-As of P2278R4, several range access CPOs are specified with possibly-const-range -and as-const-pointer. These helper functions never throw exceptions, but are not marked with -noexcept. As a result, implementations are currently allowed to make a call to -ranges::ccpo potentially throwing while the underlying ranges::cpo call is -non-throwing, which doesn't seem to be intended. -

- -

[2023-10-27; Reflector poll]

- -

-Set status to Tentatively Ready after five votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4950. -

- -
    -

  1. Modify 26.2 [ranges.syn], header <ranges> synopsis, as indicated:

    - -
    -
    -[…]
-// 26.7.21 [range.as.const], as const view
-template<input_range R>
-  constexpr auto& possibly-const-range(R& r) noexcept {      // exposition only
-    if constexpr (constant_range<const R> && !constant_range<R>) {
-      return const_cast<const R&>(r);
-    } else {
-      return r;
-    }
-  }
-[…]
-
    -
    -
    2. - -

  2. Modify 26.3.14 [range.prim.cdata] before p1 as indicated:

    - -
    -
    -template<class T>
-constexpr auto as-const-pointer(const T* p) noexcept { return p; }    // exposition only
-
    -
    -
    3. - -
- - - - - -
-

3949(i). std::atomic<bool>'s trivial destructor dropped in C++17 spec wording

-

Section: 33.5.8.1 [atomics.types.generic.general] Status: Voting - Submitter: Jeremy Hurwitz Opened: 2023-06-20 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all issues with Voting status.

-

Discussion:

-

-std::atomic<bool> was originally required to have a trivial default constructor and a trivial destructor -[C++11 N3337: Section [atomics.types.generic], Paragraph 5], -the same as the integral [C++11 N3337: Section [atomics.types.generic], -Paragraph 5] and pointer specializations [C++11 N3337: -Section [atomics.types.generic], Paragraph 6]. P0558 rearranged the text, -accidentally (as far as we can tell) removing the constructor and destructor requirements from std::atomic<bool>, -which has the surprising effect that std::atomic<bool> has no longer the same constructor/destructor -guarantees as std::atomic<int>. -

-C++20 removed the "trivial default constructor" requirement from all specializations. A specialization for floating-point -types was added with a trivial destructor [N4861: Section [atomics.types.float], -Paragraph 2)]. -

- -

[2023-10-27; Reflector poll]

- -

-Set status to Tentatively Ready after eight votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4950. -

- -
    -

  1. Modify 33.5.8.1 [atomics.types.generic.general] as indicated:

    - -
    -

    --1- […] -

    --2- The specialization atomic<bool> is a standard-layout struct. It has a trivial destructor. -

    -
    -
    2. - -
- - - - -

3950(i). std::basic_string_view comparison operators are overspecified

Section: 23.3.2 [string.view.synop] Status: Ready @@ -52649,87 +50985,6 @@

39503951(i). §[expected.object.swap]: Using value() instead of has_value()

-

Section: 22.8.6.5 [expected.object.swap], 22.8.7.5 [expected.void.swap] Status: Voting - Submitter: Ben Craig Opened: 2023-06-25 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all issues with Voting status.

-

Discussion:

-

-22.8.6.5 [expected.object.swap] p2 has the following text in it: -

-

-For the case where rhs.value() is false and this->has_value() is true, equivalent to: […] -

-

-The table preceding that text is a table of this->has_value() vs. rhs.has_value(). The rhs.value() -in the text is almost certainly a typo, as a .value() call here doesn't make any sense, especially if this is an -expected<non-bool, E>. -

-The same issue is there for 22.8.7.5 [expected.void.swap] p2. -

- -

[2023-10-27; Reflector poll]

- -

-Set status to Tentatively Ready after seven votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4950. -

- -
    -

  1. Modify 22.8.6.5 [expected.object.swap] as indicated:

    - - -
    -
    -constexpr void swap(expected& rhs) noexcept(see below);
-
    -
    -

    --1- […] -

    --2- Effects: See Table 63 [tab:expected.object.swap]. -

    -For the case where rhs.has_value() is false and this->has_value() is true, equivalent to: […] -

    -
    -
    - -
    2. - -

  2. Modify 22.8.7.5 [expected.void.swap] as indicated:

    - - -
    -
    -constexpr void swap(expected& rhs) noexcept(see below);
-
    -
    -

    --1- […] -

    --2- Effects: See Table 64 [tab:expected.void.swap]. -

    -For the case where rhs.has_value() is false and this->has_value() is true, equivalent to: […] -

    -
    -
    - -
    3. -
- - - - -

3952(i). iter_common_reference_t does not conform to the definition of indirectly_readable

Section: 25.2 [iterator.synopsis], 25.5.3.2 [const.iterators.alias], 25.5.3.3 [const.iterators.iterator] Status: New @@ -52860,128 +51115,6 @@

39523953(i). iter_move for common_iterator and counted_iterator should return decltype(auto)

-

Section: 25.5.5.7 [common.iter.cust], 25.5.7.7 [counted.iter.cust] Status: Voting - Submitter: Hewill Kang Opened: 2023-06-30 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all issues with Voting status.

-

Discussion:

-

-Although the customized iter_move of both requires the underlying iterator I to be input_iterator, -they still explicitly specify the return type as iter_rvalue_reference_t<I>, -which makes it always instantiated. -

-

-From the point of view that its validity is only specified in the input_iterator concept, it would be better to remove such -unnecessary type instantiation, which does not make much sense for an output_iterator even if it is still valid. -

- -

[2023-10-27; Reflector poll]

- -

-Set status to Tentatively Ready after six votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4950. -

- -
    -

  1. Modify 25.5.5.1 [common.iterator], class template common_iterator synopsis, as indicated:

    - - -
    -
    -namespace std {
-  template<input_or_output_iterator I, sentinel_for<I> S>
-    requires (!same_as<I, S> && copyable<I>)
-  class common_iterator {
-  public:
-    […]
-    friend constexpr iter_rvalue_reference_t<I>decltype(auto) iter_move(const common_iterator& i)
-      noexcept(noexcept(ranges::iter_move(declval<const I&>())))
-        requires input_iterator<I>;
-    […]
-  };
-  […]
-}
-
    -
    - -
    2. - -

  2. Modify 25.5.5.7 [common.iter.cust] as indicated:

    - -
    -
    -friend constexpr iter_rvalue_reference_t<I>decltype(auto) iter_move(const common_iterator& i)
-  noexcept(noexcept(ranges::iter_move(declval<const I&>())))
-    requires input_iterator<I>;
-
    -
    -

    --1- Preconditions: […] -

    --2- Effects: Equivalent to: return ranges::iter_move(get<I>(i.v_)); -

    -
    -
    - -
    3. - -

  3. Modify 25.5.7.1 [counted.iterator], class template counted_iterator synopsis, as indicated:

    - - -
    -
    -namespace std {
-  template<input_or_output_iterator I>
-  class counted_iterator {
-  public:
-    […]
-    friend constexpr iter_rvalue_reference_t<I>decltype(auto) iter_move(const counted_iterator& i)
-      noexcept(noexcept(ranges::iter_move(i.current)))
-        requires input_iterator<I>;
-    […]
-  };
-  […]
-}
-
    -
    - -
    4. - -

  4. Modify 25.5.7.7 [counted.iter.cust] as indicated:

    - -
    -
    -friend constexpr iter_rvalue_reference_t<I>decltype(auto) 
-  iter_move(const counted_iterator& i)
-    noexcept(noexcept(ranges::iter_move(i.current)))
-    requires input_iterator<I>;
-
    -
    -

    --1- Preconditions: […] -

    --2- Effects: Equivalent to: return ranges::iter_move(i.current); -

    -
    -
    - -
    5. - -
- - - - -

3954(i). Feature-test macros in C headers (<stddef.h> etc.)

Section: 17.14.1 [support.c.headers.general] Status: New @@ -53218,107 +51351,6 @@

39563957(i). §[container.alloc.reqmts] The value category of v should be claimed

-

Section: 24.2.2.5 [container.alloc.reqmts] Status: Voting - Submitter: jim x Opened: 2023-07-10 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View other active issues in [container.alloc.reqmts].

-

View all other issues in [container.alloc.reqmts].

-

View all issues with Voting status.

-

Discussion:

-

-24.2.2.5 [container.alloc.reqmts] p2 says: -

-

-[…] an expression v of type T or const T, […] -

-

-Then 24.2.2.5 [container.alloc.reqmts] bullet (2.4) says: -

-

-T is Cpp17CopyInsertable into X means that, in addition to T being -Cpp17MoveInsertable into X, the following expression is well-formed: -

-
-allocator_traits<A>::construct(m, p, v)
-
-
-

-So, what is the value category of the expression v? We didn't explicitly phrase the wording. -The intent may be that the value category of v is any defined value category in 7.2.1 [basic.lval], -however, the intent is not clear in the current wording. Maybe, we can say: -

-

-[…] the following expression is well-formed: -

-
-allocator_traits<A>::construct(m, p, v)
-
-

-for v of any value category. -

-
-

-which can make the intent meaning clearer. -

- -

[2023-10-27; Reflector poll]

- -

-Set status to Tentatively Ready after five votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4950. -

- -
    - -

  1. Modify 24.2.2.5 [container.alloc.reqmts] as indicated:

    - -
    -

    --2- Given an allocator type A and given a container type X having a value_type -identical to T and an allocator_type identical to allocator_traits<A>::rebind_alloc<T> -and given an lvalue m of type A, a pointer p of type T*, an expression -v that denotes an lvalue of type T or const T or an rvalue of type const T, -and an rvalue rv of type T, the following terms are defined. […] -

    -
      -

    1. […]

      2. -

    2. (2.3) — T is Cpp17MoveInsertable into X means that the following expression is well-formed:

      -
      -allocator_traits<A>::construct(m, p, rv)
-
      -

      and its evaluation causes the following postcondition to hold: The value of *p is equivalent to the value -of rv before the evaluation. -

      -[Note 1: rv remains a valid object. Its state is unspecified — end note]

      3. -

    3. (2.4) — T is Cpp17CopyInsertable into X means that, in addition to T being -Cpp17MoveInsertable into X, the following expression is well-formed:

      -
      -allocator_traits<A>::construct(m, p, v)
-
      -

      and its evaluation causes the following postcondition to hold: The value of v is unchanged and is -equivalent to *p.

      -
      4. -

    4. […]

      5. -
    -
    - -
    2. - -
- - - - -

3958(i). ranges::to should prioritize the "reserve" branch

Section: 26.5.7.2 [range.utility.conv.to] Status: Tentatively NAD @@ -53917,117 +51949,6 @@

39643965(i). Incorrect example in [format.string.escaped] p3 for formatting of combining characters

-

Section: 22.14.6.4 [format.string.escaped] Status: Voting - Submitter: Tom Honermann Opened: 2023-07-31 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all issues with Voting status.

-

Discussion:

-

-The C++23 DIS contains the following example in 22.14.6.4 [format.string.escaped] p3. (This example does -not appear in the most recent N4950 WP or on https://eel.is/c++draft -because the project editor has not yet merged changes needed to support rendering of some of the characters involved). -

-
-string s6 = format("[{:?}]", "🤷‍♂️"); // s6 has value: ["🤷\u{200d}♂\u{fe0f}"]
-
-

-The character to be formatted (🤷‍♂️) consists of the following sequence of code points -in the order presented: -

-
    -

  • U+1F937 (SHRUG)

    • -

  • U+200D (ZERO WIDTH JOINER)

    • -

  • U+2642 (MALE SIGN)

    • -

  • U+FE0F (VARIATION SELECTOR-16)

    • -
-

-22.14.6.4 [format.string.escaped] bullet 2.2.1 specifies which code points are to be formatted as a -\u{hex-digit-sequence} escape sequence: -

-
    -

  1. (2.2.1) — If X encodes a single character C, then:

    -
      -

    1. (2.2.1.1) — If C is one of the characters in Table 75 [tab:format.escape.sequences], then the two characters shown -as the corresponding escape sequence are appended to E.

      2. -

    2. (2.2.1.2) — Otherwise, if C is not U+0020 SPACE and

      -
        -

      1. (2.2.1.2.1) — CE is UTF-8, UTF-16, or UTF-32 and C corresponds to a Unicode scalar value whose -Unicode property General_Category has a value in the groups Separator (Z) or Other -(C), as described by UAX #44 of the Unicode Standard, or

        2. -

      2. (2.2.1.2.2) — CE is UTF-8, UTF-16, or UTF-32 and C corresponds to a Unicode scalar value with -the Unicode property Grapheme_Extend=Yes as described by UAX #44 of the Unicode -Standard and C is not immediately preceded in S by a character P appended to E without -translation to an escape sequence, or

        3. -

      3. (2.2.1.2.3) — CE is neither UTF-8, UTF-16, nor UTF-32 and C is one of an implementation-defined -set of separator or non-printable characters

        4. -
      -

      -then the sequence \u{hex-digit-sequence} is appended to E, where hex-digit-sequence -is the shortest hexadecimal representation of C using lower-case hexadecimal digits. -

      -
      3. -

    3. (2.2.1.3) — Otherwise, C is appended to E.

      4. -
    -
    2. -
-

-The example is not consistent with the above specification for the final code point. -U+FE0F is a single character, -is not one of the characters in Table 75, is not U+0020, has a General_Category of Nonspacing Mark (Mn) -which is neither Z nor C, has Grapheme_Extend=Yes but the prior character (U+2642) is not -formatted as an escape sequence, and is not one of an implementation-defined set of separator or non-printable characters -(for the purposes of this example; the example assumes a UTF-8 encoding). Thus, formatting for this character falls to -the last bullet point and the character should be appended as is (without translation to an escape sequence). -Since this character is a combining character, it should combine with the previous character and thus alter the -appearance of U+2642 (thus producing "♂️" instead of "♂\u{fe0f}"). -

- -

[2023-10-27; Reflector poll]

- -

-Set status to Tentatively Ready after six votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4950 plus missing editorial pieces from P2286R8. -

- -
    - -

  1. Modify the example following 22.14.6.4 [format.string.escaped] p3 as indicated:

    - -
    -

    -[Drafting note: The presented example was voted in as part of P2286R8 during the July 2022 -Virtual Meeting but is not yet accessible in the most recent working draft N4950. -

    -Note that the final character (♂️) is composed from the two code points U+2642 and U+FE0F. -] -

    -
    - - -
    -

    -

    -
    -string s6 = format("[{:?}]", "🤷‍♂️"); // s6 has value: ["🤷\u{200d}♂\u{fe0f}"]["🤷\u{200d}♂️"]
-
    - -
    -
    2. -
- - - - -

3966(i). The value_type and reference members of std::flat_(multi)map::(const_)iterator are unclear

Section: 24.6.9.1 [flat.map.overview], 24.6.10.1 [flat.multimap.overview] Status: New @@ -54272,61 +52193,6 @@

39693970(i). §[mdspan.syn] Missing definition of full_extent_t and full_extent

-

Section: 24.7.3.2 [mdspan.syn] Status: Voting - Submitter: S. B. Tam Opened: 2023-08-16 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all issues with Voting status.

-

Discussion:

-

-submdspan uses a type called full_extent_t, but there isn't a definition for that type. -

-It appears that full_extent_t (along with full_extent) was proposed in P0009 -before submdspan was moved into its own paper, and its definition failed to be included in -P2630 Submdspan. -

- -

[2023-10-27; Reflector poll]

- -

-Set status to Tentatively Ready after nine votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4958. -

- -
    - -

  1. Modify 24.7.3.2 [mdspan.syn] as indicated:

    - -
    -
    -[…]
-// 24.7.3.7 [mdspan.submdspan], submdspan creation
-template<class OffsetType, class LengthType, class StrideType>
-  struct strided_slice;
-
-template<class LayoutMapping>
-  struct submdspan_mapping_result;
-  
-struct full_extent_t { explicit full_extent_t() = default; };
-inline constexpr full_extent_t full_extent{};
-[…]
-
    -
    -
    2. -
- - - - -

3971(i). Join ranges of rvalue references with ranges of prvalues

Section: 26.7.15.2 [range.join.with.view] Status: SG9 @@ -54419,452 +52285,6 @@

39723973(i). Monadic operations should be ADL-proof

-

Section: 22.8.6.7 [expected.object.monadic], 22.5.3.7 [optional.monadic] Status: Voting - Submitter: Jiang An Opened: 2023-08-10 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all other issues in [expected.object.monadic].

-

View all issues with Voting status.

-

Discussion:

-

-LWG 3938 switched to use **this to access the value stored in std::expected. -However, as shown in LWG 3969, **this can trigger ADL and find an unwanted overload, -and thus may caused unintended behavior. -

-Current implementations behave correctly (Godbolt link): they -don't direct use **this, but use the name of the union member instead. -

-Moreover, P2407R5 will change the monadic operations of std::optional to use **this, -which is also problematic. -

- -

[2023-09-19; Wording update]

- -

-Several people preferred to replace operator*() by the corresponding union members, so this part of the proposed wording -has been adjusted, which is a rather mechanical replacement. -

- -

[2023-10-30; Reflector poll]

- -

-Set status to Tentatively Ready after five votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4958. -

- -
    - -

  1. Modify 22.8.6.7 [expected.object.monadic] as indicated:

    - -
    -

    -[Drafting note: Effectively replace all occurrences of **this by val, except for decltype.] -

    -
    - -
    -
    -template<class F> constexpr auto and_then(F&& f) &;
-template<class F> constexpr auto and_then(F&& f) const &;
-
    -
    -

    --1- Let U be remove_cvref_t<invoke_result_t<F, decltype(**this(val))>>. -

    --2- […] -

    --3- […] -

    --4- Effects: Equivalent to: -

    -
    -if (has_value())
-  return invoke(std::forward<F>(f), **thisval);
-else
-  return U(unexpect, error());
-
    -
    -
    -template<class F> constexpr auto and_then(F&& f) &&;
-template<class F> constexpr auto and_then(F&& f) const &&;
-
    -
    -

    --5- Let U be remove_cvref_t<invoke_result_t<F, decltype((std::move(**thisval))>>. -

    --6- […] -

    --7- […] -

    --8- Effects: Equivalent to: -

    -
    -if (has_value())
-  return invoke(std::forward<F>(f), std::move(**thisval));
-else
-  return U(unexpect, std::move(error()));
-
    -
    -
    -template<class F> constexpr auto or_else(F&& f) &;
-template<class F> constexpr auto or_else(F&& f) const &;
-
    -
    -

    --9- Let G be remove_cvref_t<invoke_result_t<F, decltype(error())>>. -

    --10- Constraints: is_constructible_v<T, decltype(**this(val))> is true. -

    --11- […] -

    --12- Effects: Equivalent to: -

    -
    -if (has_value())
-  return G(in_place, **thisval);
-else
-  return invoke(std::forward<F>(f), error());
-
    -
    -
    -template<class F> constexpr auto or_else(F&& f) &&;
-template<class F> constexpr auto or_else(F&& f) const &&;
-
    -
    -

    --13- Let G be remove_cvref_t<invoke_result_t<F, decltype(std::move(error()))>>. -

    --14- Constraints: is_constructible_v<T, decltype(std::move(**thisval))> is true. -

    --15- […] -

    --16- Effects: Equivalent to: -

    -
    -if (has_value())
-  return G(in_place, std::move(**thisval));
-else
-  return invoke(std::forward<F>(f), std::move(error()));
-
    -
    -
    -template<class F> constexpr auto transform(F&& f) &;
-template<class F> constexpr auto transform(F&& f) const &;
-
    -
    -

    --17- Let U be remove_cvref_t<invoke_result_t<F, decltype(**this(val))>>. -

    --18- […] -

    --19- Mandates: U is a valid value type for expected. If is_void_v<U> is false, -the declaration -

    -
    -U u(invoke(std::forward<F>(f), **thisval));
-
    -

    -is well-formed. -

    --20- Effects: -

    -
      -

    1. (20.1) — […]

      2. -

    2. (20.2) — Otherwise, if is_void_v<U> is false, returns an expected<U, E> -object whose has_val member is true and val member is direct-non-list-initialized -with invoke(std::forward<F>(f), **thisval).

      3. -

    3. (20.3) — Otherwise, evaluates invoke(std::forward<F>(f), **thisval) -and then returns expected<U, E>().

      4. -
    -
    -
    -template<class F> constexpr auto transform(F&& f) &&;
-template<class F> constexpr auto transform(F&& f) const &&;
-
    -
    -

    --21- Let U be remove_cvref_t<invoke_result_t<F, decltype(std::move(**thisval))>>. -

    --22- […] -

    --23- Mandates: U is a valid value type for expected. If is_void_v<U> is false, -the declaration -

    -
    -U u(invoke(std::forward<F>(f), std::move(**thisval)));
-
    -

    -is well-formed. -

    --24- Effects: -

    -
      -

    1. (24.1) — […]

      2. -

    2. (24.2) — Otherwise, if is_void_v<U> is false, returns an expected<U, E> -object whose has_val member is true and val member is direct-non-list-initialized -with invoke(std::forward<F>(f), std::move(**thisval)).

      3. -

    3. (24.3) — Otherwise, evaluates invoke(std::forward<F>(f), std::move(**thisval)) -and then returns expected<U, E>().

      4. -
    -
    -
    -template<class F> constexpr auto transform_error(F&& f) &;
-template<class F> constexpr auto transform_error(F&& f) const &;
-
    -
    -

    --25- Let G be remove_cvref_t<invoke_result_t<F, decltype(error())>>. -

    --26- Constraints: is_constructible_v<T, decltype(**this(val))> is true. -

    --27- Mandates: […] -

    --28- Returns: If has_value() is true, expected<T, G>(in_place, **thisval); -otherwise, an expected<T, G> object whose has_val member is false and -unex member is direct-non-list-initialized with invoke(std::forward<F>(f), error()). -

    -
    -
    -template<class F> constexpr auto transform_error(F&& f) &&;
-template<class F> constexpr auto transform_error(F&& f) const &&;
-
    -
    -

    --29- Let G be remove_cvref_t<invoke_result_t<F, decltype(std::move(error()))>>. -

    --30- Constraints: is_constructible_v<T, decltype(std::move(**thisval))> is true. -

    --31- Mandates: […] -

    --32- Returns: If has_value() is true, expected<T, G>(in_place, std::move(**thisval)); -otherwise, an expected<T, G> object whose has_val member is false and -unex member is direct-non-list-initialized with invoke(std::forward<F>(f), std::move(error())). -

    -
    -
    -
    2. - -

  2. Modify 22.5.3.7 [optional.monadic] as indicated:

    - - -
    -

    -[Drafting note: Effectively replace all occurrences of value() by *val.] -

    -
    - -
    -
    -template<class F> constexpr auto and_then(F&& f) &;
-template<class F> constexpr auto and_then(F&& f) const &;
-
    -
    -

    --1- Let U be invoke_result_t<F, decltype(value()*val)>. -

    --2- […] -

    --3- Effects: Equivalent to: -

    -
    -if (*this) {
-  return invoke(std::forward<F>(f), value()*val);
-} else {
-  return remove_cvref_t<U>();
-}
-
    -
    -
    -template<class F> constexpr auto and_then(F&& f) &&;
-template<class F> constexpr auto and_then(F&& f) const &&;
-
    -
    -

    --4- Let U be invoke_result_t<F, decltype(std::move(value()*val))>. -

    --5- […] -

    --6- Effects: Equivalent to: -

    -
    -if (*this) {
-  return invoke(std::forward<F>(f), std::move(value()*val));
-} else {
-  return remove_cvref_t<U>();
-}
-
    -
    -
    -template<class F> constexpr auto transform(F&& f) &;
-template<class F> constexpr auto transform(F&& f) const &;
-
    -
    -

    --7- Let U be remove_cv_t<invoke_result_t<F, decltype(value()*val)>>. -

    --8- Mandates: U is a non-array object type other than in_place_t or nullopt_t. The declaration -

    -
    -U u(invoke(std::forward<F>(f), value()*val));
-
    -

    -is well-formed for some invented variable u. -

    -[…] -

    --9- Returns: If *this contains a value, an optional<U> object whose contained value is -direct-non-list-initialized with invoke(std::forward<F>(f), value()*val); otherwise, -optional<U>(). -

    -
    -
    -template<class F> constexpr auto transform(F&& f) &&;
-template<class F> constexpr auto transform(F&& f) const &&;
-
    -
    -

    --10- Let U be remove_cv_t<invoke_result_t<F, decltype(std::move(value()*val))>>. -

    --11- Mandates: U is a non-array object type other than in_place_t or nullopt_t. The declaration -

    -
    -U u(invoke(std::forward<F>(f), std::move(value()*val)));
-
    -

    -is well-formed for some invented variable u. -

    -[…] -

    --12- Returns: If *this contains a value, an optional<U> object whose contained value is -direct-non-list-initialized with invoke(std::forward<F>(f), std::move(value()*val)); otherwise, -optional<U>(). -

    -
    -
    -
    3. -
- - - - - -
-

3974(i). mdspan::operator[] should not copy OtherIndexTypes

-

Section: 24.7.3.6.3 [mdspan.mdspan.members] Status: Voting - Submitter: Casey Carter Opened: 2023-08-12 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all issues with Voting status.

-

Discussion:

-

-The wording for mdspan's operator[] overloads that accept span and array is in -24.7.3.6.3 [mdspan.mdspan.members] paragraphs 5 and 6: -

-
-template<class OtherIndexType>
-  constexpr reference operator[](span<OtherIndexType, rank()> indices) const;
-template<class OtherIndexType>
-  constexpr reference operator[](const array<OtherIndexType, rank()>& indices) const;
-
-

--5- Constraints: -

-
    -

  1. (5.1) — is_convertible_v<const OtherIndexType&, index_type> is true, and

    2. -

  2. (5.2) — is_nothrow_constructible_v<index_type, const OtherIndexType&> is true.

    3. -
-

--6- Effects: Let P be a parameter pack such that -

-
-is_same_v<make_index_sequence<rank()>, index_sequence<P...>>
-
-

-is true. Equivalent to: -

-
-return operator[](as_const(indices[P])...);
-
-
-

-The equivalent code calls the other operator[] overload: -

-
-template<class... OtherIndexTypes>
-  constexpr reference operator[](OtherIndexTypes... indices) const;
-
-

-with a pack of const OtherIndexType lvalues, but we notably haven't required OtherIndexTypes to be copyable — -we only require that we can convert them to index_type. While one could argue that the use in "Effects: equivalent to" -implies a requirement of copyability, it's odd that this implicit requirement would be the only requirement for copyable -OtherIndexTypes in the spec. We could fix this by changing the operator[] overload accepting OtherIndexTypes -to take them by const&, but that would be inconsistent with virtually every other place in the spec where types -convertible to index_type are taken by-value. I think the best localized fix is to perform the conversion to index_type -in the "Effects: equivalent to" code so the actual arguments have type index_type which we know is copyable. -

- -

[2023-11-02; Reflector poll]

- -

-Set status to Tentatively Ready after eight votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4958. -

- -
    - -

  1. Modify 24.7.3.6.3 [mdspan.mdspan.members] as indicated:

    - -
    -
    -template<class OtherIndexType>
-  constexpr reference operator[](span<OtherIndexType, rank()> indices) const;
-template<class OtherIndexType>
-  constexpr reference operator[](const array<OtherIndexType, rank()>& indices) const;
-
    -
    -

    --5- Constraints: -

    -
      -

    1. (5.1) — is_convertible_v<const OtherIndexType&, index_type> is true, and

      2. -

    2. (5.2) — is_nothrow_constructible_v<index_type, const OtherIndexType&> is true.

      3. -
    -

    --6- Effects: Let P be a parameter pack such that -

    -
    -is_same_v<make_index_sequence<rank()>, index_sequence<P...>>
-
    -

    -is true. Equivalent to: -

    -
    -return operator[](extents_type::index-cast(as_const(indices[P]))...);
-
    -
    -
    - -
    2. -
- - - - -

3975(i). Specializations of basic_format_context should not be permitted

Section: 22.14.6.6 [format.context] Status: Ready @@ -54985,7 +52405,6 @@

3976active issues in [container.alloc.reqmts].

View all other issues in [container.alloc.reqmts].

View all issues with New status.

Discussion:

@@ -55912,57 +53331,6 @@

39863987(i). Including <flat_foo> doesn't provide std::begin/end

-

Section: 25.7 [iterator.range] Status: Voting - Submitter: Hewill Kang Opened: 2023-08-27 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View other active issues in [iterator.range].

-

View all other issues in [iterator.range].

-

View all issues with Voting status.

-

Discussion:

-

-It seems that 25.7 [iterator.range] should also add <flat_foo> to the list as the -latter provides a series of range access member functions such as begin/end. -

- -

[2023-11-02; Reflector poll]

- -

-Set status to Tentatively Ready after nine votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4958. -

- -
    - -

  1. Modify 25.7 [iterator.range] as indicated:

    - -
    -

    --1- In addition to being available via inclusion of the <iterator> header, the function templates in -[iterator.range] are available when any of the following headers are included: <array>, -<deque>, <flat_map>, <flat_set>, <forward_list>, -<list>, <map>, <regex>, <set>, <span>, -<string>, <string_view>, <unordered_map>, <unordered_set>, -and <vector>. -

    -
    - -
    2. - -
- - - - -

3988(i). Should as_const_view and basic_const_iterator provide base()?

Section: 25.5.3 [const.iterators], 26.7.21.2 [range.as.const.view] Status: Ready @@ -56152,83 +53520,6 @@

39893990(i). Program-defined specializations of std::tuple and std::variant can't be properly supported

-

Section: 22.4.4 [tuple.tuple], 22.6.3.1 [variant.variant.general] Status: Voting - Submitter: Jiang An Opened: 2023-08-29 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View all other issues in [tuple.tuple].

-

View all issues with Voting status.

-

Discussion:

-

-Currently, program-defined specializations of std::tuple and std::variant are not explicitly disallowed. -However, they can't be properly supported by standard library implementations, because the corresponding std::get -function templates have to inspect the implementation details of these types, and users have no way to make std::get -behave correctly for a program-defined specializations. -

-Perhaps we should explicitly disallow specializing std::tuple and std::variant. -

- -

[2023-11-02; Reflector poll]

- -

-Set status to Tentatively Ready after five votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4958. -

- -
    - -

  1. Modify 22.4.4 [tuple.tuple] as indicated:

    - -
    -
    -namespace std {
-  template<class... Types>
-  class tuple {
-    […]
-  };
-
-  […]
-}
-
    -
    -
    -

    --?- If a program declares an explicit or partial specialization of tuple, -the program is ill-formed, no diagnostic required. -

    -
    - -
    2. - -

  2. Modify 22.6.3.1 [variant.variant.general] as indicated:

    - -
    -

    -[…] -

    --3- A program that instantiates the definition of variant with no template arguments is ill-formed. -

    --?- If a program declares an explicit or partial specialization of variant, -the program is ill-formed, no diagnostic required. -

    -
    - -
    3. - -
- - - - -

3991(i). variant's move assignment should not be guaranteed to produce a valueless by exception state

Section: 22.6.3.4 [variant.assign] Status: New @@ -56942,115 +54233,6 @@

40004001(i). iota_view should provide empty

-

Section: 26.6.4.2 [range.iota.view] Status: Voting - Submitter: Hewill Kang Opened: 2023-10-27 Last modified: 2023-11-07

-

Priority: Not Prioritized -

-

View other active issues in [range.iota.view].

-

View all other issues in [range.iota.view].

-

View all issues with Voting status.

-

Discussion:

-

-When iota_view's template parameter is not an integer type and does not model advanceable, -its size member will not be provided as constraints are not satisfied. -

-If the type further fails to model the incrementable, this results in its view_interface base being -unable to synthesize a valid empty member as iota_view will just be an input_range -(demo): -

-
-#include <ranges>
-#include <vector>
-#include <iostream>
-
-int main() {
-  std::vector<int> v;
-  auto it = std::back_inserter(v);
-  auto s = std::ranges::subrange(it, std::unreachable_sentinel);
-  auto r = std::views::iota(it);
-  std::cout << s.empty() << "\n"; // 0
-  std::cout << r.empty() << "\n"; // ill-formed
-}
-
-

-This seems to be an oversight. I don't see a reason why iota_view doesn't provide empty -as it does store the start and end like subrange, in which case it's easy to tell if it's empty -just by comparing the two. -

- -

[2023-11-02; Reflector poll]

- -

-Set status to Tentatively Ready after seven votes in favour during reflector poll. -

- - - -

Proposed resolution:

-

-This wording is relative to N4964. -

- -
    - -

  1. Modify 26.6.4.2 [range.iota.view], class template iota_view synopsis, as indicated:

    - -
    -
    -namespace std::ranges {
-  […]
-  template<weakly_incrementable W, semiregular Bound = unreachable_sentinel_t>
-    requires weakly-equality-comparable-with<W, Bound> && copyable<W>
-  class iota_view : public view_interface<iota_view<W, Bound>> {
-  private:
-    […]
-    W value_ = W();                     // exposition only
-    Bound bound_ = Bound();             // exposition only
-  public:
-    […]
-    constexpr iterator begin() const;
-    constexpr auto end() const;
-    constexpr iterator end() const requires same_as<W, Bound>;
-
-    constexpr bool empty() const;
-    constexpr auto size() const requires see below;
-  };
-  […]
-}
-
    -

    -[…] -

    -
    -constexpr iterator end() const requires same_as<W, Bound>;
-
    -
    -

    --14- Effects: Equivalent to: return iterator{bound_}; -

    -
    -
    -constexpr bool empty() const;
-
    -
    -

    --?- Effects: Equivalent to: return value_ == bound_; -

    -[…] -

    -
    -
    - -
    2. - -
- - - - -

4002(i). The definition of iota_view::iterator::iterator_concept should be improved

Section: 26.6.4.3 [range.iota.iterator] Status: New diff --git a/lwg-closed.html b/lwg-closed.html index ee0bc42bb4..0d39a54545 100644 --- a/lwg-closed.html +++ b/lwg-closed.html @@ -50,7 +50,7 @@ Date: - 2023-11-13 + 2023-11-14 Project: @@ -62,7 +62,7 @@

C++ Standard Library Closed Issues List (Revision D125)

-

Revised 2023-11-13 at 13:15:08 UTC

+

Revised 2023-11-14 at 21:01:33 UTC

Reference ISO/IEC IS 14882:2020(E)

Also see:

@@ -86,23 +86,23 @@

Revision History