From a88faeeee88cd50a519d38df6bf67abc446efdf0 Mon Sep 17 00:00:00 2001 From: github-actions Date: Tue, 19 Nov 2024 16:10:39 +0000 Subject: [PATCH] Automatic update from GitHub Actions workflow --- issue2991.html | 19 +- issue3003.html | 7 +- issue3210.html | 2 +- issue3216.html | 12 +- issue3436.html | 10 +- issue3454.html | 16 +- issue3486.html | 2 +- issue3886.html | 10 +- issue3899.html | 10 +- issue3900.html | 10 +- issue3918.html | 10 +- issue4014.html | 10 +- issue4015.html | 2 +- issue4024.html | 10 +- issue4027.html | 10 +- issue4044.html | 10 +- issue4064.html | 12 +- issue4072.html | 10 +- issue4084.html | 10 +- issue4085.html | 10 +- issue4088.html | 10 +- issue4112.html | 10 +- issue4113.html | 10 +- issue4119.html | 10 +- issue4124.html | 10 +- issue4126.html | 10 +- issue4130.html | 13 +- issue4134.html | 10 +- issue4135.html | 10 +- issue4140.html | 10 +- issue4141.html | 10 +- issue4142.html | 10 +- issue4144.html | 10 +- issue4147.html | 10 +- issue4148.html | 10 +- issue4153.html | 10 +- issue4154.html | 10 +- issue4157.html | 10 +- issue4164.html | 10 +- issue4169.html | 10 +- issue4170.html | 10 +- lwg-active.html | 298 ++- lwg-closed.html | 41 +- lwg-defects.html | 41 +- lwg-immediate.html | 2 +- lwg-index-open.html | 241 +- lwg-index.html | 168 +- lwg-ready.html | 4795 +---------------------------------- lwg-status-date.html | 398 ++- lwg-status.html | 392 ++- lwg-tentative.html | 2015 +-------------- lwg-toc.html | 150 +- lwg-unresolved.html | 51 +- unresolved-index.html | 24 +- unresolved-prioritized.html | 14 +- unresolved-status-date.html | 62 +- unresolved-status.html | 62 +- unresolved-toc.html | 14 +- votable-index.html | 148 +- votable-status-date.html | 338 ++- votable-status.html | 332 ++- votable-toc.html | 138 +- 62 files changed, 1607 insertions(+), 8522 deletions(-) diff --git a/issue2991.html b/issue2991.html index df08e7f0de..33aee7416c 100644 --- a/issue2991.html +++ b/issue2991.html @@ -4,7 +4,7 @@ Issue 2991: variant copy constructor missing noexcept(see below) - + @@ -61,15 +61,15 @@
-

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

+

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

2991. variant copy constructor missing noexcept(see below)

-

Section: 22.6.3.2 [variant.ctor] Status: LEWG - Submitter: Peter Dimov Opened: 2017-06-27 Last modified: 2017-07-12

+

Section: 22.6.3.2 [variant.ctor] Status: Open + Submitter: Peter Dimov Opened: 2017-06-27 Last modified: 2024-11-19

Priority: Not Prioritized

View other active issues in [variant.ctor].

View all other issues in [variant.ctor].

-

View all issues with LEWG status.

+

View all issues with Open status.

Discussion:

The copy constructor of std::variant is not conditionally noexcept (I think @@ -94,6 +94,15 @@

2991. variant copy

Status to LEWG

+

[Wrocław 2024-11-18; LEWG approves the direction]

+ +

+In P0088R1 the copy constructor was conditionally noexcept +in the synopsis, but not the detailed description. This was pointed out +during LWG review in Jacksonville. +The approved paper, P008R3, doesn't have it in either place. +

+

Proposed resolution:

diff --git a/issue3003.html b/issue3003.html index 538670395b..c9e6bdb617 100644 --- a/issue3003.html +++ b/issue3003.html @@ -64,7 +64,7 @@

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

3003. <future> still has type-erased allocators in promise

Section: 32.10.6 [futures.promise] Status: LEWG - Submitter: Billy O'Neal III Opened: 2017-07-16 Last modified: 2024-10-02

+ Submitter: Billy O'Neal III Opened: 2017-07-16 Last modified: 2024-11-19

Priority: 2

View other active issues in [futures.promise].

@@ -186,6 +186,9 @@

3003. <future>

+

[Wrocław 2024-11-18; LEWG would prefer a paper for this]

+ +

Proposed resolution:

@@ -256,7 +259,7 @@

3003. <future>
[Drafting note: -Issue 4154(i) alters these Mandates: and Effects: +Issue 4154(i) alters these Mandates: and Effects: but the two edits should combine cleanly.]

-4- Preconditions: diff --git a/issue3210.html b/issue3210.html index 5c741613f1..0faa62a6da 100644 --- a/issue3210.html +++ b/issue3210.html @@ -179,7 +179,7 @@

3210. allocate_sharedpv is merely specified to point some storage instead of an object.

-

[2024-10-02; will be resolved by issue 3216(i).]

+

[2024-10-02; will be resolved by issue 3216(i).]

diff --git a/issue3216.html b/issue3216.html index 4c471a4ecf..40d73daaff 100644 --- a/issue3216.html +++ b/issue3216.html @@ -4,7 +4,7 @@ Issue 3216: Rebinding the allocator before calling construct/destroy in allocate_shared - + @@ -61,15 +61,15 @@
-

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

+

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.

3216. Rebinding the allocator before calling construct/destroy in allocate_shared

-

Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Tentatively Ready - Submitter: Billy O'Neal III Opened: 2019-06-11 Last modified: 2024-10-02

+

Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Voting + Submitter: Billy O'Neal III Opened: 2019-06-11 Last modified: 2024-11-19

Priority: 3

View other active issues in [util.smartptr.shared.create].

View all other issues in [util.smartptr.shared.create].

-

View all issues with Tentatively Ready status.

+

View all issues with Voting status.

Discussion:

The new allocate_shared wording says we need to rebind the allocator back to T's @@ -243,7 +243,7 @@

3216. Rebinding the allocator b

  • […]

  • [Drafting note: -Issue 4024(i) will add make_shared_for_overwrite +Issue 4024(i) will add make_shared_for_overwrite and allocate_shared_for_overwrite to (7.11) but that doesn't conflict with this next edit.]

    (7.11) — When a (sub)object of non-array type U that was initialized by diff --git a/issue3436.html b/issue3436.html index acb26cacca..5537f83454 100644 --- a/issue3436.html +++ b/issue3436.html @@ -4,7 +4,7 @@ Issue 3436: std::construct_at should support arrays - + @@ -61,15 +61,15 @@

    -

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

    +

    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.

    3436. std::construct_at should support arrays

    -

    Section: 26.11.8 [specialized.construct] Status: Ready - Submitter: Jonathan Wakely Opened: 2020-04-29 Last modified: 2024-06-24

    +

    Section: 26.11.8 [specialized.construct] Status: Voting + Submitter: Jonathan Wakely Opened: 2020-04-29 Last modified: 2024-11-19

    Priority: 2

    View other active issues in [specialized.construct].

    View all other issues in [specialized.construct].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    std::construct_at is ill-formed for array types, because the type of the new-expression is T diff --git a/issue3454.html b/issue3454.html index 5fda69ddb6..386858c9bd 100644 --- a/issue3454.html +++ b/issue3454.html @@ -4,7 +4,7 @@ Issue 3454: pointer_traits::pointer_to should be constexpr - + @@ -61,14 +61,14 @@

    -

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

    +

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

    3454. pointer_traits::pointer_to should be constexpr

    -

    Section: 20.2.3 [pointer.traits] Status: LEWG - Submitter: Alisdair Meredith Opened: 2020-06-21 Last modified: 2022-07-21

    +

    Section: 20.2.3 [pointer.traits] Status: Open + Submitter: Alisdair Meredith Opened: 2020-06-21 Last modified: 2024-11-19

    Priority: Not Prioritized

    View all other issues in [pointer.traits].

    -

    View all issues with LEWG status.

    +

    View all issues with Open status.

    Discussion:

    Trying to implement a constexpr std::list (inspired by Tim Song's @@ -100,6 +100,12 @@

    3454. pointer_traits::poi constexpr basic_string can support fancy pointers or SSO, but not both.

    +

    [Wrocław 2024-11-18; LEWG approves the direction]

    + +

    +Should there be an Annex C entry noting that program-defined specializations +need to add constexpr to be conforming? +

    Proposed resolution:

    diff --git a/issue3486.html b/issue3486.html index 95e2b6d847..2e003aecf0 100644 --- a/issue3486.html +++ b/issue3486.html @@ -140,7 +140,7 @@

    3486. is_constructible<

    -There may be some interaction with LWG 3436(i). +There may be some interaction with LWG 3436(i).

    diff --git a/issue3886.html b/issue3886.html index a5178f9f75..c47363af39 100644 --- a/issue3886.html +++ b/issue3886.html @@ -4,7 +4,7 @@ Issue 3886: Monad mo' problems - + @@ -61,15 +61,15 @@
    -

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

    +

    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.

    3886. Monad mo' problems

    -

    Section: 22.5.3.1 [optional.optional.general], 22.8.6.1 [expected.object.general] Status: Tentatively Ready - Submitter: Casey Carter Opened: 2023-02-13 Last modified: 2024-09-19

    +

    Section: 22.5.3.1 [optional.optional.general], 22.8.6.1 [expected.object.general] Status: Voting + Submitter: Casey Carter Opened: 2023-02-13 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [optional.optional.general].

    View all other issues in [optional.optional.general].

    -

    View all issues with Tentatively Ready status.

    +

    View all issues with Voting status.

    Discussion:

    While implementing P2505R5 "Monadic Functions for std::expected" we found it odd that diff --git a/issue3899.html b/issue3899.html index 7b5a4afc12..91715fcb58 100644 --- a/issue3899.html +++ b/issue3899.html @@ -4,7 +4,7 @@ Issue 3899: co_yielding elements of an lvalue generator is unnecessarily inefficient - + @@ -61,15 +61,15 @@

    -

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

    +

    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.

    3899. co_yielding elements of an lvalue generator is unnecessarily inefficient

    -

    Section: 25.8.5 [coro.generator.promise] Status: Ready - Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-06-28

    +

    Section: 25.8.5 [coro.generator.promise] Status: Voting + Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [coro.generator.promise].

    View all other issues in [coro.generator.promise].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    Consider: diff --git a/issue3900.html b/issue3900.html index 7d63adf883..a9beda079d 100644 --- a/issue3900.html +++ b/issue3900.html @@ -6,7 +6,7 @@ should not be constrained - + @@ -63,16 +63,16 @@

    -

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

    +

    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.

    3900. The allocator_arg_t overloads of generator::promise_type::operator new should not be constrained

    -

    Section: 25.8.5 [coro.generator.promise] Status: Ready - Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-06-28

    +

    Section: 25.8.5 [coro.generator.promise] Status: Voting + Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [coro.generator.promise].

    View all other issues in [coro.generator.promise].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    When the allocator is not type-erased, the allocator_arg_t overloads of diff --git a/issue3918.html b/issue3918.html index ab19c5b6cb..751bdad4d6 100644 --- a/issue3918.html +++ b/issue3918.html @@ -4,7 +4,7 @@ Issue 3918: std::uninitialized_move/_n and guaranteed copy elision - + @@ -61,13 +61,13 @@

    -

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

    +

    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.

    3918. std::uninitialized_move/_n and guaranteed copy elision

    -

    Section: 26.11.6 [uninitialized.move] Status: Ready - Submitter: Jiang An Opened: 2023-04-04 Last modified: 2024-06-26

    +

    Section: 26.11.6 [uninitialized.move] Status: Voting + Submitter: Jiang An Opened: 2023-04-04 Last modified: 2024-11-19

    Priority: 3

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    Currently std::move is unconditionally used in std::uninitialized_move and std::uninitialized_move_n, diff --git a/issue4014.html b/issue4014.html index 1f58da491a..5ecd8ac22a 100644 --- a/issue4014.html +++ b/issue4014.html @@ -4,7 +4,7 @@ Issue 4014: LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code - + @@ -61,14 +61,14 @@

    -

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

    +

    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.

    4014. LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code

    -

    Section: 29.5.4.4 [rand.eng.sub] Status: Ready - Submitter: Matt Stephanson Opened: 2023-11-15 Last modified: 2024-10-09

    +

    Section: 29.5.4.4 [rand.eng.sub] Status: Voting + Submitter: Matt Stephanson Opened: 2023-11-15 Last modified: 2024-11-19

    Priority: 2

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

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    Issue 3809(i) pointed out that subtract_with_carry_engine<T> can be seeded with values diff --git a/issue4015.html b/issue4015.html index dc11af6e94..ba8ae00f0d 100644 --- a/issue4015.html +++ b/issue4015.html @@ -875,7 +875,7 @@

    4015. LWG 3973 broke cons During telecon review it was suggested to replace 22.5.3.1 [optional.optional.general] p1 and p2. On the reflector Daniel requested to keep the "additional storage" prohibition, -so that will be addressed by issue 4141(i) instead. +so that will be addressed by issue 4141(i) instead.

    [2024-10-02; Jonathan tweaks proposed resolution]

    diff --git a/issue4024.html b/issue4024.html index 51a80f88fc..03164378ce 100644 --- a/issue4024.html +++ b/issue4024.html @@ -4,7 +4,7 @@ Issue 4024: Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite - + @@ -61,15 +61,15 @@
    -

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

    +

    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.

    4024. Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite

    -

    Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Ready - Submitter: Jiang An Opened: 2023-12-16 Last modified: 2024-08-21

    +

    Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Voting + Submitter: Jiang An Opened: 2023-12-16 Last modified: 2024-11-19

    Priority: 2

    View other active issues in [util.smartptr.shared.create].

    View all other issues in [util.smartptr.shared.create].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    Currently, only destructions of non-array (sub)objects created in std::make_shared and std::allocate_shared diff --git a/issue4027.html b/issue4027.html index dbf8f3d353..733c262d6f 100644 --- a/issue4027.html +++ b/issue4027.html @@ -4,7 +4,7 @@ Issue 4027: possibly-const-range should prefer returning const R& - + @@ -61,15 +61,15 @@

    -

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

    +

    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.

    4027. possibly-const-range should prefer returning const R&

    -

    Section: 25.2 [ranges.syn] Status: Ready - Submitter: Hewill Kang Opened: 2023-12-17 Last modified: 2024-06-28

    +

    Section: 25.2 [ranges.syn] Status: Voting + Submitter: Hewill Kang Opened: 2023-12-17 Last modified: 2024-11-19

    Priority: 2

    View other active issues in [ranges.syn].

    View all other issues in [ranges.syn].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    possibly-const-range currently only returns const R& when R does not diff --git a/issue4044.html b/issue4044.html index d52caa57bb..d481187590 100644 --- a/issue4044.html +++ b/issue4044.html @@ -4,7 +4,7 @@ Issue 4044: Confusing requirements for std::print on POSIX platforms - + @@ -61,15 +61,15 @@

    -

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

    +

    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.

    4044. Confusing requirements for std::print on POSIX platforms

    -

    Section: 31.7.10 [print.fun] Status: Ready - Submitter: Jonathan Wakely Opened: 2024-01-24 Last modified: 2024-06-24

    +

    Section: 31.7.10 [print.fun] Status: Voting + Submitter: Jonathan Wakely Opened: 2024-01-24 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [print.fun].

    View all other issues in [print.fun].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    The effects for vprintf_unicode say: diff --git a/issue4064.html b/issue4064.html index 85e62184da..0eff6a56df 100644 --- a/issue4064.html +++ b/issue4064.html @@ -4,7 +4,7 @@ Issue 4064: Clarify that std::launder is not needed when using the result of std::memcpy - + @@ -61,13 +61,13 @@

    -

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

    +

    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.

    4064. Clarify that std::launder is not needed when using the result of std::memcpy

    -

    Section: 27.5.1 [cstring.syn] Status: Ready - Submitter: Jan Schultke Opened: 2024-04-05 Last modified: 2024-06-28

    +

    Section: 27.5.1 [cstring.syn] Status: Voting + Submitter: Jan Schultke Opened: 2024-04-05 Last modified: 2024-11-19

    Priority: 3

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

     int x = 0;
@@ -125,6 +125,8 @@ 
    4064. Clarify that std::l
 
 
    [St. Louis 2024-06-28; LWG: move to Ready]
    
 
+
    [Wrocław 2024-11-18; approved by Core (again)]
    
+
 
 
 
diff --git a/issue4072.html b/issue4072.html
index 0307471de4..30997f87fe 100644
--- a/issue4072.html
+++ b/issue4072.html
@@ -4,7 +4,7 @@
 
 Issue 4072: std::optional comparisons: constrain harder
 
-
+
 
 
 
@@ -61,14 +61,14 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Ready status.
    
+
    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.
    
 
    4072. std::optional comparisons: constrain harder
    
-
    Section: 22.5.8 [optional.comp.with.t] Status: Ready
- Submitter: Jonathan Wakely Opened: 2024-04-19 Last modified: 2024-08-21
    
+
    Section: 22.5.8 [optional.comp.with.t] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-04-19 Last modified: 2024-11-19
    
 
    Priority: 1
 
    
 
    View all other issues in [optional.comp.with.t].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 P2944R3 added constraints to std::optional's comparisons, e.g.
diff --git a/issue4084.html b/issue4084.html
index 5508c300b2..0d44915b84 100644
--- a/issue4084.html
+++ b/issue4084.html
@@ -4,7 +4,7 @@
 
 Issue 4084: std::fixed ignores std::uppercase
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4084. std::fixed ignores std::uppercase
    
-
    Section: 28.3.4.3.3.3 [facet.num.put.virtuals] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-04-30 Last modified: 2024-09-19
    
+
    Section: 28.3.4.3.3.3 [facet.num.put.virtuals] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-04-30 Last modified: 2024-11-19
    
 
    Priority: 3
 
    
 
    View other active issues in [facet.num.put.virtuals].
    
 
    View all other issues in [facet.num.put.virtuals].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 In Table 114 – Floating-point conversions [tab:facet.num.put.fp]
diff --git a/issue4085.html b/issue4085.html
index b0f4321805..2a1875ceae 100644
--- a/issue4085.html
+++ b/issue4085.html
@@ -4,7 +4,7 @@
 
 Issue 4085: ranges::generate_random's helper lambda should specify the return type
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Ready status.
    
+
    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.
    
 
    4085. ranges::generate_random's helper lambda should specify the return type
    
-
    Section: 26.12.2 [alg.rand.generate] Status: Ready
- Submitter: Hewill Kang Opened: 2024-04-28 Last modified: 2024-10-09
    
+
    Section: 26.12.2 [alg.rand.generate] Status: Voting
+ Submitter: Hewill Kang Opened: 2024-04-28 Last modified: 2024-11-19
    
 
    Priority: 2
 
    
 
    View other active issues in [alg.rand.generate].
    
 
    View all other issues in [alg.rand.generate].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The non-specialized case of generate_random(r, g, d) would call
diff --git a/issue4088.html b/issue4088.html
index e6b47f1e35..bb5dc81335 100644
--- a/issue4088.html
+++ b/issue4088.html
@@ -4,7 +4,7 @@
 
 Issue 4088: println ignores the locale imbued in std::ostream
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4088. println ignores the locale imbued in std::ostream
    
-
    Section: 31.7.6.3.5 [ostream.formatted.print] Status: Tentatively Ready
- Submitter: Jens Maurer Opened: 2024-04-30 Last modified: 2024-10-03
    
+
    Section: 31.7.6.3.5 [ostream.formatted.print] Status: Voting
+ Submitter: Jens Maurer Opened: 2024-04-30 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [ostream.formatted.print].
    
 
    View all other issues in [ostream.formatted.print].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 31.7.6.3.5 [ostream.formatted.print] specifies that std::print uses the locale
diff --git a/issue4112.html b/issue4112.html
index 513b0f7704..a1caacbc86 100644
--- a/issue4112.html
+++ b/issue4112.html
@@ -4,7 +4,7 @@
 
 Issue 4112: has-arrow should required operator->() to be const-qualified
 
-
+
 
 
 
@@ -61,13 +61,13 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Ready status.
    
+
    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.
    
 
    4112. has-arrow should required operator->() to be const-qualified
    
-
    Section: 25.5.2 [range.utility.helpers] Status: Ready
- Submitter: Hewill Kang Opened: 2024-06-22 Last modified: 2024-06-24
    
+
    Section: 25.5.2 [range.utility.helpers] Status: Voting
+ Submitter: Hewill Kang Opened: 2024-06-22 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The helper concept has-arrow in 25.5.2 [range.utility.helpers] does not 
diff --git a/issue4113.html b/issue4113.html
index 7a9e1ecfdf..b1dad35574 100644
--- a/issue4113.html
+++ b/issue4113.html
@@ -4,7 +4,7 @@
 
 Issue 4113: Disallow has_unique_object_representations<Incomplete[]>
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4113. Disallow has_unique_object_representations<Incomplete[]>
    
-
    Section: 21.3.5.4 [meta.unary.prop] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-06-25 Last modified: 2024-08-02
    
+
    Section: 21.3.5.4 [meta.unary.prop] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-06-25 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [meta.unary.prop].
    
 
    View all other issues in [meta.unary.prop].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The type completeness requirements for has_unique_object_representations say:
diff --git a/issue4119.html b/issue4119.html
index 8048e89496..5538293799 100644
--- a/issue4119.html
+++ b/issue4119.html
@@ -4,7 +4,7 @@
 
 Issue 4119: generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4119. generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed
    
-
    Section: 25.8.5 [coro.generator.promise] Status: Tentatively Ready
- Submitter: Hewill Kang Opened: 2024-07-11 Last modified: 2024-08-02
    
+
    Section: 25.8.5 [coro.generator.promise] Status: Voting
+ Submitter: Hewill Kang Opened: 2024-07-11 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [coro.generator.promise].
    
 
    View all other issues in [coro.generator.promise].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The nested coroutine is specified to return generator<yielded, ranges::range_value_t<R>, Alloc> 
diff --git a/issue4124.html b/issue4124.html
index 9c8e36667d..96af38f35a 100644
--- a/issue4124.html
+++ b/issue4124.html
@@ -4,7 +4,7 @@
 
 Issue 4124: Cannot format zoned_time with resolution coarser than seconds
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4124. Cannot format zoned_time with resolution coarser than seconds
    
-
    Section: 30.12 [time.format] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-07-26 Last modified: 2024-08-02
    
+
    Section: 30.12 [time.format] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-07-26 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [time.format].
    
 
    View all other issues in [time.format].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The
diff --git a/issue4126.html b/issue4126.html
index 29925dfc5c..d05796a147 100644
--- a/issue4126.html
+++ b/issue4126.html
@@ -4,7 +4,7 @@
 
 Issue 4126: Some feature-test macros for fully freestanding features are not yet marked freestanding
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4126. Some feature-test macros for fully freestanding features are not yet marked freestanding
    
-
    Section: 17.3.2 [version.syn] Status: Tentatively Ready
- Submitter: Jiang An Opened: 2024-07-24 Last modified: 2024-08-02
    
+
    Section: 17.3.2 [version.syn] Status: Voting
+ Submitter: Jiang An Opened: 2024-07-24 Last modified: 2024-11-19
    
 
    Priority: 2
 
    
 
    View other active issues in [version.syn].
    
 
    View all other issues in [version.syn].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 Currently (N4986), it's a bit weird in 17.3.2 [version.syn] that some feature-test
diff --git a/issue4130.html b/issue4130.html
index 20152aa8c1..a6c2c70de3 100644
--- a/issue4130.html
+++ b/issue4130.html
@@ -4,7 +4,7 @@
 
 Issue 4130: Preconditions for std::launder might be overly strict
 
-
+
 
 
 
@@ -61,14 +61,14 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
    
+
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.
    
 
    4130. Preconditions for std::launder might be overly strict
    
-
    Section: 17.6.5 [ptr.launder] Status: New
- Submitter: Jiang An Opened: 2024-07-30 Last modified: 2024-10-02
    
+
    Section: 17.6.5 [ptr.launder] Status: Open
+ Submitter: Jiang An Opened: 2024-07-30 Last modified: 2024-11-19
    
 
    Priority: 3
 
    
 
    View all other issues in [ptr.launder].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 From issue cplusplus/draft#4553
@@ -86,6 +86,9 @@ 
    4130. Preconditions for s
 Set priority to 3 after reflector poll. Needs review by Core.
 
    
 
+
    [Wrocław 2024-11-18; approved by Core]
    
+
+
 
 
 
    Proposed resolution:
    
diff --git a/issue4134.html b/issue4134.html
index 4eac9b8b55..ff55eedb55 100644
--- a/issue4134.html
+++ b/issue4134.html
@@ -4,7 +4,7 @@
 
 Issue 4134: Issue with Philox algorithm specification
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Ready status.
    
+
    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.
    
 
    4134. Issue with Philox algorithm specification
    
-
    Section: 29.5.4.5 [rand.eng.philox] Status: Ready
- Submitter: Ilya A. Burylov Opened: 2024-08-06 Last modified: 2024-08-21
    
+
    Section: 29.5.4.5 [rand.eng.philox] Status: Voting
+ Submitter: Ilya A. Burylov Opened: 2024-08-06 Last modified: 2024-11-19
    
 
    Priority: 1
 
    
 
    View other active issues in [rand.eng.philox].
    
 
    View all other issues in [rand.eng.philox].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The P2075R6 proposal introduced the Philox engine and described the algorithm closely 
diff --git a/issue4135.html b/issue4135.html
index e659e527b5..0ecca12cfc 100644
--- a/issue4135.html
+++ b/issue4135.html
@@ -6,7 +6,7 @@
   bool
 
-
+
 
 
 
@@ -63,14 +63,14 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4135. The helper lambda of std::erase for list should specify return type as
   bool
    
-
    Section: 23.3.7.7 [forward.list.erasure], 23.3.9.6 [list.erasure] Status: Tentatively Ready
- Submitter: Hewill Kang Opened: 2024-08-07 Last modified: 2024-08-21
    
+
    Section: 23.3.7.7 [forward.list.erasure], 23.3.9.6 [list.erasure] Status: Voting
+ Submitter: Hewill Kang Opened: 2024-08-07 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 std::erase for list is specified to return
diff --git a/issue4140.html b/issue4140.html
index db1fa83c0d..5cb0b649c8 100644
--- a/issue4140.html
+++ b/issue4140.html
@@ -4,7 +4,7 @@
 
 Issue 4140: Useless default constructors for bit reference types
 
-
+
 
 
 
@@ -61,13 +61,13 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4140. Useless default constructors for bit reference types
    
-
    Section: 22.9.2.1 [template.bitset.general], 23.3.12.1 [vector.bool.pspc] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-21 Last modified: 2024-09-18
    
+
    Section: 22.9.2.1 [template.bitset.general], 23.3.12.1 [vector.bool.pspc] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-08-21 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The standard shows a private default constructor for
diff --git a/issue4141.html b/issue4141.html
index 7504fd1e39..0941d28dc0 100644
--- a/issue4141.html
+++ b/issue4141.html
@@ -4,7 +4,7 @@
 
 Issue 4141: Improve prohibitions on "additional storage"
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4141. Improve prohibitions on "additional storage"
    
-
    Section: 22.5.3.1 [optional.optional.general], 22.6.3.1 [variant.variant.general], 22.8.6.1 [expected.object.general], 22.8.7.1 [expected.void.general] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-22 Last modified: 2024-09-18
    
+
    Section: 22.5.3.1 [optional.optional.general], 22.6.3.1 [variant.variant.general], 22.8.6.1 [expected.object.general], 22.8.7.1 [expected.void.general] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-08-22 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [optional.optional.general].
    
 
    View all other issues in [optional.optional.general].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 This issue was split out from issue 4015(i).
diff --git a/issue4142.html b/issue4142.html
index 59a9fa8f28..562f900512 100644
--- a/issue4142.html
+++ b/issue4142.html
@@ -4,7 +4,7 @@
 
 Issue 4142: format_parse_context::check_dynamic_spec should require at least one type
 
-
+
 
 
 
@@ -61,14 +61,14 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4142. format_parse_context::check_dynamic_spec should require at least one type
    
-
    Section: 28.5.6.6 [format.parse.ctx] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-28 Last modified: 2024-09-18
    
+
    Section: 28.5.6.6 [format.parse.ctx] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-08-28 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View all other issues in [format.parse.ctx].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The Mandates: conditions for format_parse_context::check_dynamic_spec
diff --git a/issue4144.html b/issue4144.html
index a5df85046d..c8681d9ab4 100644
--- a/issue4144.html
+++ b/issue4144.html
@@ -4,7 +4,7 @@
 
 Issue 4144: Disallow unique_ptr<T&, D>
 
-
+
 
 
 
@@ -61,14 +61,14 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4144. Disallow unique_ptr<T&, D>
    
-
    Section: 20.3.1.3.1 [unique.ptr.single.general] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-30 Last modified: 2024-11-13
    
+
    Section: 20.3.1.3.1 [unique.ptr.single.general] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-08-30 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View all other issues in [unique.ptr.single.general].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 It seems that we currently allow nonsensical specializations of unique_ptr
diff --git a/issue4147.html b/issue4147.html
index ec412522c6..986820d278 100644
--- a/issue4147.html
+++ b/issue4147.html
@@ -4,7 +4,7 @@
 
 Issue 4147: Precondition on inplace_vector::emplace
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4147. Precondition on inplace_vector::emplace
    
-
    Section: 23.2.4 [sequence.reqmts] Status: Tentatively Ready
- Submitter: Arthur O'Dwyer Opened: 2024-08-26 Last modified: 2024-09-18
    
+
    Section: 23.2.4 [sequence.reqmts] Status: Voting
+ Submitter: Arthur O'Dwyer Opened: 2024-08-26 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [sequence.reqmts].
    
 
    View all other issues in [sequence.reqmts].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 Inserting into the middle of an inplace_vector, just like inserting into the middle of a 
diff --git a/issue4148.html b/issue4148.html
index a89447b8de..592f2dda46 100644
--- a/issue4148.html
+++ b/issue4148.html
@@ -4,7 +4,7 @@
 
 Issue 4148: unique_ptr::operator* should not allow dangling references
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4148. unique_ptr::operator* should not allow dangling references
    
-
    Section: 20.3.1.3.5 [unique.ptr.single.observers] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-09-02 Last modified: 2024-09-18
    
+
    Section: 20.3.1.3.5 [unique.ptr.single.observers] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-09-02 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [unique.ptr.single.observers].
    
 
    View all other issues in [unique.ptr.single.observers].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 If unique_ptr<T,D>::element_type* and D::pointer
diff --git a/issue4153.html b/issue4153.html
index 4cde278728..98eacae7ca 100644
--- a/issue4153.html
+++ b/issue4153.html
@@ -4,7 +4,7 @@
 
 Issue 4153: Fix extra "-1" for philox_engine::max()
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4153. Fix extra "-1" for philox_engine::max()
    
-
    Section: 29.5.4.5 [rand.eng.philox] Status: Tentatively Ready
- Submitter: Ruslan Arutyunyan Opened: 2024-09-18 Last modified: 2024-10-02
    
+
    Section: 29.5.4.5 [rand.eng.philox] Status: Voting
+ Submitter: Ruslan Arutyunyan Opened: 2024-09-18 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [rand.eng.philox].
    
 
    View all other issues in [rand.eng.philox].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 There is a typo in philox_engine wording that makes "-1" two times
diff --git a/issue4154.html b/issue4154.html
index 8f1d5a492a..b6093254ef 100644
--- a/issue4154.html
+++ b/issue4154.html
@@ -4,7 +4,7 @@
 
 Issue 4154: The Mandates for std::packaged_task's constructor from a callable entity should consider decaying
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Ready status.
    
+
    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.
    
 
    4154. The Mandates for std::packaged_task's constructor from a callable entity should consider decaying
    
-
    Section: 32.10.10.2 [futures.task.members] Status: Ready
- Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-10-09
    
+
    Section: 32.10.10.2 [futures.task.members] Status: Voting
+ Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-11-19
    
 
    Priority: 3
 
    
 
    View other active issues in [futures.task.members].
    
 
    View all other issues in [futures.task.members].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 Currently, 32.10.10.2 [futures.task.members]/3 states:
diff --git a/issue4157.html b/issue4157.html
index 0e5d0da2aa..c01d6064fe 100644
--- a/issue4157.html
+++ b/issue4157.html
@@ -4,7 +4,7 @@
 
 Issue 4157: The resolution of LWG3465 was damaged by P2167R3
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4157. The resolution of LWG3465 was damaged by P2167R3
    
-
    Section: 17.11.6 [cmp.alg] Status: Tentatively Ready
- Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-10-02
    
+
    Section: 17.11.6 [cmp.alg] Status: Voting
+ Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [cmp.alg].
    
 
    View all other issues in [cmp.alg].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 In the resolution of LWG 3465(i),
diff --git a/issue4164.html b/issue4164.html
index ab7919a7a9..56a80302b0 100644
--- a/issue4164.html
+++ b/issue4164.html
@@ -4,7 +4,7 @@
 
 Issue 4164: Missing guarantees for forward_list modifiers
 
-
+
 
 
 
@@ -61,14 +61,14 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Ready status.
    
+
    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.
    
 
    4164. Missing guarantees for forward_list modifiers
    
-
    Section: 23.3.7.5 [forward.list.modifiers] Status: Ready
- Submitter: Jonathan Wakely Opened: 2024-10-05 Last modified: 2024-10-09
    
+
    Section: 23.3.7.5 [forward.list.modifiers] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-10-05 Last modified: 2024-11-19
    
 
    Priority: 3
 
    
 
    View all other issues in [forward.list.modifiers].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The new std::list members added by P1206R7,
diff --git a/issue4169.html b/issue4169.html
index 46c8f38370..9998f8f727 100644
--- a/issue4169.html
+++ b/issue4169.html
@@ -4,7 +4,7 @@
 
 Issue 4169: std::atomic<T>'s default constructor should be constrained
 
-
+
 
 
 
@@ -61,15 +61,15 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4169. std::atomic<T>'s default constructor should be constrained
    
-
    Section: 32.5.8.2 [atomics.types.operations] Status: Tentatively Ready
- Submitter: Giuseppe D'Angelo Opened: 2024-10-15 Last modified: 2024-11-13
    
+
    Section: 32.5.8.2 [atomics.types.operations] Status: Voting
+ Submitter: Giuseppe D'Angelo Opened: 2024-10-15 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [atomics.types.operations].
    
 
    View all other issues in [atomics.types.operations].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The current wording for std::atomic's default constructor in
diff --git a/issue4170.html b/issue4170.html
index c0465e32e4..5c05a83db3 100644
--- a/issue4170.html
+++ b/issue4170.html
@@ -4,7 +4,7 @@
 
 Issue 4170: contiguous_iterator should require to_address(I{})
 
-
+
 
 
 
@@ -61,14 +61,14 @@
 
 
 
    
-
    This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Ready status.
    
+
    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.
    
 
    4170. contiguous_iterator should require to_address(I{})
    
-
    Section: 24.3.4.14 [iterator.concept.contiguous] Status: Tentatively Ready
- Submitter: Casey Carter Opened: 2024-11-01 Last modified: 2024-11-13
    
+
    Section: 24.3.4.14 [iterator.concept.contiguous] Status: Voting
+ Submitter: Casey Carter Opened: 2024-11-01 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View all other issues in [iterator.concept.contiguous].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The design intent of the contiguous_iterator concept is that iterators can be converted
diff --git a/lwg-active.html b/lwg-active.html
index 48e958bfc2..a953d5d38e 100644
--- a/lwg-active.html
+++ b/lwg-active.html
@@ -67,7 +67,7 @@
 
 
   Date:
-  2024-11-18
+  2024-11-19
 
 
   Project:
@@ -79,7 +79,7 @@
 
 
 
    C++ Standard Library Active Issues List (Revision D125)
    
-
    Revised 2024-11-18 at 13:27:23 UTC
+
    Revised 2024-11-19 at 16:10:33 UTC
 
    
   
    Reference ISO/IEC IS 14882:2020(E)
    
   
    Also see:
    
@@ -199,25 +199,24 @@ 
    Revision History

    -4- Preconditions: @@ -28216,7 +28227,7 @@

    32103216(i).]

    +

    [2024-10-02; will be resolved by issue 3216(i).]

    @@ -28418,13 +28429,13 @@

    32153216(i). Rebinding the allocator before calling construct/destroy in allocate_shared

    -

    Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Tentatively Ready - Submitter: Billy O'Neal III Opened: 2019-06-11 Last modified: 2024-10-02

    +

    Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Voting + Submitter: Billy O'Neal III Opened: 2019-06-11 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [util.smartptr.shared.create].

    View all other issues in [util.smartptr.shared.create].

    -

    View all issues with Tentatively Ready status.

    +

    View all issues with Voting status.

    Discussion:

    The new allocate_shared wording says we need to rebind the allocator back to T's @@ -28598,7 +28609,7 @@

    3216

    [Drafting note: -Issue 4024(i) will add make_shared_for_overwrite +Issue 4024(i) will add make_shared_for_overwrite and allocate_shared_for_overwrite to (7.11) but that doesn't conflict with this next edit.]

    (7.11) — When a (sub)object of non-array type U that was initialized by @@ -32594,13 +32605,13 @@

    34293436(i). std::construct_at should support arrays

    -

    Section: 26.11.8 [specialized.construct] Status: Ready - Submitter: Jonathan Wakely Opened: 2020-04-29 Last modified: 2024-06-24

    +

    Section: 26.11.8 [specialized.construct] Status: Voting + Submitter: Jonathan Wakely Opened: 2020-04-29 Last modified: 2024-11-19

    Priority: 2

    View other active issues in [specialized.construct].

    View all other issues in [specialized.construct].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    std::construct_at is ill-formed for array types, because the type of the new-expression is T @@ -33179,12 +33190,12 @@

    34513454(i). pointer_traits::pointer_to should be constexpr

    -

    Section: 20.2.3 [pointer.traits] Status: LEWG - Submitter: Alisdair Meredith Opened: 2020-06-21 Last modified: 2022-07-21

    +

    Section: 20.2.3 [pointer.traits] Status: Open + Submitter: Alisdair Meredith Opened: 2020-06-21 Last modified: 2024-11-19

    Priority: Not Prioritized

    View all other issues in [pointer.traits].

    -

    View all issues with LEWG status.

    +

    View all issues with Open status.

    Discussion:

    Trying to implement a constexpr std::list (inspired by Tim Song's @@ -33216,6 +33227,12 @@

    3454Proposed resolution:

    @@ -34034,7 +34051,7 @@

    34863436(i). +There may be some interaction with LWG 3436(i).

    @@ -46929,13 +46946,13 @@

    38833886(i). Monad mo' problems

    -

    Section: 22.5.3.1 [optional.optional.general], 22.8.6.1 [expected.object.general] Status: Tentatively Ready - Submitter: Casey Carter Opened: 2023-02-13 Last modified: 2024-09-19

    +

    Section: 22.5.3.1 [optional.optional.general], 22.8.6.1 [expected.object.general] Status: Voting + Submitter: Casey Carter Opened: 2023-02-13 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [optional.optional.general].

    View all other issues in [optional.optional.general].

    -

    View all issues with Tentatively Ready status.

    +

    View all issues with Voting status.

    Discussion:

    While implementing P2505R5 "Monadic Functions for std::expected" we found it odd that @@ -48208,13 +48225,13 @@

    38983899(i). co_yielding elements of an lvalue generator is unnecessarily inefficient

    -

    Section: 25.8.5 [coro.generator.promise] Status: Ready - Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-06-28

    +

    Section: 25.8.5 [coro.generator.promise] Status: Voting + Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [coro.generator.promise].

    View all other issues in [coro.generator.promise].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    Consider: @@ -48357,13 +48374,13 @@

    38993900(i). The allocator_arg_t overloads of generator::promise_type::operator new should not be constrained

    -

    Section: 25.8.5 [coro.generator.promise] Status: Ready - Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-06-28

    +

    Section: 25.8.5 [coro.generator.promise] Status: Voting + Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [coro.generator.promise].

    View all other issues in [coro.generator.promise].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    When the allocator is not type-erased, the allocator_arg_t overloads of @@ -49238,11 +49255,11 @@

    39173918(i). std::uninitialized_move/_n and guaranteed copy elision

    -

    Section: 26.11.6 [uninitialized.move] Status: Ready - Submitter: Jiang An Opened: 2023-04-04 Last modified: 2024-06-26

    +

    Section: 26.11.6 [uninitialized.move] Status: Voting + Submitter: Jiang An Opened: 2023-04-04 Last modified: 2024-11-19

    Priority: 3

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    Currently std::move is unconditionally used in std::uninitialized_move and std::uninitialized_move_n, @@ -55099,12 +55116,12 @@

    40104014(i). LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code

    -

    Section: 29.5.4.4 [rand.eng.sub] Status: Ready - Submitter: Matt Stephanson Opened: 2023-11-15 Last modified: 2024-10-09

    +

    Section: 29.5.4.4 [rand.eng.sub] Status: Voting + Submitter: Matt Stephanson Opened: 2023-11-15 Last modified: 2024-11-19

    Priority: 2

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

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    Issue 3809(i) pointed out that subtract_with_carry_engine<T> can be seeded with values @@ -56136,7 +56153,7 @@

    4015[optional.optional.general] p1 and p2. On the reflector Daniel requested to keep the "additional storage" prohibition, -so that will be addressed by issue 4141(i) instead. +so that will be addressed by issue 4141(i) instead.

    [2024-10-02; Jonathan tweaks proposed resolution]

    @@ -57511,13 +57528,13 @@

    40224024(i). Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite

    -

    Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Ready - Submitter: Jiang An Opened: 2023-12-16 Last modified: 2024-08-21

    +

    Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Voting + Submitter: Jiang An Opened: 2023-12-16 Last modified: 2024-11-19

    Priority: 2

    View other active issues in [util.smartptr.shared.create].

    View all other issues in [util.smartptr.shared.create].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    Currently, only destructions of non-array (sub)objects created in std::make_shared and std::allocate_shared @@ -57733,13 +57750,13 @@

    40264027(i). possibly-const-range should prefer returning const R&

    -

    Section: 25.2 [ranges.syn] Status: Ready - Submitter: Hewill Kang Opened: 2023-12-17 Last modified: 2024-06-28

    +

    Section: 25.2 [ranges.syn] Status: Voting + Submitter: Hewill Kang Opened: 2023-12-17 Last modified: 2024-11-19

    Priority: 2

    View other active issues in [ranges.syn].

    View all other issues in [ranges.syn].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    possibly-const-range currently only returns const R& when R does not @@ -59034,13 +59051,13 @@

    40424044(i). Confusing requirements for std::print on POSIX platforms

    -

    Section: 31.7.10 [print.fun] Status: Ready - Submitter: Jonathan Wakely Opened: 2024-01-24 Last modified: 2024-06-24

    +

    Section: 31.7.10 [print.fun] Status: Voting + Submitter: Jonathan Wakely Opened: 2024-01-24 Last modified: 2024-11-19

    Priority: 3

    View other active issues in [print.fun].

    View all other issues in [print.fun].

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

    The effects for vprintf_unicode say: @@ -60831,11 +60848,11 @@

    40634064(i). Clarify that std::launder is not needed when using the result of std::memcpy

    -

    Section: 27.5.1 [cstring.syn] Status: Ready - Submitter: Jan Schultke Opened: 2024-04-05 Last modified: 2024-06-28

    +

    Section: 27.5.1 [cstring.syn] Status: Voting + Submitter: Jan Schultke Opened: 2024-04-05 Last modified: 2024-11-19

    Priority: 3

    -

    View all issues with Ready status.

    +

    View all issues with Voting status.

    Discussion:

     int x = 0;
@@ -60893,6 +60910,8 @@ 
    406440704072(i). std::optional comparisons: constrain harder
    
-
    Section: 22.5.8 [optional.comp.with.t] Status: Ready
- Submitter: Jonathan Wakely Opened: 2024-04-19 Last modified: 2024-08-21
    
+
    Section: 22.5.8 [optional.comp.with.t] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-04-19 Last modified: 2024-11-19
    
 
    Priority: 1
 
    
 
    View all other issues in [optional.comp.with.t].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 P2944R3 added constraints to std::optional's comparisons, e.g.
@@ -62003,13 +62022,13 @@ 
    40814084(i). std::fixed ignores std::uppercase
    
-
    Section: 28.3.4.3.3.3 [facet.num.put.virtuals] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-04-30 Last modified: 2024-09-19
    
+
    Section: 28.3.4.3.3.3 [facet.num.put.virtuals] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-04-30 Last modified: 2024-11-19
    
 
    Priority: 3
 
    
 
    View other active issues in [facet.num.put.virtuals].
    
 
    View all other issues in [facet.num.put.virtuals].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 In Table 114 – Floating-point conversions [tab:facet.num.put.fp]
@@ -62120,13 +62139,13 @@ 
    40844085(i). ranges::generate_random's helper lambda should specify the return type
    
-
    Section: 26.12.2 [alg.rand.generate] Status: Ready
- Submitter: Hewill Kang Opened: 2024-04-28 Last modified: 2024-10-09
    
+
    Section: 26.12.2 [alg.rand.generate] Status: Voting
+ Submitter: Hewill Kang Opened: 2024-04-28 Last modified: 2024-11-19
    
 
    Priority: 2
 
    
 
    View other active issues in [alg.rand.generate].
    
 
    View all other issues in [alg.rand.generate].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The non-specialized case of generate_random(r, g, d) would call
@@ -62400,13 +62419,13 @@ 
    40874088(i). println ignores the locale imbued in std::ostream
    
-
    Section: 31.7.6.3.5 [ostream.formatted.print] Status: Tentatively Ready
- Submitter: Jens Maurer Opened: 2024-04-30 Last modified: 2024-10-03
    
+
    Section: 31.7.6.3.5 [ostream.formatted.print] Status: Voting
+ Submitter: Jens Maurer Opened: 2024-04-30 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [ostream.formatted.print].
    
 
    View all other issues in [ostream.formatted.print].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 31.7.6.3.5 [ostream.formatted.print] specifies that std::print uses the locale
@@ -64756,11 +64775,11 @@ 
    41114112(i). has-arrow should required operator->() to be const-qualified
    
-
    Section: 25.5.2 [range.utility.helpers] Status: Ready
- Submitter: Hewill Kang Opened: 2024-06-22 Last modified: 2024-06-24
    
+
    Section: 25.5.2 [range.utility.helpers] Status: Voting
+ Submitter: Hewill Kang Opened: 2024-06-22 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The helper concept has-arrow in 25.5.2 [range.utility.helpers] does not 
@@ -64807,13 +64826,13 @@ 
    41124113(i). Disallow has_unique_object_representations<Incomplete[]>
    
-
    Section: 21.3.5.4 [meta.unary.prop] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-06-25 Last modified: 2024-08-02
    
+
    Section: 21.3.5.4 [meta.unary.prop] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-06-25 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [meta.unary.prop].
    
 
    View all other issues in [meta.unary.prop].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The type completeness requirements for has_unique_object_representations say:
@@ -65321,13 +65340,13 @@ 
    41184119(i). generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed
    
-
    Section: 25.8.5 [coro.generator.promise] Status: Tentatively Ready
- Submitter: Hewill Kang Opened: 2024-07-11 Last modified: 2024-08-02
    
+
    Section: 25.8.5 [coro.generator.promise] Status: Voting
+ Submitter: Hewill Kang Opened: 2024-07-11 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [coro.generator.promise].
    
 
    View all other issues in [coro.generator.promise].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The nested coroutine is specified to return generator<yielded, ranges::range_value_t<R>, Alloc> 
@@ -65697,13 +65716,13 @@ 
    41234124(i). Cannot format zoned_time with resolution coarser than seconds
    
-
    Section: 30.12 [time.format] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-07-26 Last modified: 2024-08-02
    
+
    Section: 30.12 [time.format] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-07-26 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [time.format].
    
 
    View all other issues in [time.format].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The
@@ -65896,13 +65915,13 @@ 
    41254126(i). Some feature-test macros for fully freestanding features are not yet marked freestanding
    
-
    Section: 17.3.2 [version.syn] Status: Tentatively Ready
- Submitter: Jiang An Opened: 2024-07-24 Last modified: 2024-08-02
    
+
    Section: 17.3.2 [version.syn] Status: Voting
+ Submitter: Jiang An Opened: 2024-07-24 Last modified: 2024-11-19
    
 
    Priority: 2
 
    
 
    View other active issues in [version.syn].
    
 
    View all other issues in [version.syn].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 Currently (N4986), it's a bit weird in 17.3.2 [version.syn] that some feature-test
@@ -66903,12 +66922,12 @@ 
    41294130(i). Preconditions for std::launder might be overly strict
    
-
    Section: 17.6.5 [ptr.launder] Status: New
- Submitter: Jiang An Opened: 2024-07-30 Last modified: 2024-10-02
    
+
    Section: 17.6.5 [ptr.launder] Status: Open
+ Submitter: Jiang An Opened: 2024-07-30 Last modified: 2024-11-19
    
 
    Priority: 3
 
    
 
    View all other issues in [ptr.launder].
    
-
    View all issues with New status.
    
+
    View all issues with Open status.
    
 
    Discussion:
    
 
    
 From issue cplusplus/draft#4553
@@ -66926,6 +66945,9 @@ 
    4130Proposed resolution:
    
@@ -67385,13 +67407,13 @@ 
    41334134(i). Issue with Philox algorithm specification
    
-
    Section: 29.5.4.5 [rand.eng.philox] Status: Ready
- Submitter: Ilya A. Burylov Opened: 2024-08-06 Last modified: 2024-08-21
    
+
    Section: 29.5.4.5 [rand.eng.philox] Status: Voting
+ Submitter: Ilya A. Burylov Opened: 2024-08-06 Last modified: 2024-11-19
    
 
    Priority: 1
 
    
 
    View other active issues in [rand.eng.philox].
    
 
    View all other issues in [rand.eng.philox].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The P2075R6 proposal introduced the Philox engine and described the algorithm closely 
@@ -67636,11 +67658,11 @@ 
    41344135(i). The helper lambda of std::erase for list should specify return type as
   bool
    
-
    Section: 23.3.7.7 [forward.list.erasure], 23.3.9.6 [list.erasure] Status: Tentatively Ready
- Submitter: Hewill Kang Opened: 2024-08-07 Last modified: 2024-08-21
    
+
    Section: 23.3.7.7 [forward.list.erasure], 23.3.9.6 [list.erasure] Status: Voting
+ Submitter: Hewill Kang Opened: 2024-08-07 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 std::erase for list is specified to return
@@ -68305,11 +68327,11 @@ 
    41394140(i). Useless default constructors for bit reference types
    
-
    Section: 22.9.2.1 [template.bitset.general], 23.3.12.1 [vector.bool.pspc] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-21 Last modified: 2024-09-18
    
+
    Section: 22.9.2.1 [template.bitset.general], 23.3.12.1 [vector.bool.pspc] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-08-21 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The standard shows a private default constructor for
@@ -68417,13 +68439,13 @@ 
    41404141(i). Improve prohibitions on "additional storage"
    
-
    Section: 22.5.3.1 [optional.optional.general], 22.6.3.1 [variant.variant.general], 22.8.6.1 [expected.object.general], 22.8.7.1 [expected.void.general] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-22 Last modified: 2024-09-18
    
+
    Section: 22.5.3.1 [optional.optional.general], 22.6.3.1 [variant.variant.general], 22.8.6.1 [expected.object.general], 22.8.7.1 [expected.void.general] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-08-22 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [optional.optional.general].
    
 
    View all other issues in [optional.optional.general].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 This issue was split out from issue 4015(i).
@@ -68585,12 +68607,12 @@ 
    41414142(i). format_parse_context::check_dynamic_spec should require at least one type
    
-
    Section: 28.5.6.6 [format.parse.ctx] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-28 Last modified: 2024-09-18
    
+
    Section: 28.5.6.6 [format.parse.ctx] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-08-28 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View all other issues in [format.parse.ctx].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The Mandates: conditions for format_parse_context::check_dynamic_spec
@@ -68753,12 +68775,12 @@ 
    41434144(i). Disallow unique_ptr<T&, D>
    
-
    Section: 20.3.1.3.1 [unique.ptr.single.general] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-30 Last modified: 2024-11-13
    
+
    Section: 20.3.1.3.1 [unique.ptr.single.general] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-08-30 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View all other issues in [unique.ptr.single.general].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 It seems that we currently allow nonsensical specializations of unique_ptr
@@ -68971,13 +68993,13 @@ 
    41464147(i). Precondition on inplace_vector::emplace
    
-
    Section: 23.2.4 [sequence.reqmts] Status: Tentatively Ready
- Submitter: Arthur O'Dwyer Opened: 2024-08-26 Last modified: 2024-09-18
    
+
    Section: 23.2.4 [sequence.reqmts] Status: Voting
+ Submitter: Arthur O'Dwyer Opened: 2024-08-26 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [sequence.reqmts].
    
 
    View all other issues in [sequence.reqmts].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 Inserting into the middle of an inplace_vector, just like inserting into the middle of a 
@@ -69036,13 +69058,13 @@ 
    41474148(i). unique_ptr::operator* should not allow dangling references
    
-
    Section: 20.3.1.3.5 [unique.ptr.single.observers] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-09-02 Last modified: 2024-09-18
    
+
    Section: 20.3.1.3.5 [unique.ptr.single.observers] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-09-02 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [unique.ptr.single.observers].
    
 
    View all other issues in [unique.ptr.single.observers].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 If unique_ptr<T,D>::element_type* and D::pointer
@@ -69387,13 +69409,13 @@ 
    41524153(i). Fix extra "-1" for philox_engine::max()
    
-
    Section: 29.5.4.5 [rand.eng.philox] Status: Tentatively Ready
- Submitter: Ruslan Arutyunyan Opened: 2024-09-18 Last modified: 2024-10-02
    
+
    Section: 29.5.4.5 [rand.eng.philox] Status: Voting
+ Submitter: Ruslan Arutyunyan Opened: 2024-09-18 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [rand.eng.philox].
    
 
    View all other issues in [rand.eng.philox].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 There is a typo in philox_engine wording that makes "-1" two times
@@ -69445,13 +69467,13 @@ 
    41534154(i). The Mandates for std::packaged_task's constructor from a callable entity should consider decaying
    
-
    Section: 32.10.10.2 [futures.task.members] Status: Ready
- Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-10-09
    
+
    Section: 32.10.10.2 [futures.task.members] Status: Voting
+ Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-11-19
    
 
    Priority: 3
 
    
 
    View other active issues in [futures.task.members].
    
 
    View all other issues in [futures.task.members].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 Currently, 32.10.10.2 [futures.task.members]/3 states:
@@ -69724,13 +69746,13 @@ 
    41564157(i). The resolution of LWG3465 was damaged by P2167R3
    
-
    Section: 17.11.6 [cmp.alg] Status: Tentatively Ready
- Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-10-02
    
+
    Section: 17.11.6 [cmp.alg] Status: Voting
+ Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [cmp.alg].
    
 
    View all other issues in [cmp.alg].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 In the resolution of LWG 3465(i),
@@ -70242,12 +70264,12 @@ 
    41634164(i). Missing guarantees for forward_list modifiers
    
-
    Section: 23.3.7.5 [forward.list.modifiers] Status: Ready
- Submitter: Jonathan Wakely Opened: 2024-10-05 Last modified: 2024-10-09
    
+
    Section: 23.3.7.5 [forward.list.modifiers] Status: Voting
+ Submitter: Jonathan Wakely Opened: 2024-10-05 Last modified: 2024-11-19
    
 
    Priority: 3
 
    
 
    View all other issues in [forward.list.modifiers].
    
-
    View all issues with Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The new std::list members added by P1206R7,
@@ -70923,13 +70945,13 @@ 
    41684169(i). std::atomic<T>'s default constructor should be constrained
    
-
    Section: 32.5.8.2 [atomics.types.operations] Status: Tentatively Ready
- Submitter: Giuseppe D'Angelo Opened: 2024-10-15 Last modified: 2024-11-13
    
+
    Section: 32.5.8.2 [atomics.types.operations] Status: Voting
+ Submitter: Giuseppe D'Angelo Opened: 2024-10-15 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View other active issues in [atomics.types.operations].
    
 
    View all other issues in [atomics.types.operations].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The current wording for std::atomic's default constructor in
@@ -71019,12 +71041,12 @@ 
    41694170(i). contiguous_iterator should require to_address(I{})
    
-
    Section: 24.3.4.14 [iterator.concept.contiguous] Status: Tentatively Ready
- Submitter: Casey Carter Opened: 2024-11-01 Last modified: 2024-11-13
    
+
    Section: 24.3.4.14 [iterator.concept.contiguous] Status: Voting
+ Submitter: Casey Carter Opened: 2024-11-01 Last modified: 2024-11-19
    
 
    Priority: Not Prioritized
 
    
 
    View all other issues in [iterator.concept.contiguous].
    
-
    View all issues with Tentatively Ready status.
    
+
    View all issues with Voting status.
    
 
    Discussion:
    
 
    
 The design intent of the contiguous_iterator concept is that iterators can be converted
diff --git a/lwg-closed.html b/lwg-closed.html
index 182b65dc54..c3a00c0b95 100644
--- a/lwg-closed.html
+++ b/lwg-closed.html
@@ -67,7 +67,7 @@
 
 
   Date:
-  2024-11-18
+  2024-11-19
 
 
   Project:
@@ -79,7 +79,7 @@
 
 
 
    C++ Standard Library Closed Issues List (Revision D125)
    
-
    Revised 2024-11-18 at 13:27:23 UTC
+
    Revised 2024-11-19 at 16:10:33 UTC
 
    
   
    Reference ISO/IEC IS 14882:2020(E)
    
   
    Also see:
    
@@ -103,25 +103,24 @@ 
    Revision History
    
 
      
 
    • D125: 2023-06-09 Post-Varna
        
 
      • Summary:
          
-
        • 561 open issues, up by 131.
          • 
+
        • 563 open issues, up by 133.
          • 
 
        • 3092 closed issues, up by 92.
          • 
-
        • 41 reassigned issues, up by 5.
          • 
+
        • 39 reassigned issues, up by 3.
          • 
 
        • 3694 issues total, up by 228.
          • 
 
        • 
 
      • Details:
@@ -750,7 +749,7 @@ 
        Revision History
        
 
      • Added the following Tentatively Ready issue: 3001.
        • 
 
      • Added the following 14 New issues: 2983, 2984, 2986, 2987, 2989, 2990, 2994, 2995, 2997, 2999, 3000, 3002, 3003, 3004.
        • 
-
      • Added the following 3 LEWG issues: 2985, 2991, 2996.
        • 
+
      • Added the following 3 LEWG issues: 2985, 2991, 2996.
        • 
 
      • Added the following NAD issue: 2992.
        • 
 
      • Changed the following 19 issues to Ready (from New): 2870, 2935, 2941, 2944, 2945, 2948, 2950, 2952, 2953, 2964, 2965, 2972, 2976, 2977, 2978, 2979, 2980, 2981, 2982.
        • 
 
      • Changed the following issue to Ready (from LEWG): 2779.
        • 
diff --git a/lwg-defects.html b/lwg-defects.html
index d764920ac1..7c58730537 100644
--- a/lwg-defects.html
+++ b/lwg-defects.html
@@ -67,7 +67,7 @@
 
 
   Date:
-  2024-11-18
+  2024-11-19
 
 
   Project:
@@ -79,7 +79,7 @@
 
 
 
        C++ Standard Library Defect Reports and Accepted Issues (Revision D125)
        
-
        Revised 2024-11-18 at 13:27:23 UTC
+
        Revised 2024-11-19 at 16:10:33 UTC
 
        
   
        Reference ISO/IEC IS 14882:2020(E)
        
   
        Also see:
        
@@ -104,25 +104,24 @@ 
        Revision History
        
 
          
 
        • D125: 2023-06-09 Post-Varna
            
 
          • Summary:
              
-
            • 561 open issues, up by 131.
              • 
+
            • 563 open issues, up by 133.
              • 
 
            • 3092 closed issues, up by 92.
              • 
-
            • 41 reassigned issues, up by 5.
              • 
+
            • 39 reassigned issues, up by 3.
              • 
 
            • 3694 issues total, up by 228.
              • 
 
            • 
 
          • Details:
@@ -751,7 +750,7 @@ 
            Revision History
            
 
          • Added the following Tentatively Ready issue: 3001.
            • 
 
          • Added the following 14 New issues: 2983, 2984, 2986, 2987, 2989, 2990, 2994, 2995, 2997, 2999, 3000, 3002, 3003, 3004.
            • 
-
          • Added the following 3 LEWG issues: 2985, 2991, 2996.
            • 
+
          • Added the following 3 LEWG issues: 2985, 2991, 2996.
            • 
 
          • Added the following NAD issue: 2992.
            • 
 
          • Changed the following 19 issues to Ready (from New): 2870, 2935, 2941, 2944, 2945, 2948, 2950, 2952, 2953, 2964, 2965, 2972, 2976, 2977, 2978, 2979, 2980, 2981, 2982.
            • 
 
          • Changed the following issue to Ready (from LEWG): 2779.
            • 
diff --git a/lwg-immediate.html b/lwg-immediate.html
index c9b637142e..c12a6369a5 100644
--- a/lwg-immediate.html
+++ b/lwg-immediate.html
@@ -62,7 +62,7 @@ 
            C++ Standard Library Issues Resolved Directly In [INSERT CURRENT MEETING HER
 
 
 Date:
-Revised 2024-11-18 at 13:27:23 UTC
+Revised 2024-11-19 at 16:10:33 UTC
 
 
 
diff --git a/lwg-index-open.html b/lwg-index-open.html
index 6494bf0576..ccba3780dc 100644
--- a/lwg-index-open.html
+++ b/lwg-index-open.html
@@ -66,7 +66,7 @@ 
            Index by Section
            
 
            This document is the Index by Section for the Library Active Issues List.
            
 
            Index by Section (non-Ready active issues only)
            
 
            (view all issues)
            
-
            Revised 2024-11-18 at 13:27:23 UTC
+
            Revised 2024-11-19 at 16:10:33 UTC
 
            Section 3 (2 issues)
            
 
            (view all issues)
            
 
@@ -544,7 +544,7 @@ 
            Section 16 (43 issues)
            
 
            
 
            
 
            
-
            Section 17 (32 issues)
            
+
            Section 17 (30 issues)
            
 
            (view all issues)
            
 
@@ -566,18 +566,9 @@ 
            Section 17 (32 issues)
            
-
-
-
-
-
-
-
-
-
-
+
@@ -685,8 +676,8 @@ 
            Section 17 (32 issues)
            
-
-
+
+
@@ -768,18 +759,9 @@ 
            Section 17 (32 issues)
            
-
-
-
-
-
-
-
-
-
-
+
@@ -992,7 +974,7 @@ 
            Section 19 (8 issues)
            
 
            
 
 
            
 
            4126(i)Tentatively Ready17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestandingYes2
            
 3931(i)
 New17.3.2 [version.syn]17.3.2 [version.syn]
 Too many paper bump __cpp_lib_ranges
 Yes
 3
 
 
            
 
            4130(i)New4130(i)Open
 17.6.5 [ptr.launder]
 Preconditions for std::launder might be overly strict
 Yes
 
 
            
 
            4157(i)Tentatively Ready17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R3Yes
            
 3932(i)
 New17.11.6 [cmp.alg]17.11.6 [cmp.alg]
 Expression-equivalence is sometimes unimplementable when passing prvalue expressions to comparison CPOs
 No
 3
 
 
            
 
            
-
            Section 20 (25 issues)
            
+
            Section 20 (22 issues)
            
 
            (view all issues)
            
 
@@ -1005,8 +987,8 @@ 
            Section 20 (25 issues)
            
-
-
+
+
@@ -1104,27 +1086,9 @@ 
            Section 20 (25 issues)
            
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
@@ -1178,19 +1142,10 @@ 
            Section 20 (25 issues)
            
-
-
-
-
-
-
-
-
-
-
+
@@ -1234,7 +1189,7 @@ 
            Section 20 (25 issues)
            
 
            
   Duplicates
 
            
 
            3454(i)LEWG3454(i)Open
 20.2.3 [pointer.traits]
 pointer_traits::pointer_to should be constexpr
 Yes
 
 
            
 
            4144(i)Tentatively Ready20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D>Yes
            4148(i)Tentatively Ready20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling referencesYes
            
 3911(i)
 New20.3.1.3.5 [unique.ptr.single.observers]20.3.1.3.5 [unique.ptr.single.observers]
 unique_ptr's operator* is missing a mandate
 Yes
 3
 
 
            
 
            3216(i)Tentatively Ready20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_sharedYes3
            
 3210(i)
 New20.3.2.2.7 [util.smartptr.shared.create]20.3.2.2.7 [util.smartptr.shared.create]
 allocate_shared is inconsistent about removing const from the pointer
 passed to allocator construct and destroy
 Yes
 
 
            
 
            
-
            Section 21 (21 issues)
            
+
            Section 21 (20 issues)
            
 
            (view all issues)
            
 
@@ -1303,18 +1258,9 @@ 
            Section 21 (21 issues)
            
-
-
-
-
-
-
-
-
-
-
+
@@ -1440,7 +1386,7 @@ 
            Section 21 (21 issues)
            
 
            
 
 
            
 
            4113(i)Tentatively Ready21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]>Yes
            
 3967(i)
 New21.3.5.4 [meta.unary.prop]21.3.5.4 [meta.unary.prop]
 The specification for std::is_nothrow_* traits may be ambiguous in some cases involving noexcept(false)
 No
 
 
 
            
 
            
-
            Section 22 (50 issues)
            
+
            Section 22 (47 issues)
            
 
            (view all issues)
            
 
@@ -1597,24 +1543,6 @@ 
            Section 22 (50 issues)
            
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@@ -1696,21 +1624,21 @@ 
            Section 22 (50 issues)
            
-
+
-
+
-
+
-
-
+
+
-
+
-
+
@@ -1786,15 +1714,6 @@ 
            Section 22 (50 issues)
            
-
-
-
-
-
-
-
-
-
@@ -1903,7 +1822,7 @@ 
            Section 22 (50 issues)
            
 
            
 
 
            
 
            3886(i)Tentatively Ready22.5.3.1 [optional.optional.general]Monad mo' problemsYes3
            4141(i)Tentatively Ready22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage"Yes
            
 2811(i)
 New
 22.5.3.2 [optional.ctor]
 
 
            
 
            2833(i)2991(i)
 Open
 22.6.3.2 [variant.ctor]Library needs to specify what it means when it declares a function constexprvariant copy constructor missing noexcept(see below)
 Yes2
 
 
            
 
            2991(i)LEWG2833(i)Open
 22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Library needs to specify what it means when it declares a function constexpr
 Yes2
 
 
            
 
            
 
 
            
 
            4140(i)Tentatively Ready22.9.2.1 [template.bitset.general]Useless default constructors for bit reference typesYes
            
 3805(i)
 New
 22.10 [function.objects]
 
 
            
 
            
-
            Section 23 (57 issues)
            
+
            Section 23 (55 issues)
            
 
            (view all issues)
            
 
@@ -1990,18 +1909,9 @@ 
            Section 23 (57 issues)
            
-
-
-
-
-
-
-
-
-
-
+
@@ -2226,17 +2136,6 @@ 
            Section 23 (57 issues)
            
-
-
-
-
-
-
-
-
-
@@ -2437,7 +2336,7 @@ 
            Section 23 (57 issues)
            
 
            
 
 
            
 
            4147(i)Tentatively Ready23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplaceYes
            
 3297(i)
 New23.2.4 [sequence.reqmts]23.2.4 [sequence.reqmts]
 Useless sequence container requirement
 Yes
 3
 
 
            
 
            4135(i)Tentatively Ready23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as
-  boolYes
            
 3758(i)
 New
 
 
            
 
            
-
            Section 24 (40 issues)
            
+
            Section 24 (39 issues)
            
 
            (view all issues)
            
 
@@ -2522,15 +2421,6 @@ 
            Section 24 (40 issues)
            
-
-
-
-
-
-
-
-
-
@@ -2814,7 +2704,7 @@ 
            Section 24 (40 issues)
            
 
            
 
 
            
 
            4170(i)Tentatively Ready24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{})Yes
            
 484(i)
 Open
 24.3.5.3 [input.iterators]
 
 
            
 
            
-
            Section 25 (62 issues)
            
+
            Section 25 (61 issues)
            
 
            (view all issues)
            
 
@@ -3368,15 +3258,6 @@ 
            Section 25 (62 issues)
            
-
-
-
-
-
-
-
-
-
@@ -3881,7 +3762,7 @@ 
            Section 27 (18 issues)
            
 
            
 
 
            
 
            4119(i)Tentatively Ready25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formedYes
            
 4057(i)
 New
 25.8.6 [coro.generator.iterator]
 
 
            
 
            
-
            Section 28 (52 issues)
            
+
            Section 28 (50 issues)
            
 
            (view all issues)
            
 
@@ -3975,18 +3856,9 @@ 
            Section 28 (52 issues)
            
-
-
-
-
-
-
-
-
-
-
+
@@ -4155,15 +4027,6 @@ 
            Section 28 (52 issues)
            
-
-
-
-
-
-
-
-
-
@@ -4366,7 +4229,7 @@ 
            Section 28 (52 issues)
            
 
            
 
 
            
 
            4084(i)Tentatively Ready28.3.4.3.3.3 [facet.num.put.virtuals]std::fixed ignores std::uppercaseYes3
            
 2703(i)
 New28.3.4.3.3.3 [facet.num.put.virtuals]28.3.4.3.3.3 [facet.num.put.virtuals]
 No provision for fill-padding when boolalpha is set
 No
 3
 
 
            
 
            4142(i)Tentatively Ready28.5.6.6 [format.parse.ctx]format_parse_context::check_dynamic_spec should require at least one typeYes
            
 4107(i)
 New
 28.5.7.4 [format.range.fmtmap]
 
 
            
 
            
-
            Section 29 (20 issues)
            
+
            Section 29 (19 issues)
            
 
            (view all issues)
            
 
@@ -4433,15 +4296,6 @@ 
            Section 29 (20 issues)
            
-
-
-
-
-
-
-
-
-
@@ -4561,7 +4415,7 @@ 
            Section 29 (20 issues)
            
 
            
 
 
            
 
            4153(i)Tentatively Ready29.5.4.5 [rand.eng.philox]Fix extra "-1" for philox_engine::max()Yes
            
 3402(i)
 New
 29.5.9.3.4 [rand.dist.bern.negbin]
 
 
            
 
            
-
            Section 30 (18 issues)
            
+
            Section 30 (17 issues)
            
 
            (view all issues)
            
 
@@ -4637,18 +4491,9 @@ 
            Section 30 (18 issues)
            
-
-
-
-
-
-
-
-
-
-
+
@@ -4738,7 +4583,7 @@ 
            Section 30 (18 issues)
            
 
            
 
 
            
 
            4124(i)Tentatively Ready30.12 [time.format]Cannot format zoned_time with resolution coarser than secondsYes
            
 4118(i)
 New30.12 [time.format]30.12 [time.format]
 How should duration formatters format custom rep types?
 Yes
 3
 
 
            
 
            
-
            Section 31 (34 issues)
            
+
            Section 31 (33 issues)
            
 
            (view all issues)
            
 
@@ -4850,19 +4695,10 @@ 
            Section 31 (34 issues)
            
-
-
-
-
-
-
-
-
-
-
+
@@ -5059,7 +4895,7 @@ 
            Section 31 (34 issues)
            
 
            
 
 
            
 
            4088(i)Tentatively Ready31.7.6.3.5 [ostream.formatted.print]println ignores the locale imbued in std::ostreamYes
            
 4039(i)
 New31.7.6.3.5 [ostream.formatted.print]31.7.6.3.5 [ostream.formatted.print]
 §[ostream.formatted.print]: Inappropriate usage of badbit in definition of 
 vprint_unicode/vprint_nonunicode
 Yes
 
 
            
 
            
-
            Section 32 (42 issues)
            
+
            Section 32 (41 issues)
            
 
            (view all issues)
            
 
@@ -5261,18 +5097,9 @@ 
            Section 32 (42 issues)
            
-
-
-
-
-
-
-
-
-
-
+
diff --git a/lwg-index.html b/lwg-index.html
index d0f8dde64f..2f5e1374c8 100644
--- a/lwg-index.html
+++ b/lwg-index.html
@@ -66,7 +66,7 @@ 
            Index by Section
            This document is the Index by Section for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List.
            Index by Section
            (view only non-Ready open issues)
            
-
            Revised 2024-11-18 at 13:27:23 UTC
+
            Revised 2024-11-19 at 16:10:33 UTC
 
            Section 2 (2 issues)
            
 
            
 
 
            
 
            4169(i)Tentatively Ready32.5.8.2 [atomics.types.operations]std::atomic<T>'s default constructor should be constrainedYes
            
 3417(i)
 SG132.5.8.2 [atomics.types.operations]32.5.8.2 [atomics.types.operations]
 Missing volatile atomic deprecations
 Yes
 3
 
 
 
 
            
@@ -2449,8 +2449,8 @@ 
            Section 17 (168 issues)
            
-
-
+
+
@@ -3090,8 +3090,8 @@ 
            Section 17 (168 issues)
            
-
-
+
+
@@ -3560,8 +3560,8 @@ 
            Section 17 (168 issues)
            
-
-
+
+
@@ -4447,8 +4447,8 @@ 
            Section 20 (207 issues)
            
-
-
+
+
@@ -4954,8 +4954,8 @@ 
            Section 20 (207 issues)
            
-
-
+
+
@@ -5091,8 +5091,8 @@ 
            Section 20 (207 issues)
            
-
-
+
+
@@ -5651,21 +5651,21 @@ 
            Section 20 (207 issues)
            
-
-
+
+
-
+
-
+
-
-
+
+
-
+
-
+
@@ -6562,8 +6562,8 @@ 
            Section 21 (109 issues)
            
-
-
+
+
@@ -8315,8 +8315,8 @@ 
            Section 22 (325 issues)
            
-
-
+
+
@@ -8324,8 +8324,8 @@ 
            Section 22 (325 issues)
            
-
-
+
+
@@ -8459,8 +8459,8 @@ 
            Section 22 (325 issues)
            
-
-
+
+
@@ -8571,21 +8571,21 @@ 
            Section 22 (325 issues)
            
-
+
-
+
-
+
-
-
+
+
-
+
-
+
@@ -9023,8 +9023,8 @@ 
            Section 22 (325 issues)
            
-
-
+
+
@@ -10757,8 +10757,8 @@ 
            Section 23 (374 issues)
            
-
-
+
+
@@ -11947,8 +11947,8 @@ 
            Section 23 (374 issues)
            
-
-
+
+
@@ -12092,8 +12092,8 @@ 
            Section 23 (374 issues)
            
-
+  bool (Status: Voting)">4135(i)
+
@@ -14074,8 +14074,8 @@ 
            Section 24 (205 issues)
            
-
-
+
+
@@ -15478,8 +15478,8 @@ 
            Section 25 (229 issues)
            
-
-
+
+
@@ -15748,8 +15748,8 @@ 
            Section 25 (229 issues)
            
-
-
+
+
@@ -17485,8 +17485,8 @@ 
            Section 25 (229 issues)
            
-
-
+
+
@@ -17495,8 +17495,8 @@ 
            Section 25 (229 issues)
            
-
+should not be constrained (Status: Voting)">3900(i)
+
@@ -17505,8 +17505,8 @@ 
            Section 25 (229 issues)
            
-
-
+
+
@@ -19231,8 +19231,8 @@ 
            Section 26 (194 issues)
            
-
-
+
+
@@ -19249,8 +19249,8 @@ 
            Section 26 (194 issues)
            
-
-
+
+
@@ -19276,8 +19276,8 @@ 
            Section 26 (194 issues)
            
-
-
+
+
@@ -20694,8 +20694,8 @@ 
            Section 27 (150 issues)
            
-
-
+
+
@@ -21654,8 +21654,8 @@ 
            Section 28 (278 issues)
            
-
-
+
+
@@ -22340,8 +22340,8 @@ 
            Section 28 (278 issues)
            
-
-
+
+
@@ -23833,8 +23833,8 @@ 
            Section 29 (180 issues)
            
-
-
+
+
@@ -23860,8 +23860,8 @@ 
            Section 29 (180 issues)
            
-
-
+
+
@@ -23869,8 +23869,8 @@ 
            Section 29 (180 issues)
            
-
-
+
+
@@ -25449,8 +25449,8 @@ 
            Section 30 (90 issues)
            
-
-
+
+
@@ -27139,8 +27139,8 @@ 
            Section 31 (318 issues)
            
-
-
+
+
@@ -27330,8 +27330,8 @@ 
            Section 31 (318 issues)
            
-
-
+
+
@@ -29412,8 +29412,8 @@ 
            Section 32 (276 issues)
            
-
-
+
+
@@ -30991,8 +30991,8 @@ 
            Section 32 (276 issues)
            
-
-
+
+
diff --git a/lwg-ready.html b/lwg-ready.html
index 77b9be49ad..1c198104a8 100644
--- a/lwg-ready.html
+++ b/lwg-ready.html
@@ -62,7 +62,7 @@ 
            C++ Standard Library Issues to be moved in [INSERT CURRENT MEETING HERE]
            
-
@@ -75,4798 +75,5 @@ 
            C++ Standard Library Issues to be moved in [INSERT CURRENT MEETING HERE]
            
 
            
 
 
            
 
            4126(i)Tentatively Ready4126(i)Voting
 17.3.2 [version.syn]
 Some feature-test macros for fully freestanding features are not yet marked freestanding
 Yes
 
 
            
 
            4130(i)New4130(i)Open
 17.6.5 [ptr.launder]
 Preconditions for std::launder might be overly strict
 Yes
 
 
            
 
            4157(i)Tentatively Ready4157(i)Voting
 17.11.6 [cmp.alg]
 The resolution of LWG3465 was damaged by P2167R3
 Yes
 
 
            
 
            3454(i)LEWG3454(i)Open
 20.2.3 [pointer.traits]
 pointer_traits::pointer_to should be constexpr
 Yes
 
 
            
 
            4144(i)Tentatively Ready4144(i)Voting
 20.3.1.3.1 [unique.ptr.single.general]
 Disallow unique_ptr<T&, D>
 Yes
 
 
            
 
            4148(i)Tentatively Ready4148(i)Voting
 20.3.1.3.5 [unique.ptr.single.observers]
 unique_ptr::operator* should not allow dangling references
 Yes
 
 
            
 
            4024(i)Ready3216(i)Voting
 20.3.2.2.7 [util.smartptr.shared.create]Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwriteRebinding the allocator before calling construct/destroy in allocate_shared
 Yes23
 
 
            
 
            3216(i)Tentatively Ready4024(i)Voting
 20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_sharedUnderspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite
 Yes32
 
 
            
 
            
 
 
            
 
            4113(i)Tentatively Ready4113(i)Voting
 21.3.5.4 [meta.unary.prop]
 Disallow has_unique_object_representations<Incomplete[]>
 Yes
 
 
            
 
            3886(i)Tentatively Ready3886(i)Voting
 22.5.3.1 [optional.optional.general]
 Monad mo' problems
 Yes
 
 
            
 
            4141(i)Tentatively Ready4141(i)Voting
 22.5.3.1 [optional.optional.general]
 Improve prohibitions on "additional storage"
 Yes
 
 
            
 
            4072(i)Ready4072(i)Voting
 22.5.8 [optional.comp.with.t]
 std::optional comparisons: constrain harder
 Yes
 
 
            
 
            2833(i)2991(i)
 Open
 22.6.3.2 [variant.ctor]Library needs to specify what it means when it declares a function constexprvariant copy constructor missing noexcept(see below)
 Yes2
 
 
            
 
            2991(i)LEWG2833(i)Open
 22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Library needs to specify what it means when it declares a function constexpr
 Yes2
 
 
            
 
            
 778
 
            
 
            4140(i)Tentatively Ready4140(i)Voting
 22.9.2.1 [template.bitset.general]
 Useless default constructors for bit reference types
 Yes
 
 
            
 
            4147(i)Tentatively Ready4147(i)Voting
 23.2.4 [sequence.reqmts]
 Precondition on inplace_vector::emplace
 Yes
 
 
            
 
            4164(i)Ready4164(i)Voting
 23.3.7.5 [forward.list.modifiers]
 Missing guarantees for forward_list modifiers
 Yes
 
            
 
            
 4135(i)Tentatively ReadyVoting
 23.3.7.7 [forward.list.erasure]
 The helper lambda of std::erase for list should specify return type as
   bool
 
 
            
 
            4170(i)Tentatively Ready4170(i)Voting
 24.3.4.14 [iterator.concept.contiguous]
 contiguous_iterator should require to_address(I{})
 Yes
   Duplicates
 
            
 
            4027(i)Ready4027(i)Voting
 25.2 [ranges.syn]
 possibly-const-range should prefer returning const R&
 Yes
 
 
            
 
            4112(i)Ready4112(i)Voting
 25.5.2 [range.utility.helpers]
 has-arrow should required operator->() to be const-qualified
 Yes
 
 
            
 
            3899(i)Ready3899(i)Voting
 25.8.5 [coro.generator.promise]
 co_yielding elements of an lvalue generator is unnecessarily inefficient
 Yes
 
            
 
            
 3900(i)ReadyVoting
 25.8.5 [coro.generator.promise]
 The allocator_arg_t overloads of generator::promise_type::operator new
 should not be constrained
 
 
            
 
            4119(i)Tentatively Ready4119(i)Voting
 25.8.5 [coro.generator.promise]
 generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed
 Yes
 
 
            
 
            3918(i)Ready3918(i)Voting
 26.11.6 [uninitialized.move]
 std::uninitialized_move/_n and guaranteed copy elision
 Yes
 
 
            
 
            3436(i)Ready3436(i)Voting
 26.11.8 [specialized.construct]
 std::construct_at should support arrays
 Yes
 
 
            
 
            4085(i)Ready4085(i)Voting
 26.12.2 [alg.rand.generate]
 ranges::generate_random's helper lambda should specify the return type
 Yes
 
 
            
 
            4064(i)Ready4064(i)Voting
 27.5.1 [cstring.syn]
 Clarify that std::launder is not needed when using the result of std::memcpy
 Yes
 
 
            
 
            4084(i)Tentatively Ready4084(i)Voting
 28.3.4.3.3.3 [facet.num.put.virtuals]
 std::fixed ignores std::uppercase
 Yes
 
 
            
 
            4142(i)Tentatively Ready4142(i)Voting
 28.5.6.6 [format.parse.ctx]
 format_parse_context::check_dynamic_spec should require at least one type
 Yes
 
 
            
 
            4014(i)Ready4014(i)Voting
 29.5.4.4 [rand.eng.sub]
 LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code
 Yes
 
 
            
 
            4134(i)Ready4134(i)Voting
 29.5.4.5 [rand.eng.philox]
 Issue with Philox algorithm specification
 Yes
 
 
            
 
            4153(i)Tentatively Ready4153(i)Voting
 29.5.4.5 [rand.eng.philox]
 Fix extra "-1" for philox_engine::max()
 Yes
 
 
            
 
            4124(i)Tentatively Ready4124(i)Voting
 30.12 [time.format]
 Cannot format zoned_time with resolution coarser than seconds
 Yes
 
 
            
 
            4088(i)Tentatively Ready4088(i)Voting
 31.7.6.3.5 [ostream.formatted.print]
 println ignores the locale imbued in std::ostream
 Yes
 
 
            
 
            4044(i)Ready4044(i)Voting
 31.7.10 [print.fun]
 Confusing requirements for std::print on POSIX platforms
 Yes
 
 
            
 
            4169(i)Tentatively Ready4169(i)Voting
 32.5.8.2 [atomics.types.operations]
 std::atomic<T>'s default constructor should be constrained
 Yes
 
 
            
 
            4154(i)Ready4154(i)Voting
 32.10.10.2 [futures.task.members]
 The Mandates for std::packaged_task's constructor from a callable entity should consider decaying
 Yes
 
            
 Date:Revised 2024-11-18 at 13:27:23 UTC
+Revised 2024-11-19 at 16:10:33 UTC
 
 
            
 
            
 
            
 
            Ready Issues
            
-
            
-
            3216(i). Rebinding the allocator before calling construct/destroy in allocate_shared
            
-
            Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Tentatively Ready
- Submitter: Billy O'Neal III Opened: 2019-06-11 Last modified: 2024-10-02
            
-
            Priority: 3
-
            
-
            View other active issues in [util.smartptr.shared.create].
            
-
            View all other issues in [util.smartptr.shared.create].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The new allocate_shared wording says we need to rebind the allocator back to T's
-type before we can call construct or destroy, but this is suboptimal (might make
-extra unnecessary allocator copies), and is inconsistent with the containers' behavior, which call
-allocator construct on whatever T they want. (For example,
-std::list<T, alloc<T>> rebinds to alloc<_ListNode<T>>,
-but calls construct(T*) without rebinding back)
-
            
-It seems like we should be consistent with the containers and not require a rebind here. PR would
-look something like this, relative to N4810; I'm still not super happy with this wording because
-it looks like it might be saying a copy of the allocator must be made we would like to avoid…
-
            
-
-
            [2019-07 Issue Prioritization]
            
-
-
            Priority to 3 after discussion on the reflector.
            
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            This wording is relative to N4810.
            
-
-
              
-
            1. Modify 20.3.2.2.7 [util.smartptr.shared.create] as indicated:
              
-
-
              
-
              
-[Drafting note: The edits to change pv to pu were suggested by Jonathan
-Wakely (thanks!). This wording also has the remove_cv_t fixes specified by LWG 3210(i)
-— if that change is rejected some of those have to be stripped here.]
-
              
-
              
-
-
              
-
              -template<class T, ...>
-  shared_ptr<T> make_shared(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared(const A& a, args);
-template<class T, ...>
-  shared_ptr<T> make_shared_default_init(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared_default_init(const A& a, args);
-
              
-
              
-
              
--2- Requires: […]
-
              
-[…]
-
              
--7- Remarks:
-
              
-
                
-
              1. (7.1) — […]
                2. 
-
              2. […]
                3. 
-
              3. (7.5) — When a (sub)object of a non-array type U is specified to have an initial
-value of v, or U(l...), where l... is a list of constructor arguments,
-allocate_shared shall initialize this (sub)object via the expression
-
                
-
                  
-
                1. (7.5.1) — allocator_traits<A2>::construct(a2, pvu, v) or
                  2. 
-
                2. (7.5.2) — allocator_traits<A2>::construct(a2, pvu, l...)
                  3. 
-
                
-
                
-respectively, where pvu is a pointer of type
-remove_cv_t<U>* pointsing to storage suitable to hold
-an object of type remove_cv_t<U> and a2 of type
-A2 is a potentially rebound copy of the allocator a
-passed to allocate_shared such that its value_type is remove_cv_t<U>.
-
                
-
                4. 
-
              4. (7.6) — […]
                5. 
-
              5. (7.7) — When a (sub)object of non-array type U is specified to have a default
-initial value, allocate_shared shall initializes this (sub)object via
-the expression allocator_traits<A2>::construct(a2, pvu), where
-pvu is a pointer of type remove_cv_t<U>*
-pointsing to storage suitable to hold an object of type
-remove_cv_t<U> and a2 of type A2 is a
-potentially rebound copy of the allocator a passed to allocate_shared
-such that its value_type is remove_cv_t<U>.
                6. 
-
              6. […]
                7. 
-
              7. (7.12) — When a (sub)object of non-array type U that was initialized by
-allocate_shared is to be destroyed, it is destroyed via the expression
-allocator_traits<A2>::destroy(a2, pvu) where
-pvu is a pointer of type remove_cv_t<U>*
-pointsing to that object of type remove_cv_t<U> and
-a2 of type A2 is a potentially rebound copy of the
-allocator a passed to allocate_shared such that its value_type is
-remove_cv_t<U>.
                8. 
-
              
-
              
-
              
-
              2. 
-
            
-
            
-
-
            [2024-08-23; Jonathan provides updated wording]
            
-
-
            
-make_shared_default_init and allocate_shared_default_init were renamed
-by P1973R1 so this needs a rebase.
-The edit to (7.11) is just for consistency, so that pv is always void*
-and pu is remove_cv_t<U>*.
-Accepting this proposed resolution would also resolve issue 3210(i).
-
            
-
-
-
            [2024-10-02; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after six votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            This wording is relative to N4988.
            
-
-
              
-
            1. Modify 20.3.2.2.7 [util.smartptr.shared.create] as indicated:
              
-
-
              
-
              -template<class T, ...>
-  shared_ptr<T> make_shared(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared(const A& a, args);
-template<class T, ...>
-  shared_ptr<T> make_shared_for_overwrite(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared_for_overwrite(const A& a, args);
-
              
-
              
-
              
--2- Preconditions: […]
-
              
-[…]
-
              
--7- Remarks:
-
              
-
                
-
              1. (7.1) — […]
                2. 
-
              2. […]
                3. 
-
              3. (7.5) — When a (sub)object of a non-array type U is specified to have an initial
-value of v, or U(l...), where l... is a list of constructor arguments,
-allocate_shared shall initialize this (sub)object via the expression
-
                
-
                  
-
                1. (7.5.1) — allocator_traits<A2>::construct(a2, pvu, v) or
                  2. 
-
                2. (7.5.2) — allocator_traits<A2>::construct(a2, pvu, l...)
                  3. 
-
                
-
                
-respectively, where pvu is a pointer of type
-remove_cv_t<U>* pointsing to storage suitable to hold
-an object of type remove_cv_t<U> and a2 of type
-A2 is a potentially rebound copy of the allocator a
-passed to allocate_shared such that its value_type is remove_cv_t<U>.
-
                
-
                4. 
-
              4. (7.6) — […]
                5. 
-
              5. (7.7) — When a (sub)object of non-array type U is specified to have a default
-initial value, allocate_shared shall initializes this (sub)object via
-the expression allocator_traits<A2>::construct(a2, pvu), where
-pvu is a pointer of type remove_cv_t<U>*
-pointsing to storage suitable to hold an object of type
-remove_cv_t<U> and a2 of type A2 is a
-potentially rebound copy of the allocator a passed to allocate_shared
-such that its value_type is remove_cv_t<U>.
                6. 
-
              6. […]
                7. 
-
              7. 
-
                [Drafting note:
-Issue 4024(i) will add make_shared_for_overwrite
-and allocate_shared_for_overwrite to (7.11) but that doesn't conflict with this next edit.]
-
                
-
                (7.11) — When a (sub)object of non-array type U that was initialized by
-make_shared is to be destroyed, it is destroyed via the expression
-pvu->~U() where pvu
-points to that object of type U.
                8. 
-
              8. (7.12) — When a (sub)object of non-array type U that was initialized by
-allocate_shared is to be destroyed, it is destroyed via the expression
-allocator_traits<A2>::destroy(a2, pvu) where
-pvu is a pointer of type remove_cv_t<U>*
-pointsing to that object of type remove_cv_t<U> and
-a2 of type A2 is a potentially rebound copy of the
-allocator a passed to allocate_shared such that its value_type is
-remove_cv_t<U>.
                9. 
-
              
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
            
-
            3436(i). std::construct_at should support arrays
            
-
            Section: 26.11.8 [specialized.construct] Status: Ready
- Submitter: Jonathan Wakely Opened: 2020-04-29 Last modified: 2024-06-24
            
-
            Priority: 2
-
            
-
            View other active issues in [specialized.construct].
            
-
            View all other issues in [specialized.construct].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-std::construct_at is ill-formed for array types, because the type of the new-expression is T 
-not T* so it cannot be converted to the return type.
-
            
-In C++17 allocator_traits::construct did work for arrays, because it returns void so there is no 
-ill-formed conversion. On the other hand, in C++17 allocator_traits::destroy didn't work for arrays, 
-because p->~T() isn't valid.
-
            
-In C++20 allocator_traits::destroy does work, because std::destroy_at treats arrays specially, 
-but allocator_traits::construct no longer works because it uses std::construct_at.
-
            
-It seems unnecessary and/or confusing to remove support for arrays in construct when we're adding it in destroy.
-
            
-I suggest that std::construct_at should also handle arrays. It might be reasonable to restrict that 
-support to the case where sizeof...(Args) == 0, if supporting parenthesized aggregate-initialization 
-is not desirable in std::construct_at.
-
            
-
-
            [2020-05-09; Reflector prioritization]
            
-
-
            
-Set priority to 2 after reflector discussions.
-
            
-
-
            [2021-01-16; Zhihao Yuan provides wording]
            
-
-
-
            
-Previous resolution [SUPERSEDED]:
-
            
-
            
-
            
-This wording is relative to N4878. 
-
            
-
-
              
-
            1. Modify 26.11.8 [specialized.construct] as indicated:
              
-
-
              
-
              -template<class T, class... Args>
-  constexpr T* construct_at(T* location, Args&&... args);
-
-namespace ranges {
-  template<class T, class... Args>
-    constexpr T* construct_at(T* location, Args&&... args);
-}
-
              
-
              
-
              
--1- Constraints: The expression ::new (declval<void*>()) T(declval<Args>()...) is well-formed
-when treated as an unevaluated operand.
-
              
--2- Effects: Equivalent to:
-
              
-
              -returnauto ptr = ::new (voidify(*location)) T(std::forward<Args>(args)...);
-if constexpr (is_array_v<T>)
-  return launder(location);
-else
-  return ptr;
-
              
-
              
-
              
-
              2. 
-
            
-
            
-
-
            [2021-12-07; Zhihao Yuan comments and provides improved wording]
            
-
-
            
-The previous PR allows constructing arbitrary number of elements when
-T is an array of unknown bound:
            
-
            -extern int a[];
-std::construct_at(&a, 0, 1, 2);
-
            
-
            
-and leads to a UB.
-
            
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4901. 
-
            
-
-
              
-
            1. Modify 26.11.8 [specialized.construct] as indicated:
              
-
-
              
-
              -template<class T, class... Args>
-  constexpr T* construct_at(T* location, Args&&... args);
-
-namespace ranges {
-  template<class T, class... Args>
-    constexpr T* construct_at(T* location, Args&&... args);
-}
-
              
-
              
-
              
--1- Constraints: The expression ::new (declval<void*>()) T(declval<Args>()...) is well-formed
-when treated as an unevaluated operand (7.2.3 [expr.context]) and is_unbounded_array_v<T> is 
-false.
-
              
--2- Effects: Equivalent to:
-
              
-
              -returnauto ptr = ::new (voidify(*location)) T(std::forward<Args>(args)...);
-if constexpr (is_array_v<T>)
-  return launder(location);
-else
-  return ptr;
-
              
-
              
-
              
-
              2. 
-
            
-
            
-
-
            [2024-03-18; Jonathan provides new wording]
            
-
-
            
-During Core review in Varna, Hubert suggested creating T[1] for the array case.
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4971.
-
            
-
-
              
-
            1. Modify 26.11.8 [specialized.construct] as indicated:
              
-
-
              
-
              -template<class T, class... Args>
-  constexpr T* construct_at(T* location, Args&&... args);
-
-namespace ranges {
-  template<class T, class... Args>
-    constexpr T* construct_at(T* location, Args&&... args);
-}
-
              
-
              
-
              
--1- Constraints:
-is_unbounded_array_v<T> is false.
-The expression ::new (declval<void*>()) T(declval<Args>()...) is well-formed
-when treated as an unevaluated operand (7.2.3 [expr.context]).
-
              
--2- Effects: Equivalent to:
-
              
-
              -if constexpr (is_array_v<T>)
-  return ::new (voidify(*location)) T[1]{{std::forward<Args>(args)...}};
-else
-  return ::new (voidify(*location)) T(std::forward<Args>(args)...);
-
              
-
              
-
              
-
              2. 
-
            
-
            
-
-
            [St. Louis 2024-06-24; Jonathan provides improved wording]
            
-
-
            
-Why not support unbounded arrays, deducing the bound from sizeof...(Args)?
-
            
-JW: There's no motivation to support that here in construct_at.
-It isn't possible to create unbounded arrays via allocators,
-nor via any of the uninitialized_xxx algorithms. Extending construct_at
-that way seems like a design change, not restoring support for something
-that used to work with allocators and then got broken in C++20.
-
            
-
            
-Tim observed that the proposed resolution is ill-formed if T has an
-explicit default constructor. Value-initialization would work for that case,
-and there seems to be little motivation for supplying arguments to
-initialize the array. In C++17 the allocator_traits::construct case only
-supported value-initialization.
-
            
-
-
            [St. Louis 2024-06-24; move to Ready.]
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
-
              
-
            1. Modify 26.11.8 [specialized.construct] as indicated:
              
-
-
              
-
              -template<class T, class... Args>
-  constexpr T* construct_at(T* location, Args&&... args);
-
-namespace ranges {
-  template<class T, class... Args>
-    constexpr T* construct_at(T* location, Args&&... args);
-}
-
              
-
              
-
              
--1- Constraints:
-is_unbounded_array_v<T> is false.
-The expression ::new (declval<void*>()) T(declval<Args>()...) is well-formed
-when treated as an unevaluated operand (7.2.3 [expr.context]).
-
              
-
              
--?- Mandates:
-If is_array_v<T> is true, sizeof...(Args) is zero.
-
-
              
-
              
--2- Effects: Equivalent to:
-
              
-
              -if constexpr (is_array_v<T>)
-  return ::new (voidify(*location)) T[1]();
-else
-  return ::new (voidify(*location)) T(std::forward<Args>(args)...);
-
              
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
            
-
            3886(i). Monad mo' problems
            
-
            Section: 22.5.3.1 [optional.optional.general], 22.8.6.1 [expected.object.general] Status: Tentatively Ready
- Submitter: Casey Carter Opened: 2023-02-13 Last modified: 2024-09-19
            
-
            Priority: 3
-
            
-
            View other active issues in [optional.optional.general].
            
-
            View all other issues in [optional.optional.general].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-While implementing P2505R5 "Monadic Functions for std::expected" we found it odd that
-the template type parameter for the assignment operator that accepts an argument by forwarding reference is
-defaulted, but the template type parameter for value_or is not. For consistency, it would seem that
-meow.value_or(woof) should accept the same arguments woof as does
-meow = woof, even when those arguments are braced-initializers.
-
            
-That said, it would be peculiar to default the template type parameter of value_or to T
-instead of remove_cv_t<T>. For expected<const vector<int>, int> meow{unexpect, 42};,
-for example, meow.value_or({1, 2, 3}) would create a temporary const vector<int>
-for the argument and return a copy of that argument. Were the default template argument instead
-remove_cv_t<T>, meow.value_or({1, 2, 3}) could move construct its return value
-from the argument vector<int>. For the same reason, the constructor that accepts a forwarding
-reference with a default template argument of T should default that argument to remove_cv_t<T>.
-
            
-For consistency, it would be best to default the template argument of the perfect-forwarding construct,
-perfect-forwarding assignment operator, and value_or to remove_cv_t<T>. Since all of
-the arguments presented apply equally to optional, we believe optional should be changed
-consistently with expected. MSVCSTL has prototyped these changes successfully.
-
            
-
-
            [2023-03-22; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll.
-
            
-
            [2024-09-18; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after six votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4928.
-
            
-
-
              
-
            1. Modify 22.5.3.1 [optional.optional.general] as indicated:
              
-
-
              
-
              -namespace std {
-  template<class T>
-  class optional {
-  public:
-    […]
-    template<class U = remove_cv_t<T>>
-      constexpr explicit(see below) optional(U&&);
-    […]
-    template<class U = remove_cv_t<T>> constexpr optional& operator=(U&&);
-    […]
-    template<class U = remove_cv_t<T>> constexpr T value_or(U&&) const &;
-    template<class U = remove_cv_t<T>> constexpr T value_or(U&&) &&;
-    […]
-  };
-  […]
-}
-
              
-
              
-
-
              2. 
-
-
            2. Modify 22.5.3.2 [optional.ctor] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>> constexpr explicit(see below) optional(U&& v);
-
              
-
              
-
              
--23- Constraints: […]
-
              
-
              
-
              
-
-
              3. 
-
-
            3. Modify 22.5.3.4 [optional.assign] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>> constexpr optional& operator=(U&& v);
-
              
-
              
-
              
--12- Constraints: […]
-
              
-
              
-
              
-
-
              4. 
-
-
            4. Modify 22.5.3.7 [optional.observe] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>> constexpr T value_or(U&& v) const &;
-
              
-
              
-
              
--15- Mandates: […]
-
              
-[…]
-
              
-
              
-
              -template<class U = remove_cv_t<T>> constexpr T value_or(U&& v) &&;
-
              
-
              
-
              
--17- Mandates: […]
-
              
-
              
-
              
-
-
              5. 
-
-
            5. Modify 22.8.6.1 [expected.object.general] as indicated:
              
-
-
              
-
              -namespace std {
-  template<class T, class E>
-  class expected {
-  public:
-    […]
-    template<class U = remove_cv_t<T>>
-      constexpr explicit(see below) expected(U&& v);
-    […]
-    template<class U = remove_cv_t<T>> constexpr expected& operator=(U&&);
-    […]
-    template<class U = remove_cv_t<T>> constexpr T value_or(U&&) const &;
-    template<class U = remove_cv_t<T>> constexpr T value_or(U&&) &&;
-    […]
-  };
-  […]
-}
-
              
-
              
-
-
              6. 
-
-
            6. Modify 22.8.6.2 [expected.object.cons] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>>
-  constexpr explicit(!is_convertible_v<U, T>) expected(U&& v);
-
              
-
              
-
              
--23- Constraints: […]
-
              
-
              
-
              
-
-
              7. 
-
-
            7. Modify 22.8.6.4 [expected.object.assign] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>>
-  constexpr expected& operator=(U&& v);
-
              
-
              
-
              
--9- Constraints: […]
-
              
-
              
-
              
-
-
              8. 
-
-
            8. Modify 22.8.6.6 [expected.object.obs] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>> constexpr T value_or(U&& v) const &;
-
              
-
              
-
              
--16- Mandates: […]
-
              
-[…]
-
              
-
              
-
              -template<class U = remove_cv_t<T>> constexpr T value_or(U&& v) &&;
-
              
-
              
-
              
--18- Mandates: […]
-
              
-
              
-
              
-
-
              9. 
-
-
            
-
-
-
-
-
-
            
-
            3899(i). co_yielding elements of an lvalue generator is unnecessarily inefficient
            
-
            Section: 25.8.5 [coro.generator.promise] Status: Ready
- Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-06-28
            
-
            Priority: 3
-
            
-
            View other active issues in [coro.generator.promise].
            
-
            View all other issues in [coro.generator.promise].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-Consider:
-
            
-
            
-
            -std::generator<int> f();
-std::generator<int> g() {
-    auto gen = f();
-    auto gen2 = f();
-    co_yield std::ranges::elements_of(std::move(gen));   // #1
-    co_yield std::ranges::elements_of(gen2);             // #2
-    // other stuff
-}
-
            
-
            
-
            
-Both #1 and #2 compile. The differences are:
-
            
-
              
-
            • 
-
              
-#2 is significantly less efficient (it uses the general overload of yield_value,
-so it creates a new coroutine frame and doesn't do symmetric transfer into gen2's coroutine)
-
              
-
              • 
-
            • 
-
              
-the coroutine frame of gen and gen2 are destroyed at different
-times: gen's frame is destroyed at the end of #1, but gen2's is
-not destroyed until the closing brace.
-
              
-
              • 
-
            
-
            
-But as far as the user is concerned, neither gen nor gen2 is
-usable after the co_yield. In both cases the only things you can do
-with the objects are:
-
            
-
              
-
            • destroying them;
              • 
-
            • assigning to them;
              • 
-
            • call end() on them to get a copy of default_sentinel.
              • 
-
            
-
            
-We could make #2 ill-formed, but that seems unnecessary: there is no meaningful
-difference between generator and any other single-pass input range
-(or a generator with a different yielded type that has to go through
-the general overload) in this regard. We should just make #2 do the efficient
-thing too.
-
            
-
-
            [2023-03-22; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll.
-
            
-
-
            [St. Louis 2024-06-28; move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4928.
-
            
-
-
              
-
-
            1. Modify 25.8.5 [coro.generator.promise] as indicated:
              
-
-
              
-
              
-
              -namespace std {
-  template<class Ref, class V, class Allocator>
-  class generator<Ref, V, Allocator>::promise_type {
-  public:
-    […]
-    auto yield_value(const remove_reference_t<yielded>& lval)
-      requires is_rvalue_reference_v<yielded> &&
-        constructible_from<remove_cvref_t<yielded>, const remove_reference_t<yielded>&>;
-
-    template<class R2, class V2, class Alloc2, class Unused>
-      requires same_as<typename generator<R2, V2, Alloc2>::yielded, yielded>
-        auto yield_value(ranges::elements_of<generator<R2, V2, Alloc2>&&, Unused> g) noexcept;
-    template<class R2, class V2, class Alloc2, class Unused>
-      requires same_as<typename generator<R2, V2, Alloc2>::yielded, yielded>
-        auto yield_value(ranges::elements_of<generator<R2, V2, Alloc2>&, Unused> g) noexcept;
-
-    template<ranges::input_range R, class Alloc>
-      requires convertible_to<ranges::range_reference_t<R>, yielded>
-        auto yield_value(ranges::elements_of<R, Alloc> r) noexcept;
-    […]
-   };
-}
-
              
-
              
-[…]
-
              -template<class R2, class V2, class Alloc2, class Unused>
-  requires same_as<typename generator<R2, V2, Alloc2>::yielded, yielded>
-  auto yield_value(ranges::elements_of<generator<R2, V2, Alloc2>&&, Unused> g) noexcept;
-template<class R2, class V2, class Alloc2, class Unused>
-  requires same_as<typename generator<R2, V2, Alloc2>::yielded, yielded>
-  auto yield_value(ranges::elements_of<generator<R2, V2, Alloc2>&, Unused> g) noexcept;
-
              
-
              
-
              
--10- Preconditions: A handle referring to the coroutine whose promise object
-is *this is at the top of *active_ of some generator
-object x. The coroutine referred to by g.range.coroutine_
-is suspended at its initial suspend point.
-
              
--11- Returns: An awaitable object of an unspecified type (7.6.2.4 [expr.await])
-into which g.range is moved, whose member await_ready returns false,
-whose member await_suspend pushes g.range.coroutine_ into *x.active_
-and resumes execution of the coroutine referred to by g.range.coroutine_,
-and whose member await_resume evaluates rethrow_exception(except_)
-if bool(except_) is true. If bool(except_) is false,
-the await_resume member has no effects.
-
              
--12- Remarks: A yield-expression that calls
-this functionone of these functions has type
-void (7.6.17 [expr.yield]).
-
              
-
              
-
              
-
-
              2. 
-
-
-
            
-
-
-
-
-
-
            
-
            3900(i). The allocator_arg_t overloads of generator::promise_type::operator new
-should not be constrained
            
-
            Section: 25.8.5 [coro.generator.promise] Status: Ready
- Submitter: Tim Song Opened: 2023-03-04 Last modified: 2024-06-28
            
-
            Priority: 3
-
            
-
            View other active issues in [coro.generator.promise].
            
-
            View all other issues in [coro.generator.promise].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-When the allocator is not type-erased, the allocator_arg_t overloads of
-generator::promise_type::operator new are constrained on
-convertible_to<const Alloc&, Allocator>. As a result, if the
-the allocator is default-constructible (like polymorphic_allocator is)
-but the user accidentally provided a wrong type (say, memory_resource&
-instead of memory_resource*), their code will silently fall back to
-using a default-constructed allocator. It would seem better to take the tag
-as definitive evidence of the user's intent to supply an allocator for the coroutine,
-and error out if the supplied allocator cannot be used.
-
            
-This change does mean that the user cannot deliberately pass an incompatible
-allocator (preceded by an std::allocator_arg_t tag) for their own use
-inside the coroutine, but that sort of API seems fragile and confusing at best,
-since the usual case is that allocators so passed will be used by
-generator.
-
            
-
-
            [2023-03-22; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll.
-
            
-
-
            [St. Louis 2024-06-28; move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4928.
-
            
-
-
              
-
-
            1. Modify 25.8.5 [coro.generator.promise] as indicated:
              
-
-
              
-
              
-
              -namespace std {
-  template<class Ref, class V, class Allocator>
-  class generator<Ref, V, Allocator>::promise_type {
-  public:
-    […]
-    void* operator new(size_t size)
-      requires same_as<Allocator, void> || default_initializable<Allocator>;
-
-    template<class Alloc, class... Args>
-      requires same_as<Allocator, void> || convertible_to<const Alloc&, Allocator>
-        void* operator new(size_t size, allocator_arg_t, const Alloc& alloc, const Args&...);
-
-    template<class This, class Alloc, class... Args>
-      requires same_as<Allocator, void> || convertible_to<const Alloc&, Allocator>
-        void* operator new(size_t size, const This&, allocator_arg_t, const Alloc& alloc,
-                           const Args&...);
-    […]
-   };
-}
-
              
-
              
-[…]
-
              -void* operator new(size_t size)
-  requires same_as<Allocator, void> || default_initializable<Allocator>;
-
-template<class Alloc, class... Args>
-  requires same_as<Allocator, void> || convertible_to<const Alloc&, Allocator>
-  void* operator new(size_t size, allocator_arg_t, const Alloc& alloc, const Args&...);
-
-template<class This, class Alloc, class... Args>
-  requires same_as<Allocator, void> || convertible_to<const Alloc&, Allocator>
-  void* operator new(size_t size, const This&, allocator_arg_t, const Alloc& alloc,
-                     const Args&...);
-
              
-
              
-
              
--17- Let A be
-
              
-
                
-  
              1. (17.1) — Allocator, if it is not void,
                2. 
-  
              2. (17.2) — Alloc for the overloads with a template parameter Alloc, or
                3. 
-  
              3. (17.3) — allocator<void> otherwise.
                4. 
-
              
-
              
-Let B be allocator_traits<A>::template rebind_alloc<U>
-where U is an unspecified type whose size and alignment are both
-__STDCPP_DEFAULT_NEW_ALIGNMENT__.
-
              
--18- Mandates: allocator_traits<B>::pointer is a pointer type.
-For the overloads with a template parameter Alloc,
-same_as<Allocator, void> || convertible_to<const Alloc&, Allocator> is modeled.
-
              
--19- Effects: Initializes an allocator b of type B with A(alloc),
-for the overloads with a function parameter alloc, and with A() otherwise.
-Uses b to allocate storage for the smallest array of U sufficient
-to provide storage for a coroutine state of size size, and unspecified
-additional state necessary to ensure that operator delete can later
-deallocate this memory block with an allocator equal to b.
-
              
--20- Returns: A pointer to the allocated storage.
-
              
-
-
              
-
              
-
-
-
              2. 
-
-
-
            
-
-
-
-
-
-
            
-
            3918(i). std::uninitialized_move/_n and guaranteed copy elision
            
-
            Section: 26.11.6 [uninitialized.move] Status: Ready
- Submitter: Jiang An Opened: 2023-04-04 Last modified: 2024-06-26
            
-
            Priority: 3
-
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-Currently std::move is unconditionally used in std::uninitialized_move and std::uninitialized_move_n, 
-which may involve unnecessary move construction if dereferencing the input iterator yields a prvalue.
-
            
-The status quo was mentioned in paper issue #975, 
-but no further process is done since then.
-
            
-
-
            [2023-06-01; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll. Send to LEWG.
-
            
-
            
-"P2283 wants to remove guaranteed elision here."
-"Poorly motivated, not clear anybody is using these algos with proxy iterators."
-"Consider using iter_move in the move algos."
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4944.
-
            
-
-
              
-
            1. 
-
              Modify 26.11.1 [specialized.algorithms.general] as indicated:
              
-
-
              
-
              
--3- Some algorithms specified in 26.11 [specialized.algorithms] make use of the following exposition-only 
-functions voidify:
-
              
-
              -template<class T>
-  constexpr void* voidify(T& obj) noexcept {
-    return addressof(obj);
-  }
-  
-template<class I>
-  decltype(auto) deref-move(const I& it) {
-    if constexpr (is_lvalue_reference_v<decltype(*it)>)
-      return std::move(*it);
-    else
-      return *it;
-  }
-
              
-
              
-
              2. 
-
-
            2. 
-
              Modify 26.11.6 [uninitialized.move] as indicated:
              
-
-
              
-
              -template<class InputIterator, class NoThrowForwardIterator>
-  NoThrowForwardIterator uninitialized_move(InputIterator first, InputIterator last,
-                                            NoThrowForwardIterator result);
-
              
-
              
-
              
--1- Preconditions: result + [0, (last - first)) does not overlap with [first, last).
-
              
--2- Effects: Equivalent to:
-
              
-
              -for (; first != last; (void)++result, ++first)
-  ::new (voidify(*result))
-    typename iterator_traits<NoThrowForwardIterator>::value_type(std::move(*deref-move(first));
-return result;
-
              
-
              
-[…]
-
              -template<class InputIterator, class Size, class NoThrowForwardIterator>
-  pair<InputIterator, NoThrowForwardIterator>
-    uninitialized_move_n(InputIterator first, Size n, NoThrowForwardIterator result);
-
              
-
              
-
              
--6- Preconditions: result + [0, n) does not overlap with first + [0, n).
-
              
--7- Effects: Equivalent to:
-
              
-
              -for (; n > 0; ++result,(void) ++first, --n)
-  ::new (voidify(*result))
-    typename iterator_traits<NoThrowForwardIterator>::value_type(std::move(*deref-move(first));
-return {first, result};
-
              
-
              
-
              
-
              3. 
-
            
-
            
-
-
            [2024-03-22; Tokyo: Jonathan updates wording after LEWG review]
            
-
-
            
-LEWG agrees it would be good to do this.
-Using iter_move was discussed, but it was noted that the versions of these
-algos in the ranges namespace already use it and introducing
-ranges::iter_move into the non-ranges versions wasn't desirable.
-It was observed that the proposed deref-move has a
-const I& parameter which would be ill-formed for any iterator
-with a non-const operator* member. Suggested removing the const and
-recommended LWG to accept the proposed resolution.
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4971.
-
            
-
-
              
-
            1. 
-
              Modify 26.11.1 [specialized.algorithms.general] as indicated:
              
-
-
              
-
              
--3- Some algorithms specified in 26.11 [specialized.algorithms] make use of the following exposition-only 
-functions voidify:
-
              
-
              -template<class T>
-  constexpr void* voidify(T& obj) noexcept {
-    return addressof(obj);
-  }
-  
-template<class I>
-  decltype(auto) deref-move(I& it) {
-    if constexpr (is_lvalue_reference_v<decltype(*it)>)
-      return std::move(*it);
-    else
-      return *it;
-  }
-
              
-
              
-
              2. 
-
-
            2. 
-
              Modify 26.11.6 [uninitialized.move] as indicated:
              
-
-
              
-
              -template<class InputIterator, class NoThrowForwardIterator>
-  NoThrowForwardIterator uninitialized_move(InputIterator first, InputIterator last,
-                                            NoThrowForwardIterator result);
-
              
-
              
-
              
--1- Preconditions: result + [0, (last - first)) does not overlap with [first, last).
-
              
--2- Effects: Equivalent to:
-
              
-
              -for (; first != last; (void)++result, ++first)
-  ::new (voidify(*result))
-    typename iterator_traits<NoThrowForwardIterator>::value_type(std::move(*deref-move(first));
-return result;
-
              
-
              
-[…]
-
              -template<class InputIterator, class Size, class NoThrowForwardIterator>
-  pair<InputIterator, NoThrowForwardIterator>
-    uninitialized_move_n(InputIterator first, Size n, NoThrowForwardIterator result);
-
              
-
              
-
              
--6- Preconditions: result + [0, n) does not overlap with first + [0, n).
-
              
--7- Effects: Equivalent to:
-
              
-
              -for (; n > 0; ++result,(void) ++first, --n)
-  ::new (voidify(*result))
-    typename iterator_traits<NoThrowForwardIterator>::value_type(std::move(*deref-move(first));
-return {first, result};
-
              
-
              
-
              
-
              3. 
-
            
-
            
-
-
            [St. Louis 2024-06-24; revert P/R and move to Ready]
            
-
-
            
-Tim observed that the iterator requirements require all iterators to be
-const-dereferenceable, so there was no reason to remove the const.
-Restore the original resolution and move to Ready.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4971.
-
            
-
-
              
-
            1. 
-
              Modify 26.11.1 [specialized.algorithms.general] as indicated:
              
-
-
              
-
              
--3- Some algorithms specified in 26.11 [specialized.algorithms] make use of the following exposition-only 
-functions voidify:
-
              
-
              -template<class T>
-  constexpr void* voidify(T& obj) noexcept {
-    return addressof(obj);
-  }
-
-template<class I>
-  decltype(auto) deref-move(I& it) {
-    if constexpr (is_lvalue_reference_v<decltype(*it)>)
-      return std::move(*it);
-    else
-      return *it;
-  }
-
              
-
              
-
              2. 
-
-
            2. 
-
              Modify 26.11.6 [uninitialized.move] as indicated:
              
-
-
              
-
              -template<class InputIterator, class NoThrowForwardIterator>
-  NoThrowForwardIterator uninitialized_move(InputIterator first, InputIterator last,
-                                            NoThrowForwardIterator result);
-
              
-
              
-
              
--1- Preconditions: result + [0, (last - first)) does not overlap with [first, last).
-
              
--2- Effects: Equivalent to:
-
              
-
              -for (; first != last; (void)++result, ++first)
-  ::new (voidify(*result))
-    typename iterator_traits<NoThrowForwardIterator>::value_type(std::move(*deref-move(first));
-return result;
-
              
-
              
-[…]
-
              -template<class InputIterator, class Size, class NoThrowForwardIterator>
-  pair<InputIterator, NoThrowForwardIterator>
-    uninitialized_move_n(InputIterator first, Size n, NoThrowForwardIterator result);
-
              
-
              
-
              
--6- Preconditions: result + [0, n) does not overlap with first + [0, n).
-
              
--7- Effects: Equivalent to:
-
              
-
              -for (; n > 0; ++result,(void) ++first, --n)
-  ::new (voidify(*result))
-    typename iterator_traits<NoThrowForwardIterator>::value_type(std::move(*deref-move(first));
-return {first, result};
-
              
-
              
-
              
-
              3. 
-
            
-
-
-
-
-
-
            
-
            4014(i). LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code
            
-
            Section: 29.5.4.4 [rand.eng.sub] Status: Ready
- Submitter: Matt Stephanson Opened: 2023-11-15 Last modified: 2024-10-09
            
-
            Priority: 2
-
            
-
            View all other issues in [rand.eng.sub].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-Issue 3809(i) pointed out that subtract_with_carry_engine<T> can be seeded with values
-from a linear_congruential_engine<T, 40014u, 0u, 2147483563u> object, which results in narrowing
-when T is less than 32 bits. Part of the resolution was to modify the LCG seed sequence as follows:
-
            
-
            
-
            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
-  
-.
-
            
-
            
-
            
-Inside linear_congruential_engine, the seed is reduced modulo 2147483563, so uint_least32_t
-is fine from that point on. This resolution, however, forces value, the user-provided seed, to be
-truncated from result_type to uint_least32_t before the reduction, which generally will
-change the result. It also breaks the existing behavior that two seeds are equivalent if they're in the same
-congruence class modulo the divisor.
-
            
-
-
            [2024-01-11; Reflector poll]
            
-
-
            
-Set priority to 2 after reflector poll.
-
-
            [2024-01-11; Jonathan comments]
            
-
-
            
-More precisely, the resolution forces value to be converted
-to uint_least32_t, which doesn't necessarily truncate, and if it
-does truncate, it doesn't necessarily change the value.
-But it will truncate whenever value_type is wider than
-uint_least32_t,
-e.g. for 32-bit uint_least32_t you get a different result for
-std::ranlux48_base(UINT_MAX + 1LL)().
-The new proposed resolution below restores the old behaviour for that type.
-
            
-
-
            
-
-
            [2024-10-09; LWG telecon: Move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4964 after the wording changes applied by LWG 3809(i),
-which had been accepted into the working paper during the Kona 2023-11 meeting.
-
            
-
-
              
-
-
            1. Modify 29.5.4.4 [rand.eng.sub] 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<uint_least32_t,
-                           40014u,0u,2147483563u> e(value == 0u ? default_seed :
-                           static_cast<uint_least32_t>(value % 2147483563u));
-
              
-
                  
-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
-  
-.
-
              
-
              
-
-
              2. 
-
-
            
-
-
-
-
-
-
            
-
            4024(i). Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite
            
-
            Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Ready
- Submitter: Jiang An Opened: 2023-12-16 Last modified: 2024-08-21
            
-
            Priority: 2
-
            
-
            View other active issues in [util.smartptr.shared.create].
            
-
            View all other issues in [util.smartptr.shared.create].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-Currently, only destructions of non-array (sub)objects created in std::make_shared and std::allocate_shared 
-are specified in 20.3.2.2.7 [util.smartptr.shared.create]. Presumably, objects created in 
-std::make_shared_for_overwrite and std::allocate_shared_for_overwrite should be destroyed by plain 
-destructor calls.
-
            
-
-
            [2024-03-11; Reflector poll]
            
-
-
            
-Set priority to 2 after reflector poll in December 2023.
-
            
-
            
-This was the P1020R1 author's intent (see LWG reflector mail
-in November 2018) but it was never clarified in the wording. This fixes that.
-
            
-
-
            [2024-08-21; Move to Ready at LWG telecon]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4964.
-
            
-
-
              
-
-
            1. Modify 20.3.2.2.7 [util.smartptr.shared.create] as indicated:
              
-
-
              
-
              -template<class T, ...>
-  shared_ptr<T> make_shared(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared(const A& a, args);
-template<class T, ...>
-  shared_ptr<T> make_shared_for_overwrite(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared_for_overwrite(const A& a, args);
-
              
-
              
-
              
-[…]
-
              
--7- Remarks:
-
              
-
                
-
              1. […]
                2. 
-
              2. (7.11) — When a (sub)object of non-array type U that was initialized by 
-make_shared, make_shared_for_overwrite, or allocate_shared_for_overwrite 
-is to be destroyed, it is destroyed via the expression pv->~U() where pv points to that 
-object of type U.
                3. 
-
              3. […]
                4. 
-
              
-
              
-
              
-
              2. 
-
-
            
-
-
-
-
-
-
-
-
            
-
            4027(i). possibly-const-range should prefer returning const R&
            
-
            Section: 25.2 [ranges.syn] Status: Ready
- Submitter: Hewill Kang Opened: 2023-12-17 Last modified: 2024-06-28
            
-
            Priority: 2
-
            
-
            View other active issues in [ranges.syn].
            
-
            View all other issues in [ranges.syn].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-possibly-const-range currently only returns const R& when R does not 
-satisfy constant_range and const R satisfies constant_range.
-
            
-Although it's not clear why we need the former condition, this does diverge from the legacy std::cbegin 
-(demo):
-
            
-
            -#include <ranges>
-
-int main() {
-  auto r = std::views::single(0)
-        | std::views::transform([](int) { return 0; });
-  using C1 = decltype(std::ranges::cbegin(r));
-  using C2 = decltype(std::cbegin(r));
-  static_assert(std::same_as<C1, C2>); // failed
-}
-
            
-
            
-Since R itself is constant_range, so possibly-const-range, above just returns 
-R& and C1 is transform_view::iterator<false>; std::cbegin 
-specifies to return as_const(r).begin(), which makes that C2 is 
-transform_view::iterator<true> which is different from C1.
-
            
-I believe const R& should always be returned if it's a range, regardless of whether const R 
-or R is a constant_range, just as fmt-maybe-const in format ranges always prefers 
-const R over R.
-
            
-Although it is theoretically possible for R to satisfy constant_range and that const R 
-is a mutable range, such nonsense range type should not be of interest.
-
            
-This relaxation of constraints allows for maximum consistency with std::cbegin, and in some cases can 
-preserve constness to the greatest extent (demo):
-
            
-
            -#include <ranges>
-
-int main() {
-  auto r = std::views::single(0) | std::views::lazy_split(0);
-  (*std::ranges::cbegin(r)).front() = 42; // ok
-  (*std::cbegin(r)).front() = 42; // not ok
-}
-
            
-
            
-Above, *std::ranges::cbegin returns a range of type const lazy_split_view::outer-iterator<false>::value_type, 
-which does not satisfy constant_range because its reference type is int&.
-
            
-However, *std::cbegin(r) returns lazy_split_view::outer-iterator<true>::value_type 
-whose reference type is const int& and satisfies constant_range.
-
            
-
-
            [2024-03-11; Reflector poll]
            
-
-
            
-Set priority to 2 after reflector poll. Send to SG9.
-
            
-
-
            [St. Louis 2024-06-28; LWG and SG9 joint session: move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4971.
-
            
-
-
              
-
-
            1. Modify 25.2 [ranges.syn], header <ranges> synopsis, as indicated:
              
-
-
              
-
              -#include <compare>              // see 17.11.1 [compare.syn]
-#include <initializer_list>     // see 17.10.2 [initializer.list.syn]
-#include <iterator>             // see 24.2 [iterator.synopsis]
-
-namespace std::ranges {
-  […]
-
-  // 25.7.22 [range.as.const], as const view
-  template<input_range R>
-    constexpr auto& possibly-const-range(R& r) noexcept { // exposition only
-      if constexpr (inputconstant_range<const R> && !constant_range<R>) {
-        return const_cast<const R&>(r);
-      } else {
-        return r;
-      }
-    }
-
-  […]
-}
-
              
-
              
-
              2. 
-
-
            
-
-
-
-
-
-
-
-
            
-
            4044(i). Confusing requirements for std::print on POSIX platforms
            
-
            Section: 31.7.10 [print.fun] Status: Ready
- Submitter: Jonathan Wakely Opened: 2024-01-24 Last modified: 2024-06-24
            
-
            Priority: 3
-
            
-
            View other active issues in [print.fun].
            
-
            View all other issues in [print.fun].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-The effects for vprintf_unicode say:
-
            
-
-
            
-
            
-If stream refers to a terminal capable of displaying Unicode,
-writes out to the terminal using the native Unicode API;
-if out contains invalid code units, the behavior is undefined
-and implementations are encouraged to diagnose it.
-Otherwise writes out to stream unchanged.
-If the native Unicode API is used, the function flushes stream
-before writing out.
-
            
-
            
-[Note 1:
-On POSIX and Windows, stream referring to a terminal means that,
-respectively, isatty(fileno(stream)) and
-GetConsoleMode(_get_osfhandle(_fileno(stream)), ...)
-return nonzero.
-— end note]
-
            
-
            
-[Note 2:
-On Windows, the native Unicode API is WriteConsoleW.
-— end note]
-
            
-
            -8-
-Throws:  [...]
-
            
-
            -9-
-Recommended practice:
-If invoking the native Unicode API requires transcoding, implementations
-should substitute invalid code units with
-u+fffd replacement character
-per the Unicode Standard, Chapter 3.9
-u+fffd Substitution in Conversion.
-
            
-
            
-
-
            
-The very explicit mention of isatty for POSIX platforms has
-confused at least two implementers into thinking that we're supposed to
-use isatty, and supposed to do something differently based
-on what it returns. That seems consistent with the nearly identical wording
-in 28.5.2.2 [format.string.std] paragraph 12, which says
-"Implementations should use either UTF-8, UTF-16, or UTF-32,
-on platforms capable of displaying Unicode text in a terminal"
-and then has a note explicitly saying this is the case for Windows-based and
-many POSIX-based operating systems. So it seems clear that POSIX platforms
-are supposed to be considered to have "a terminal capable of displaying
-Unicode text", and so std::print should use isatty
-and then use a native Unicode API, and diagnose invalid code units.
-
            
-
            
-This is a problem however, because isatty needs
-to make a system call on Linux, adding 500ns to every std::print
-call. This results in a 10x slowdown on Linux, where std::print
-can take just 60ns without the isatty check.
-
            
-
            
-From discussions with Tom Honermann I learned that the "native Unicode API"
-wording is only relevant on Windows. This makes sense, because for POSIX
-platforms, writing to a terminal is done using the usual stdio functions,
-so there's no need to treat a terminal differently to any other file stream.
-And substitution of invalid code units with
-u+fffd
-is recommended for Windows because that's what typical modern terminals do on
-POSIX platforms, so requiring the implementation to do that on Windows gives
-consistent behaviour. But the implementation doesn't need to do anything to
-make that happen with a POSIX terminal, it happens anyway.
-So the isatty check is unnecessary for POSIX platforms,
-and the note mentioning it just causes confusion and has no benefit.
-
            
-
-
            
-Secondly, there initially seems to be a contradiction between the 
-"implementations are encouraged to diagnose it" wording and the later
-Recommended practice. In fact, there's no contradiction because
-the native Unicode API might accept UTF-8 and therefore require no
-transcoding, and so the Recommended practice wouldn't apply.
-The intention is that diagnosing invalid UTF-8 is still desirable in this case,
-but how should it be diagnosed? By writing an error to the terminal alongside
-the formatted string?
-Or by substituting u+fffd maybe?
-If the latter is the intention, why is one suggestion in the middle of the
-Effects, and one given as Recommended practice?
-
            
-
-
            
-The proposed resolution attempts to clarify that a "native Unicode API"
-is only needed if that's how you display Unicode on the terminal.
-It also moves the flushing requirement to be adjacent to the other
-requirements for systems using a native Unicode API instead of on its own
-later in the paragraph.
-And the suggestion to diagnose invalid code units is moved into the
-Recommended practice and clarified that it's only relevant if
-using a native Unicode API. I'm still not entirely happy with encouragement
-to diagnose invalid code units without giving any clue as to how that should
-be done. What does it mean to diagnose something at runtime? That's novel
-for the C++ standard. The way it's currently phrased seems to imply something
-other than u+fffd substitution
-should be done, although that seems the most obvious implementation to me.
-
            
-
-
-
            [2024-03-12; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll and send to SG16.
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4971.
-
            
-
-
              
-
            1. Modify 31.7.6.3.5 [ostream.formatted.print] as indicated:
              
-
              
-
              -void vprint_unicode(ostream& os, string_view fmt, format_args args);
-void vprint_nonunicode(ostream& os, string_view fmt, format_args args);
-
              
-
              -3-
-Effects:
-Behaves as a formatted output function
-(31.7.6.3.1 [ostream.formatted.reqmts])
-of os, except that:
-
                
-
              1. (3.1) –
-failure to generate output is reported as specified below, and
-
                2. 
-
              2. (3.2) –
-any exception thrown by the call to vformat is propagated without
-regard to the value of os.exceptions() and without turning on
-ios_base::badbit in the error state of os.
-
                3. 
-
              
-
              
-
              
-After constructing a sentry object,
-the function initializes an automatic variable via
-
                string out = vformat(os.getloc(), fmt, args); 
              
-If the function is vprint_unicode
-and os is a stream that
-refers to a terminal capable of displaying Unicode
-via a native Unicode API,
-which is determined in an implementation-defined manner,
-flushes os and then
-writes out to the terminal using the native Unicode API;
-if out contains invalid code units, the behavior is undefined
-and implementations are encouraged to diagnose it.
-
-If the native Unicode API is used, the function flushes os
-before writing out.
-
-Otherwise, (if os is not such a stream or the function is
-vprint_nonunicode), inserts the character sequence
-[out.begin(),out.end()) into os.
-If writing to the terminal or inserting into os fails, calls
-os.setstate(ios_base::badbit)
-(which may throw ios_base::failure).
-
              
-
              -4-
-Recommended practice:
-For vprint_unicode,
-if invoking the native Unicode API requires transcoding, implementations
-should substitute invalid code units with
-u+fffd replacement character
-per the Unicode Standard, Chapter 3.9
-u+fffd Substitution in Conversion.
-
-If invoking the native Unicode API  does not require transcoding,
-implementations are encouraged to diagnose invalid code units.
-
-
              
-
              
-
              2. 
-
-
            2. Modify 31.7.10 [print.fun] as indicated:
              
-
-
              
-
              -void vprint_unicode(FILE* stream, string_view fmt, format_args args);
-
              
-
              -6-
-Preconditions:
-stream is a valid pointer to an output C stream.
-
              
-
              -7-
-Effects:
-The function initializes an automatic variable via
-
                string out = vformat(fmt, args); 
              
-If stream refers to a terminal capable of displaying Unicode
-via a native Unicode API,
-flushes stream and then
-writes out to the terminal using the native Unicode API;
-if out contains invalid code units, the behavior is undefined
-and implementations are encouraged to diagnose it.
-Otherwise writes out to stream unchanged.
-
-If the native Unicode API is used, the function flushes stream
-before writing out.
-
-
              
-
              
-[Note 1:
-On POSIX and Windows,
-the native Unicode API is WriteConsoleW and
-stream referring to a terminal means that,
-respectively, isatty(fileno(stream)) and
-GetConsoleMode(_get_osfhandle(_fileno(stream)), ...)
-return nonzero.
-— end note]
-
              
-
              
-
-[Note 2:
-On Windows, the native Unicode API is WriteConsoleW.
-— end note]
-
-
              
-
              -8-
-Throws:  [...]
-
              
-
              -9-
-Recommended practice:
-If invoking the native Unicode API requires transcoding, implementations
-should substitute invalid code units with
-u+fffd replacement character
-per the Unicode Standard, Chapter 3.9
-u+fffd Substitution in Conversion.
-
-If invoking the native Unicode API  does not require transcoding,
-implementations are encouraged to diagnose invalid code units.
-
-
              
-
              
-
              3. 
-
            
-
            
-
-
            [2024-03-12; Jonathan updates wording based on SG16 feedback]
            
-
-
            
-SG16 reviewed the issue and approved the proposed resolution with
-the wording about diagnosing invalid code units removed.
-
            
-
            
-SG16 favors removing the following text (both occurrences) from the proposed
-wording. This is motivated by a lack of understanding regarding what it means
-to diagnose such invalid code unit sequences given that the input is likely
-provided at run-time.
-
-
            
-If invoking the native Unicode API does not require transcoding, implementations are encouraged to diagnose invalid code units.
-
            
-
            
-
-
            
-Some concern was expressed regarding how the current wording is structured.
-At present, the wording leads with a Windows centric perspective;
-if the stream refers to a terminal ... use the native Unicode API ...
-otherwise write code units to the stream.
-It might be an improvement to structure the wording such that use of the native
-Unicode API is presented as a fallback for implementations that require its use
-when writing directly to the stream is not sufficient to produce desired
-results. In other words, the wording should permit direct writing to the stream
-even when the stream is directed to a terminal and a native Unicode API is
-available when the implementation has reason to believe that doing so will
-produce the correct results. For example, Microsoft's HoloLens has a Windows
-based operating system, but it only supports use of UTF-8 as the system code
-page and therefore would not require the native Unicode API bypass;
-implementations for it could avoid the overhead of checking to see if the
-stream is directed to a console.
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
-
            
-This wording is relative to N4971.
-
            
-
-
              
-
            1. Modify 31.7.6.3.5 [ostream.formatted.print] as indicated:
              
-
              
-
              -void vprint_unicode(ostream& os, string_view fmt, format_args args);
-void vprint_nonunicode(ostream& os, string_view fmt, format_args args);
-
              
-
              -3-
-Effects:
-Behaves as a formatted output function
-(31.7.6.3.1 [ostream.formatted.reqmts])
-of os, except that:
-
                
-
              1. (3.1) –
-failure to generate output is reported as specified below, and
-
                2. 
-
              2. (3.2) –
-any exception thrown by the call to vformat is propagated without
-regard to the value of os.exceptions() and without turning on
-ios_base::badbit in the error state of os.
-
                3. 
-
              
-
              
-
              
-After constructing a sentry object,
-the function initializes an automatic variable via
-
                string out = vformat(os.getloc(), fmt, args); 
              
-If the function is vprint_unicode
-and os is a stream that
-refers to a terminal that is only capable of displaying Unicode
-via a native Unicode API,
-which is determined in an implementation-defined manner,
-flushes os and then
-writes out to the terminal using the native Unicode API;
-if out contains invalid code units, the behavior is undefined
-and implementations are encouraged to diagnose it.
-
-If the native Unicode API is used, the function flushes os
-before writing out.
-
-Otherwise, (if os is not such a stream or the function is
-vprint_nonunicode), inserts the character sequence
-[out.begin(),out.end()) into os.
-If writing to the terminal or inserting into os fails, calls
-os.setstate(ios_base::badbit)
-(which may throw ios_base::failure).
-
              
-
              -4-
-Recommended practice:
-For vprint_unicode,
-if invoking the native Unicode API requires transcoding, implementations
-should substitute invalid code units with
-u+fffd replacement character
-per the Unicode Standard, Chapter 3.9
-u+fffd Substitution in Conversion.
-
              
-
              
-
              2. 
-
-
            2. Modify 31.7.10 [print.fun] as indicated:
              
-
-
              
-
              -void vprint_unicode(FILE* stream, string_view fmt, format_args args);
-
              
-
              -6-
-Preconditions:
-stream is a valid pointer to an output C stream.
-
              
-
              -7-
-Effects:
-The function initializes an automatic variable via
-
                string out = vformat(fmt, args); 
              
-If stream refers to a terminal that is only
-capable of displaying Unicode
-via a native Unicode API,
-flushes stream and then
-writes out to the terminal using the native Unicode API;
-if out contains invalid code units, the behavior is undefined
-and implementations are encouraged to diagnose it.
-Otherwise writes out to stream unchanged.
-
-If the native Unicode API is used, the function flushes stream
-before writing out.
-
-
              
-
              
-[Note 1:
-On POSIX and Windows,
-the native Unicode API is WriteConsoleW and
-stream referring to a terminal means that,
-respectively, isatty(fileno(stream)) and
-GetConsoleMode(_get_osfhandle(_fileno(stream)), ...)
-return nonzero.
-— end note]
-
              
-
              
-
-[Note 2:
-On Windows, the native Unicode API is WriteConsoleW.
-— end note]
-
-
              
-
              -8-
-Throws:  [...]
-
              
-
              -9-
-Recommended practice:
-If invoking the native Unicode API requires transcoding, implementations
-should substitute invalid code units with
-u+fffd replacement character
-per the Unicode Standard, Chapter 3.9
-u+fffd Substitution in Conversion.
-
              
-
              
-
              3. 
-
            
-
            
-
-
            [2024-03-19; Tokyo: Jonathan updates wording after LWG review]
            
-
-
            
-Split the Effects: into separate bullets for the "native Unicode API"
-and "otherwise" cases. Remove the now-redundant "if os is not such a stream"
-parenthesis.
-
            
-
-
            [St. Louis 2024-06-24; move to Ready.]
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4971.
-
            
-
-
              
-
            1. Modify 31.7.6.3.5 [ostream.formatted.print] as indicated:
              
-
              
-
              -void vprint_unicode(ostream& os, string_view fmt, format_args args);
-void vprint_nonunicode(ostream& os, string_view fmt, format_args args);
-
              
-
              -3-
-Effects:
-Behaves as a formatted output function
-(31.7.6.3.1 [ostream.formatted.reqmts])
-of os, except that:
-
                
-
              1. (3.1) –
-failure to generate output is reported as specified below, and
-
                2. 
-
              2. (3.2) –
-any exception thrown by the call to vformat is propagated without
-regard to the value of os.exceptions() and without turning on
-ios_base::badbit in the error state of os.
-
                3. 
-
              
-
              
-
-
              
--?-
-After constructing a sentry object,
-the function initializes an automatic variable via
-
                string out = vformat(os.getloc(), fmt, args); 
              
-
                
-
              1. (?.1) – 
-If the function is vprint_unicode
-and os is a stream that
-refers to a terminal that is only capable of displaying Unicode
-via a native Unicode API,
-which is determined in an implementation-defined manner,
-flushes os and then
-writes out to the terminal using the native Unicode API;
-if out contains invalid code units, the behavior is undefined
-and implementations are encouraged to diagnose it.
-
-If the native Unicode API is used, the function flushes os
-before writing out.
-
                2. 
-
              2. (?.2) – 
-Otherwise,
-
-(if os is not such a stream or the function is
-vprint_nonunicode),
-
-inserts the character sequence
-[out.begin(),out.end()) into os.
-
                3. 
-
              
-
              
-
              
--?-
-If writing to the terminal or inserting into os fails, calls
-os.setstate(ios_base::badbit)
-(which may throw ios_base::failure).
-
              
-
              -4-
-Recommended practice:
-For vprint_unicode,
-if invoking the native Unicode API requires transcoding, implementations
-should substitute invalid code units with
-u+fffd replacement character
-per the Unicode Standard, Chapter 3.9
-u+fffd Substitution in Conversion.
-
              
-
              
-
              2. 
-
-
            2. Modify 31.7.10 [print.fun] as indicated:
              
-
-
              
-
              -void vprint_unicode(FILE* stream, string_view fmt, format_args args);
-
              
-
              -6-
-Preconditions:
-stream is a valid pointer to an output C stream.
-
              
-
              -7-
-Effects:
-The function initializes an automatic variable via
-
                string out = vformat(fmt, args); 
              
-
                
-
              1. (7.1) – 
-If stream refers to a terminal that is only
-capable of displaying Unicode
-via a native Unicode API,
-flushes stream and then
-writes out to the terminal using the native Unicode API;
-if out contains invalid code units, the behavior is undefined
-and implementations are encouraged to diagnose it.
-
                2. 
-
              2. (7.2) – 
-Otherwise writes out to stream unchanged.
-
                3. 
-
              
-
              
-
              
-
-If the native Unicode API is used, the function flushes stream
-before writing out.
-
-
              
-
              
-[Note 1:
-On POSIX and Windows,
-the native Unicode API is WriteConsoleW and
-stream referring to a terminal means that,
-respectively, isatty(fileno(stream)) and
-GetConsoleMode(_get_osfhandle(_fileno(stream)), ...)
-returns nonzero.
-— end note]
-
              
-
              
-
-[Note 2:
-On Windows, the native Unicode API is WriteConsoleW.
-— end note]
-
-
              
-
              -8-
-Throws:  [...]
-
              
-
              -9-
-Recommended practice:
-If invoking the native Unicode API requires transcoding, implementations
-should substitute invalid code units with
-u+fffd replacement character
-per the Unicode Standard, Chapter 3.9
-u+fffd Substitution in Conversion.
-
              
-
              
-
              3. 
-
            
-
-
-
-
-
-
-
            
-
            4064(i). Clarify that std::launder is not needed when using the result of std::memcpy
            
-
            Section: 27.5.1 [cstring.syn] Status: Ready
- Submitter: Jan Schultke Opened: 2024-04-05 Last modified: 2024-06-28
            
-
            Priority: 3
-
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            -int x = 0;
-alignas(int) std::byte y[sizeof(int)];
-int z = *static_cast<int*>(std::memcpy(y, &x, sizeof(int)));
-
            
-
            
-This example should be well-defined, even without the use of std::launder.
-std::memcpy implicitly creates an int inside y, and 
-https://www.iso-9899.info/n3047.html#7.26.2.1p3 
-states that
-
            
-
            
-
            
-The memcpy function returns the value of [the destination operand].
-
            
-
            
-
            
-In conjunction with 27.5.1 [cstring.syn] p3, this presumably means that std::memcpy 
-returns a pointer to the (first) implicitly-created object, and no use of std::launder 
-is necessary.
-
            
-The wording should be clarified to clearly support this interpretation or reject it.
-
            
-
-
            [2024-06-24; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll.
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4971.
-
            
-
-
              
-
            1. Modify 27.5.1 [cstring.syn] as indicated:
              
-
-
              
-
              
--3- The functions memcpy and memmove are signal-safe (17.13.5 [support.signal]). 
-Both functions implicitly create objects (6.7.2 [intro.object]) in the destination region of 
-storage immediately prior to copying the sequence of characters to the destination. Both functions 
-return a pointer to a suitable created object.
-
              
-
              
-
              2. 
-
            
-
            
-
-
            [St. Louis 2024-06-26; CWG suggested improved wording]
            
-
-
            [St. Louis 2024-06-28; LWG: move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
-
              
-
            1. Modify 27.5.1 [cstring.syn] as indicated:
              
-
-
              
-
              
--3-
-The functions memcpy and memmove are signal-safe
-(17.13.5 [support.signal]).
-Both Each of these functions implicitly
-create creates objects (6.7.2 [intro.object])
-in the destination region of storage immediately prior to copying
-the sequence of characters to the destination.
-Each of these functions returns a pointer to a suitable created object,
-if any, otherwise the value of the first parameter.
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4072(i). std::optional comparisons: constrain harder
            
-
            Section: 22.5.8 [optional.comp.with.t] Status: Ready
- Submitter: Jonathan Wakely Opened: 2024-04-19 Last modified: 2024-08-21
            
-
            Priority: 1
-
            
-
            View all other issues in [optional.comp.with.t].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-P2944R3 added constraints to std::optional's comparisons, e.g.
-
            
-
            
-
            
-template<class T, class U> constexpr bool operator==(const optional<T>& x, const optional<U>& y);
-
            
--1- MandatesConstraints:
-The expression *x == *y is well-formed and its result is convertible to bool.
-
             … 
            
-
            
-template<class T, class U> constexpr bool operator==(const optional<T>& x, const U& v);
-
            
--1- MandatesConstraints:
-The expression *x == v is well-formed and its result is convertible to bool.
-
            
-
-
            
-But I don't think the constraint on the second one (the "compare with value")
-is correct. If we try to compare two optionals that can't be compared,
-such as optional<void*> and optional<int>,
-then the first overload is not valid due to the new constraints, and so does
-not participate in overload resolution.  But that means we now consider the
-second overload, but that's ambiguous. We could either use
-operator==<void*, optional<int>> or we could use
-operator==<optional<void*>, int> with the arguments
-reversed (using the C++20 default comparison rules).
-We never even get as far as checking the new constraints on those overloads,
-because they're simply ambiguous.
-
            
-
            
-Before P2944R3 overload resolution always would have selected
-the first overload, for comparing two optionals. But because that is now
-constrained away, we consider an overload that should never be used for
-comparing two optionals. The solution is to add an additional constraint
-to the "compare with value" overloads so that they won't be used when the
-"value" is really another optional.
-
            
-
-
            
-A similar change was made to optional's operator<=> by
-LWG 3566(i), and modified by LWG 3746(i).
-I haven't analyzed whether we need the modification here too.
-
            
-
-
            
-The proposed resolution (without is-derived-from-optional)
-has been implemented and tested in libstdc++.
-
            
-
-
            [2024-06-24; Reflector poll]
            
-
-
            
-Set priority to 1 after reflector poll.
-LWG 3746(i) changes might be needed here too,
-i.e, consider types derived from optional, not only optional itself.
-
            
-
-
            [2024-08-21; Move to Ready at LWG telecon]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
-
              
-
            1. Modify 22.5.8 [optional.comp.with.t] as indicated:
              
-
-
              
-
              
-template<class T, class U> constexpr bool operator==(const optional<T>& x, const U& v);
-
              
-
              -1-
-Constraints:
-U is not a specialization of optional.
-The expression *x == v is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator==(const T& v, const optional<U>& x);
-
              
-
              -3-
-Constraints:
-T is not a specialization of optional.
-The expression v == *x is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator!=(const optional<T>& x, const U& v);
-
              
-
              -5-
-Constraints:
-U is not a specialization of optional.
-The expression *x != v is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator!=(const T& v, const optional<U>& x);
-
              
-
              -7-
-Constraints:
-T is not a specialization of optional.
-The expression v != *x is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator<(const optional<T>& x, const U& v);
-
              
-
              -9-
-Constraints:
-U is not a specialization of optional.
-The expression *x < v is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator<(const T& v, const optional<U>& x);
-
              
-
              -11-
-Constraints:
-T is not a specialization of optional.
-The expression v < *x is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator>(const optional<T>& x, const U& v);
-
              
-
              -13-
-Constraints:
-U is not a specialization of optional.
-The expression *x > v is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator>(const T& v, const optional<U>& x);
-
              
-
              -15-
-Constraints:
-T is not a specialization of optional.
-The expression v > *x is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator<=(const optional<T>& x, const U& v);
-
              
-
              -17-
-Constraints:
-U is not a specialization of optional.
-The expression *x <= v is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator<=(const T& v, const optional<U>& x);
-
              
-
              -19-
-Constraints:
-T is not a specialization of optional.
-The expression v <= *x is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator>=(const optional<T>& x, const U& v);
-
              
-
              -21-
-Constraints:
-U is not a specialization of optional.
-The expression *x &gt;= v is well-formed
-and its result is convertible to bool.
-
              
-
-
              
-template<class T, class U> constexpr bool operator>=(const T& v, const optional<U>& x);
-
              
-
              -23-
-Constraints:
-T is not a specialization of optional.
-The expression v >= *x is well-formed
-and its result is convertible to bool.
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4084(i). std::fixed ignores std::uppercase
            
-
            Section: 28.3.4.3.3.3 [facet.num.put.virtuals] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-04-30 Last modified: 2024-09-19
            
-
            Priority: 3
-
            
-
            View other active issues in [facet.num.put.virtuals].
            
-
            View all other issues in [facet.num.put.virtuals].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-In Table 114 – Floating-point conversions [tab:facet.num.put.fp]
-we specify that a floating-point value should be printed as if by %f
-when (flags & floatfield) == fixed.
-This ignores whether uppercase is also set in flags,
-meaning there is no way to use the conversion specifier %F
-that was added to printf in C99.
-
            
-
            
-That's fine for finite values, because 1.23 in fixed format has
-no exponent character and no hex digits that would need to use uppercase.
-But %f and %F are not equivalent for non-finite values,
-because %F prints "NAN" and "INF" (or "INFINITY").
-It seems there is no way to print "NAN" or "INF" using std::num_put.
-
            
-
            
-Libstdc++ and MSVC print "inf" for the following code,
-but libc++ prints "INF" which I think is non-conforming:
-
            
-
                std::cout << std::uppercase << std::fixed << std::numeric_limits<double>::infinity();
-
            
-
            
-The libc++ behaviour seems more useful and less surprising.
-
            
-
-
            [2024-05-08; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll. Send to LEWG.
-
            
-
            [2024-09-17; LEWG mailing list vote]
            
-
-
            
-Set status to Open after LEWG approved the proposed change.
-
            
-
            [2024-09-19; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after eight votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
              
-
            1. Modify 28.3.4.3.3.3 [facet.num.put.virtuals] as indicated:
              
-
-
              
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
              
-Table 114 – Floating-point conversions [tab:facet.num.put.fp]
-
              Statestdio equivalent
              
-floatfield == ios_base::fixed && !uppercase
-%f
              floatfield == ios_base::fixed%F
              floatfield == ios_base::scientific && !uppercase%e
              floatfield == ios_base::scientific%E
              
-
-floatfield == (ios_base::fixed | ios_base::scientific)` && !uppercase
-
-%a
              floatfield == (ios_base::fixed | ios_base::scientific)%A
              !uppercase%g
              otherwise%G
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
-
            
-
            4085(i). ranges::generate_random's helper lambda should specify the return type
            
-
            Section: 26.12.2 [alg.rand.generate] Status: Ready
- Submitter: Hewill Kang Opened: 2024-04-28 Last modified: 2024-10-09
            
-
            Priority: 2
-
            
-
            View other active issues in [alg.rand.generate].
            
-
            View all other issues in [alg.rand.generate].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-The non-specialized case of generate_random(r, g, d) would call
-ranges::generate(r, [&d, &g] { return invoke(d, g); }).
-However, the lambda does not explicitly specify the return type, which leads
-to a hard error when invoke returns a reference to the object that is not copyable or
-R is not the output_range for decay_t<invoke_result_t<D&, G&>>.
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4981.
-
            
-
-
              
-
            1. Modify 26.12.2 [alg.rand.generate] as indicated:
              
-
-
              
-
              -template<class R, class G, class D>
-  requires output_range<R, invoke_result_t<D&, G&>> && invocable<D&, G&> &&
-           uniform_random_bit_generator<remove_cvref_t<G>>
-constexpr borrowed_iterator_t<R> ranges::generate_random(R&& r, G&& g, D&& d);
-
              
-
              -5- Effects:
              
-
                
-
              1. (5.1) — […]
                2. 
-
              2. (5.2) — […]
                3. 
-
              3. (5.3) — Otherwise, calls:
                
-
                -ranges::generate(std::forward<R>(r), [&d, &g] -> decltype(auto) { return invoke(d, g); });
-
                
-
                4. 
-
              
-
              -6- Returns: ranges::end(r)
              
-
              -7- Remarks: The effects of generate_random(r, g, d) shall be equivalent to
              
-
              -ranges::generate(std::forward<R>(r), [&d, &g] -> decltype(auto) { return invoke(d, g); })
-
              
-
              
-
-
              2. 
-
            
-
            
-
-
            [2024-05-12, Hewill Kang provides improved wording]
            
-
-
-
            [2024-08-02; Reflector poll]
            
-
-
            
-Set priority to 2 after reflector poll.
-
            
-
-
            [2024-10-09; LWG telecon: Move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
-
              
-
            1. Modify 29.5.2 [rand.synopsis], header <random> synopsis, as indicated:
              
-
-
              
-
              -#include <initializer_list>     // see 17.10.2 [initializer.list.syn]
-
-namespace std {
-  […]
-  namespace ranges {
-    […]
-    template<class R, class G, class D>
-      requires output_range<R, invoke_result_t<D&, G&>> && invocable<D&, G&> &&
-               uniform_random_bit_generator<remove_cvref_t<G>> &&
-               is_arithmetic_v<invoke_result_t<D&, G&>>
-    constexpr borrowed_iterator_t<R> generate_random(R&& r, G&& g, D&& d);
-
-    template<class G, class D, output_iterator<invoke_result_t<D&, G&>> O, sentinel_for<O> S>
-      requires invocable<D&, G&> && uniform_random_bit_generator<remove_cvref_t<G>> &&
-               is_arithmetic_v<invoke_result_t<D&, G&>>
-    constexpr O generate_random(O first, S last, G&& g, D&& d);
-  }
-  […]
-}
-
              
-
              
-
-
              2. 
-
-
            2. Modify 26.12.2 [alg.rand.generate] as indicated:
              
-
-
              
-
              -template<class R, class G, class D>
-  requires output_range<R, invoke_result_t<D&, G&>> && invocable<D&, G&> &&
-           uniform_random_bit_generator<remove_cvref_t<G>> &&
-           is_arithmetic_v<invoke_result_t<D&, G&>>
-constexpr borrowed_iterator_t<R> ranges::generate_random(R&& r, G&& g, D&& d);
-
              
-
              
-
              
--5- Effects:
-
              
-[…]
-
              
-
              -template<class G, class D, output_iterator<invoke_result_t<D&, G&>> O, sentinel_for<O> S>
-  requires invocable<D&, G&> && uniform_random_bit_generator<remove_cvref_t<G>> &&
-           is_arithmetic_v<invoke_result_t<D&, G&>>
-constexpr O ranges::generate_random(O first, S last, G&& g, D&& d);
-
              
-
              
-
              
--8- Effects: Equivalent to:
-
              
-[…]
-
              
-
              
-
-
              3. 
-
            
-
-
-
-
-
-
-
            
-
            4088(i). println ignores the locale imbued in std::ostream
            
-
            Section: 31.7.6.3.5 [ostream.formatted.print] Status: Tentatively Ready
- Submitter: Jens Maurer Opened: 2024-04-30 Last modified: 2024-10-03
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [ostream.formatted.print].
            
-
            View all other issues in [ostream.formatted.print].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-31.7.6.3.5 [ostream.formatted.print] specifies that std::print uses the locale
-imbued in the std::ostream& argument for formatting, by using this equivalence:
-
            
-
            
-
            -vformat(os.getloc(), fmt, args);
-
            
-
            
-
            
-(in the vformat_(non)unicode delegation).
-
            
-However, std::println ignores the std::ostream's locale
-for its locale-dependent formatting:
-
            
-
            
-
            -print(os, "{}\n", format(fmt, std::forward<Args>(args)...));
-
            
-
            
-
            
-This is inconsistent.
-
            
-
-
            [2024-10-03; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after seven votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
-
              
-
-
            1. Modify 31.7.6.3.5 [ostream.formatted.print] as indicated:
              
-
-
              
-
              -template<class... Args>
-  void println(ostream& os, format_string<Args...> fmt, Args&&... args);
-
              
-
              
-
              
--2- Effects: Equivalent to:
-
              
-
              
-
              -print(os, "{}\n", format(os.getloc(), fmt, std::forward<Args>(args)...));
-
              
-
              
-
              
-
              
-
-
              2. 
-
            
-
-
-
-
-
-
-
            
-
            4112(i). has-arrow should required operator->() to be const-qualified
            
-
            Section: 25.5.2 [range.utility.helpers] Status: Ready
- Submitter: Hewill Kang Opened: 2024-06-22 Last modified: 2024-06-24
            
-
            Priority: Not Prioritized
-
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-The helper concept has-arrow in 25.5.2 [range.utility.helpers] does not 
-require that I::operator->() be const-qualified, which is inconsistent with 
-the constraints on reverse_iterator and common_iterator's operator->() 
-as the latter two both require the underlying iterator has const operator->() member.
-
            
-We should enhance the semantics of has-arrow so that
-implicit expression variations (18.2 [concepts.equality])
-prohibit silly games.
-
            
-
-
            [St. Louis 2024-06-24; move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
-
              
-
            1. Modify 25.5.2 [range.utility.helpers] as indicated:
              
-
-
              
-
              -[…]
-
-template<class I>
-  concept has-arrow =                                       // exposition only
-    input_iterator<I> && (is_pointer_v<I> || requires(const I i) { i.operator->(); });
-
-[…]
-
              
-
              
-
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4113(i). Disallow has_unique_object_representations<Incomplete[]>
            
-
            Section: 21.3.5.4 [meta.unary.prop] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-06-25 Last modified: 2024-08-02
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [meta.unary.prop].
            
-
            View all other issues in [meta.unary.prop].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The type completeness requirements for has_unique_object_representations say:
-
            
-T shall be a complete type, cv void, or an array of unknown bound.
-
            
-
            
-
            
-This implies that the trait works for all arrays of unknown bound,
-whether the element type is complete or not. That seems to be incorrect,
-because has_unique_object_representations_v<Incomplete[]>
-is required to have the same result as
-has_unique_object_representations_v<Incomplete>
-which is ill-formed if Incomplete is an incomplete class type.
-
            
-
-
            
-I think we need the element type to be complete to be able to give an answer.
-Alternatively, if the intended result for an array of unknown bound is false
-(maybe because there can be no objects of type T[], or because we can't
-know that two objects declared as extern T a[]; and extern T b[]; have
-the same number of elements?) then the condition for the trait needs to be
-special-cased as false for arrays of unknown bound.
-The current spec is inconsistent, we can't allow arrays of unknown bound
-and apply the current rules to determine the trait's result.
-
            
-
-
            [2024-08-02; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after nine votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
-
              
-
            1. Modify 21.3.5.4 [meta.unary.prop] as indicated:
              
-
-
              
-
-
-
-
-
-
-
-
-
-
-
-
-
              TemplateConditionPreconditions
              ………
              
-
              template<class T>
-struct has_unique_object_representations;
              
-              		
-For an array type T, the same result as
-has_unique_object_representations_v<remove_all_extents_t<T>>,
-otherwise see below.
-
-remove_all_extents_t<T>
-T
-shall be a complete type,
-or cv void, or an array of unknown bound.
-
              
-
              
-
              
-
              
-[Drafting note: We could use remove_extent_t<T>
-to remove just the first array dimension, because only that first one can
-have an unknown bound.
-The proposed resolution uses remove_all_extents_t<T>
-for consistency with the Condition column.]
-
              
-
              
-
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4119(i). generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed
            
-
            Section: 25.8.5 [coro.generator.promise] Status: Tentatively Ready
- Submitter: Hewill Kang Opened: 2024-07-11 Last modified: 2024-08-02
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [coro.generator.promise].
            
-
            View all other issues in [coro.generator.promise].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The nested coroutine is specified to return generator<yielded, ranges::range_value_t<R>, Alloc> 
-which can be problematic as the value type of R is really irrelevant to yielded, 
-unnecessarily violating the generator's Mandates (demo):
-
            
-
            -#include <generator>
-#include <vector>
-
-std::generator<std::span<int>> f() {
-  std::vector<int> v;
-  co_yield v; // ok
-}
-
-std::generator<std::span<int>> g() {
-  std::vector<std::vector<int>> v;
-  co_yield std::ranges::elements_of(v); // hard error
-}
-
            
-
            
-This proposed resolution is to change the second template parameter from range_value_t<R> 
-to void since that type doesn't matter to us.
-
            
-
-
            [2024-08-02; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after five votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4986.
-
            
-
              
-
            1. Modify 25.8.5 [coro.generator.promise] as indicated:
              
-
-
              
-
              -template<ranges::input_range R, class Alloc>
-  requires convertible_to<ranges::range_reference_t<R>, yielded>
-  auto yield_value(ranges::elements_of<R, Alloc> r);
-
              
-
              
-
              
--13- Effects: Equivalent to:
-
              
-
              -auto nested = [](allocator_arg_t, Alloc, ranges::iterator_t<R> i, ranges::sentinel_t<R> s)
-  -> generator<yielded, ranges::range_value_t<R>void, Alloc> {
-    for (; i != s; ++i) {
-      co_yield static_cast<yielded>(*i);
-    }
-  };
-return yield_value(ranges::elements_of(nested(
-  allocator_arg, r.allocator, ranges::begin(r.range), ranges::end(r.range))));
-
              
-[…]
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4124(i). Cannot format zoned_time with resolution coarser than seconds
            
-
            Section: 30.12 [time.format] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-07-26 Last modified: 2024-08-02
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [time.format].
            
-
            View all other issues in [time.format].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The
-std::formatter<std::chrono::zoned_time<Duration, TimeZonePtr>>
-specialization calls tp.get_local_time() for the object it passes to its
-base class' format function. But get_local_time() does not return a
-local_time<Duration>, it returns
-local_time<common_type_t<Duration, seconds>>.
-The base class' format function is only defined for
-local_time<Duration>.
-That means this is ill-formed, even though the static assert passes:
-
            using namespace std::chrono;
-  static_assert( std::formattable<zoned_time<minutes>, char> );
-  zoned_time<minutes> zt;
-  (void) std::format("{}", zt); // error: cannot convert local_time<seconds> to local_time<minutes>
-
            
-
            
-
-
            
-Additionally, it's not specified what output you should get for:
-
            std::format("{}", local_time_format(zt.get_local_time()));
-
            
-30.12 [time.format] p7 says it's formatted as if by streaming to an
-ostringstream,
-but there is no operator<< for local-time-format-t.
-Presumably it should give the same result as operator<< for 
-a zoned_time, i.e. "{:L%F %T %Z}" with padding adjustments etc.
-
            
-
            
-The proposed resolution below has been implemented in libstdc++.
-
            
-
-
            [2024-08-02; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after seven votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4986.
-
            
-
-
              
-
            1. Modify 30.12 [time.format] as indicated:
              
-
-
              
-
              -template<classDuration, class charT>
-  struct formatter<chrono::local-time-format-t<Duration>, charT>;
-
              
-
              -17-
-Let f be a locale-time-format-t<Duration> object
-passed to formatter::format.
-
              
-
              -18- Remarks:
-If the chrono-specs is omitted, the result is equivalent to
-using %F %T %Z as the chrono-specs.
-If %Z is used,
-it is replaced with *f.abbrev if f.abbrev is not a null pointer value.
-If %Z is used and f.abbrev is a null pointer value,
-an exception of type format_error is thrown.
-If %z (or a modified variant of %z) is used,
-it is formatted with the value of *f.offset_sec if f.offset_sec is
-not a null pointer value.
-If %z (or a modified variant of %z) is used and f.offset_sec
-is a null pointer value, then an exception of type format_error is thrown.
-
              
-
              -  template<class Duration, class TimeZonePtr, class charT>
-  struct formatter<chrono::zoned_time<Duration, TimeZonePtr>, charT>
-      : formatter<chrono::local-time-format-t<common_type_t<Duration, seconds>>, charT> {
-    template<class FormatContext>
-      typename FormatContext::iterator
-      format(const chrono::zoned_time<Duration, TimeZonePtr>& tp, FormatContext& ctx) const;
-  };
-
              
-
              -template<class FormatContext>
-  typename FormatContext::iterator
-    format(const chrono::zoned_time<Duration, TimeZonePtr>& tp, FormatContext& ctx) const;
-
              
-
              -19- Effects: Equivalent to:
-
              
-
              -sys_info info = tp.get_info();
-return formatter<chrono::local-time-format-t<common_type_t<Duration, seconds>>, charT>::
-         format({tp.get_local_time(), &info.abbrev, &info.offset}, ctx);
-
              
-
              
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4126(i). Some feature-test macros for fully freestanding features are not yet marked freestanding
            
-
            Section: 17.3.2 [version.syn] Status: Tentatively Ready
- Submitter: Jiang An Opened: 2024-07-24 Last modified: 2024-08-02
            
-
            Priority: 2
-
            
-
            View other active issues in [version.syn].
            
-
            View all other issues in [version.syn].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-Currently (N4986), it's a bit weird in 17.3.2 [version.syn] that some feature-test
-macros are not marked freestanding, despite the indicated features being fully freestanding. The 
-freestanding status seems sometimes implicitly covered by "also in" headers that are mostly or all 
-freestanding, but sometimes not.
-
            
-I think it's more consistent to ensure feature-test macros for fully freestanding features are also freestanding.
-
            
-
-
            [2024-08-02; Reflector poll]
            
-
-
            
-Set priority to 2 and set status to Tentatively Ready after seven votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4986.
-
            
-
-
              
-
            1. Modify 17.3.2 [version.syn] as indicated:
              
-
-
              
-
              
-[Drafting note:  <charconv> is not fully freestanding, but all functions made constexpr 
-by P2291R3 are furtherly made freestanding by P2338R4. ]
-
              
-
              
-
-
              
-
              -[…]
-#define __cpp_lib_common_reference                  202302L // freestanding, also in <type_traits>
-#define __cpp_lib_common_reference_wrapper          202302L // freestanding, also in <functional>
-[…]                                                                              
-#define __cpp_lib_constexpr_charconv                202207L // freestanding, also in <charconv>
-[…]                                                                              
-#define __cpp_lib_coroutine                         201902L // freestanding, also in <coroutine>
-[…]                                                                              
-#define __cpp_lib_is_implicit_lifetime              202302L // freestanding, also in <type_traits>
-[…]                                                                              
-#define __cpp_lib_is_virtual_base_of                202406L // freestanding, also in <type_traits>
-[…]                                                                              
-#define __cpp_lib_is_within_lifetime                202306L // freestanding, also in <type_traits>
-[…]                                                                              
-#define __cpp_lib_mdspan                            202406L // freestanding, also in <mdspan>
-[…]                                                                              
-#define __cpp_lib_ratio                             202306L // freestanding, also in <ratio>
-[…]                                                                              
-#define __cpp_lib_span_initializer_list             202311L // freestanding, also in <span>
-[…]                                                                              
-#define __cpp_lib_submdspan                         202403L // freestanding, also in <mdspan>
-[…]                                                                              
-#define __cpp_lib_to_array                          201907L // freestanding, also in <array>
-[…]
-
              
-
              
-
-
              2. 
-
-
            
-
-
-
-
-
-
            
-
            4134(i). Issue with Philox algorithm specification
            
-
            Section: 29.5.4.5 [rand.eng.philox] Status: Ready
- Submitter: Ilya A. Burylov Opened: 2024-08-06 Last modified: 2024-08-21
            
-
            Priority: 1
-
            
-
            View other active issues in [rand.eng.philox].
            
-
            View all other issues in [rand.eng.philox].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-The P2075R6 proposal introduced the Philox engine and described the algorithm closely 
-following the original paper 
-(further Random123sc11).
-
            
-Matt Stephanson implemented P2075R6 and the 10000'th number did not match. Further investigation revealed 
-several places in Random123sc11 algorithm description, which either deviate from the reference implementation 
-written by Random123sc11 authors or loosely defined, which opens the way for different interpretations.
-
            
-All major implementations of the Philox algorithm (NumPy, Intel MKL, Nvidia cuRAND, etc.) match the 
-reference implementation written by Random123sc11 authors and we propose to align wording with that.
-
            
-The rationale of proposed changes:
-
            
-
              
-
            1. Random123sc11 refers to the permutation step as "the inputs are permuted using the Threefish 
-N-word P-box", thus the P2075R6 permutation table ([tab:rand.eng.philox.f]) is taken from 
-Threefish algorithm. But the permutation for N=4 in this table does not match the reference 
-implementations. It's worth noting that while Random123sc11 described the Philox algorithm for N=8 
-and N=16, there are no known reference implementations of it either provided by authors or 
-implemented by other libraries. We proposed to drop N=8 and N=16 for now and update 
-the permutation indices for N=4 to match the reference implementation. Note: the proposed resolution 
-allows extending N > 4 cases in the future.
              2. 
-
            2. The original paper describes the S-box update for X values in terms of L' and 
-R' but does not clarify their ordering as part of the counter. In order to match Random123sc11 
-reference implementation the ordering should be swapped.
              3. 
-
            3. Philox alias templates should be updated, because the current ordering of constants matches the 
-specific optimization in the reference Random123sc11 implementation and not the generic algorithm 
-description.
              4. 
-
            
-
            
-All proposed modifications below are confirmed by:
-
            
-
              
-
            • Philox algorithm coauthor Mark Moraes who is planning to publish errata for the original Random123sc11 
-Philox paper.
              • 
-
            • Matt Stephanson, who originally found the mismatch in P2075R6
              • 
-
            • The updated 
-reference implementation.
              • 
-
            
-
-
            [2024-08-21; Reflector poll]
            
-
-
            
-Set priority to 1 after reflector poll.
-
            
-
-
            [2024-08-21; Move to Ready at LWG telecon]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
-
              
-
            1. Modify 29.5.4.5 [rand.eng.philox], [tab:rand.eng.philox.f] as indicated (This effectively reduces
-16 data columns to 4 data columns and 4 data rows to 2 data rows):
              
-
-
              
-
-
-
-  
-  
-
-
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-
-
-
-  
-
-
-  
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-
-
-  
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-
-
-  
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-
-  
-  
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-
-
              Table 101 — Values for the word permutation fn(j) [tab:rand.eng.philox.f]
              fn(j)j
              0123456789101112131415
              n
              201
              420130231
              821476503
              160921361141510712314581
               
-
-
              
-
              2. 
-
-
            2. Modify 29.5.4.5 [rand.eng.philox] as indicated:
              
-
-
              
-
              
--4- […]
-
              
-
                
-
              1. (4.1) — […]
                2. 
-
              2. (4.2) — The following computations are applied to the elements of the V sequence:
                
-
                
-
                
-X2k+0 = mulhimullo(V2k+1,Mk,w)
-xor keykq xor V2k+1
-
                
-X2k+1 = mullomulhi(V2k+1,Mk,w)
- xor keykq xor V2k
-
                
-
                
-
                3. 
-
              
-
              
--5- […]
-
              
--6- Mandates:
-
              
-
                
-
              1. (6.1) — […]
                2. 
-
              2. (6.2) — n == 2 || n == 4 || n == 8 || n == 16 is true, and
                3. 
-
              3. (6.3) — […]
                4. 
-
              4. (6.4) — […]
                5. 
-
              
-
-
              
-
              3. 
-
-
            3. Modify 29.5.6 [rand.predef] as indicated:
              
-
-
              
-
              -using philox4x32 =
-      philox_engine<uint_fast32_t, 32, 4, 10,
-       0xCD9E8D570xD2511F53, 0x9E3779B9, 0xD2511F530xCD9E8D57, 0xBB67AE85>;
-
              
-
              
-
              
--11- Required behavior: The 10000th consecutive invocation a default-constructed 
-object of type philox4x32 produces the value 1955073260.
-
              
-
              
-
              -using philox4x64 =
-      philox_engine<uint_fast64_t, 64, 4, 10,
-       0xCA5A8263951211570xD2E7470EE14C6C93, 0x9E3779B97F4A7C15, 0xD2E7470EE14C6C930xCA5A826395121157, 0xBB67AE8584CAA73B>;
-
              
-
              
-
              
--12- Required behavior: The 10000th consecutive invocation a default-constructed 
-object of type philox4x64 produces the value 3409172418970261260.
-
              
-
              
-
              
-
              4. 
-
-
            
-
-
-
-
-
-
            
-
            4135(i). The helper lambda of std::erase for list should specify return type as
-  bool
            
-
            Section: 23.3.7.7 [forward.list.erasure], 23.3.9.6 [list.erasure] Status: Tentatively Ready
- Submitter: Hewill Kang Opened: 2024-08-07 Last modified: 2024-08-21
            
-
            Priority: Not Prioritized
-
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-std::erase for list is specified to return
-erase_if(c, [&](auto& elem) { return elem == value; }).
-However, the template parameter Predicate of erase_if only requires that the
-type of decltype(pred(...)) satisfies boolean-testable, i.e., the
-return type of elem == value is not necessarily bool.
-
            
-This means it's worth explicitly specifying the lambda's return type as bool to avoid some 
-pedantic cases (demo):
-
            
-
            -#include <list>
-
-struct Bool {
-  Bool(const Bool&) = delete;
-  operator bool() const;
-};
-
-struct Int {
-  Bool& operator==(Int) const;
-};
-
-int main() {
-  std::list<Int> l;
-  std::erase(l, Int{}); // unnecessary hard error
-}
-
            
-
-
            [2024-08-21; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after nine votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
-
              
-
-
            1. Modify 23.3.7.7 [forward.list.erasure] as indicated:
              
-
-
              
-
              -template<class T, class Allocator, class U = T>
-  typename forward_list<T, Allocator>::size_type
-    erase(forward_list<T, Allocator>& c, const U& value);
-
              
-
              
-
              
--1- Effects: Equivalent to:
-  return erase_if(c, [&](const auto& elem) -> bool { return elem == value; });
-
              
-
              
-
              
-
              2. 
-
-
            2. Modify 23.3.9.6 [list.erasure] as indicated:
              
-
-
              
-
              -template<class T, class Allocator, class U = T>
-  typename list<T, Allocator>::size_type
-    erase(list<T, Allocator>& c, const U& value);
-
              
-
              
-
              
--1- Effects: Equivalent to:
-  return erase_if(c, [&](const auto& elem) -> bool { return elem == value; });
-
              
-
              
-
              
-
              3. 
-
-
            
-
-
-
-
-
-
            
-
            4140(i). Useless default constructors for bit reference types
            
-
            Section: 22.9.2.1 [template.bitset.general], 23.3.12.1 [vector.bool.pspc] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-21 Last modified: 2024-09-18
            
-
            Priority: Not Prioritized
-
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The standard shows a private default constructor for
-bitset<N>::reference
-but does not define its semantics, and nothing in the spec refers to it.
-It was present in C++98, then in C++11 it got noexcept added to it,
-and in C++23 it was made constexpr by P2417R2. That's quite
-a lot of churn for an unusuable member function with no definition.
-
            
-
            
-In libstdc++ it's declared as private, but never defined.
-In libc++ it doesn't exist at all.
-In MSVC it is private and defined (and presumably used somewhere).
-There's no reason for the standard to declare it.
-Implementers can define it as private if they want to, or not.
-The spec doesn't need to say anything for that to be true.
-We can also remove the friend declaration, because implementers know how to
-do that too.
-
            
-
            
-I suspect it was added as private originally so that it didn't look like
-reference should have an implicitly-defined default constructor,
-which would have been the case in previous standards with no other
-constructors declared.
-However, C++20 added reference(const reference&) = default;
-which suppresses the implicit default constructor, so declaring the
-default constructor as private is now unnecessary.
-
            
-
            
-Jiang An pointed out in an editorial pull request that
-vector<bool, Alloc>::reference
-has exactly the same issue.
-
            
-
-
            [2024-09-18; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after eight votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
-
              
-
            1. Modify 22.9.2.1 [template.bitset.general] as indicated:
              
-
              
-
              -namespace std {
-  template<size_t N> class bitset {
-  public:
-    // bit reference
-    class reference {
-      friend class bitset;
-      constexpr reference() noexcept;
-
-    public:
-      constexpr reference(const reference&) = default;
-      constexpr ~reference();
-      constexpr reference& operator=(bool x) noexcept;            // for b[i] = x;
-      constexpr reference& operator=(const reference&) noexcept;  // for b[i] = b[j];
-      constexpr bool operator~() const noexcept;                  // flips the bit
-      constexpr operator bool() const noexcept;                   // for x = b[i];
-      constexpr reference& flip() noexcept;                       // for b[i].flip();
-    };
-
              
-
              
-
              2. 
-
-
            2. Modify 23.3.12.1 [vector.bool.pspc], vector<bool, Allocator> synopsis, as indicated:
              
-
              
-
              -namespace std {
-  template<class Allocator>
-  class vector<bool, Allocator> {
-  public:
-    // types
-    […]
-    // bit reference
-    class reference {
-      friend class vector;
-      constexpr reference() noexcept;
-
-    public:
-      constexpr reference(const reference&) = default;
-      constexpr ~reference();
-      constexpr operator bool() const noexcept;
-      constexpr reference& operator=(bool x) noexcept;
-      constexpr reference& operator=(const reference& x) noexcept;
-      constexpr const reference& operator=(bool x) const noexcept;
-      constexpr void flip() noexcept;   // flips the bit
-    };
-
              
-
              
-
              3. 
-
            
-
-
-
-
-
-
-
            
-
            4141(i). Improve prohibitions on "additional storage"
            
-
            Section: 22.5.3.1 [optional.optional.general], 22.6.3.1 [variant.variant.general], 22.8.6.1 [expected.object.general], 22.8.7.1 [expected.void.general] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-22 Last modified: 2024-09-18
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [optional.optional.general].
            
-
            View all other issues in [optional.optional.general].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-This issue was split out from issue 4015(i).
-
            
-
            
-optional, variant and expected all use similar wording to require
-their contained value to be a subobject, rather than dynamically allocated
-and referred to by a pointer, e.g.
-
            
-When an instance of optional<T> contains a value,
-it means that an object of type T, referred to as the
-optional object’s contained value,
-is allocated within the storage of the optional object.
-Implementations are not permitted to use additional storage,
-such as dynamic memory, to allocate its contained value.
-
            
-
            
-
-
            
-During the LWG reviews of P2300 in St. Louis, concerns were
-raised about the form of this wording and whether it's normatively meaningful.
-Except for the special case of standard-layout class types, the standard has
-very few requirements on where or how storage for subobjects is allocated.
-The library should not be trying to dictate more than the language guarantees.
-It would be better to refer to wording from 6.7.2 [intro.object]
-such as subobject, provides storage, or nested within.
-Any of these terms would provide the desired properties, without using
-different (and possibly inconsistent) terminology.
-
            
-
            
-Using an array of bytes to provide storage for the contained value would
-make it tricky to meet the constexpr requirements of types like optional.
-This means in practice, the most restrictive of these terms, subobject,
-is probably accurate and the only plausible implementation strategy.
-However, I don't see any reason to outlaw other implementation strategies that
-might be possible in future (say, with a constexpr type cast, or non-standard
-compiler-specific instrinics).
-For this reason, the proposed resolution below uses nested within,
-which provides the desired guarantee without imposing additional restrictions
-on implementations.
-
            
-
-
            [2024-09-18; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after seven votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
-
              
-
            1. Modify 22.5.3.1 [optional.optional.general] as indicated:
              
-
-
              
-[Drafting note:
-This edit modifies the same paragraph as issue 4015(i),
-but that other issue intentionally doesn't touch the affected sentence here
-(except for removing the italics on "contained value").
-The intention is that the merge conflict can be resolved in the obvious way:
-"An optional object's contained value
-is nested within (6.7.2 [intro.object]) the optional object."]
-
              
-
-
              
-
              
--1-
-Any instance of optional<T> at any given time either
-contains a value or does not contain a value.
-When an instance of optional<T> contains a value,
-it means that an object of type T,
-referred to as the optional object's contained value,
-is
-allocated within the storage of
-nested within (6.7.2 [intro.object])
-the optional object.
-
-Implementations are not permitted to use additional storage,
-such as dynamic memory, to allocate its contained value.
-
-When an object of type optional<T>
-is contextually converted to bool,
-the conversion returns true if the object contains a value;
-otherwise the conversion returns false.
-
              
-
              
-
              2. 
-
-
            2. Modify 22.6.3.1 [variant.variant.general] as indicated:
              
-
-
              
-
              
--1-
-Any instance of variant at any given time either
-holds a value of one of its alternative types or holds no value.
-When an instance of variant holds a value of alternative type T,
-it means that a value of type T,
-referred to as the variant object's contained value,
-is
-allocated within the storage of
-nested within (6.7.2 [intro.object])
-the variant object.
-
-Implementations are not permitted to use additional storage,
-such as dynamic memory, to allocate the contained value.
-
-
              
-
              
-
              3. 
-
-
            3. Modify 22.8.6.1 [expected.object.general] as indicated:
              
-
-
              
-
              
--1-
-Any object of type expected<T, E> either contains
-a value of type T or a value of type E
-within its own storage
-nested within (6.7.2 [intro.object]) it.
-
-Implementations are not permitted to use additional storage,
-such as dynamic memory,
-to allocate the object of type T or the object of type E.
-
-Member has_val indicates whether the
-expected<T, E> object contains an object of type T.
-
              
-
              
-
              4. 
-
-
            4. Modify 22.8.7.1 [expected.void.general] as indicated:
              
-
-
              
-
              
--1-
-Any object of type expected<T, E> either represents
-a value of type T, or contains a value of type E
-within its own storage
-nested within (6.7.2 [intro.object]) it.
-
-Implementations are not permitted to use additional storage,
-such as dynamic memory, to allocate the object of type E.
-
-Member has_val indicates whether the
-expected<T, E> represents a value of type T.
-
              
-
              
-
              5. 
-
            
-
-
-
-
-
-
-
            
-
            4142(i). format_parse_context::check_dynamic_spec should require at least one type
            
-
            Section: 28.5.6.6 [format.parse.ctx] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-28 Last modified: 2024-09-18
            
-
            Priority: Not Prioritized
-
            
-
            View all other issues in [format.parse.ctx].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The Mandates: conditions for format_parse_context::check_dynamic_spec
-are:
-
            
--14- Mandates:
-The types in Ts... are unique. Each type in Ts... is one of bool,
-char_type, int, unsigned int, long long int, unsigned long long int,
-float, double, long double, const char_type*,
-basic_string_view<char_type>, or const void*.
-
            
-
            
-
            
-There seems to be no reason to allow Ts to be an empty pack,
-that's not useful. There is no valid arg-id value that can be passed to it
-if the list of types is empty, since arg(n) will never be one of the types
-in an empty pack. So it's never a constant expression if the pack is empty.
-
            
-
-
            [2024-09-18; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after seven votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
-
              
-
            1. Modify 28.5.6.6 [format.parse.ctx] as indicated:
              
-
-
              template<class... Ts>
-  constexpr void check_dynamic_spec(size_t id) noexcept;
-
              
-
              
-
              
--14- Mandates:
-sizeof...(Ts) ≥ 1.
-The types in Ts... are unique. Each type in Ts... is one of bool,
-char_type, int, unsigned int, long long int, unsigned long long int,
-float, double, long double, const char_type*,
-basic_string_view<char_type>, or const void*.
-
              
-
              
--15- Remarks:
-A call to this function is a core constant expression only if:
-
                
-
              1. (15.1) — id < num_args_ is true and
                2. 
-
              2. (15.2) — the type of the corresponding format argument
-(after conversion to basic_format_arg<Context>)
-is one of the types in Ts....
                3. 
-
              
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
-
            
-
            4144(i). Disallow unique_ptr<T&, D>
            
-
            Section: 20.3.1.3.1 [unique.ptr.single.general] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-08-30 Last modified: 2024-11-13
            
-
            Priority: Not Prioritized
-
            
-
            View all other issues in [unique.ptr.single.general].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-It seems that we currently allow nonsensical specializations of unique_ptr
-such as unique_ptr<int&, D>
-and unique_ptr<void()const, D>
-(a custom deleter that defines D::pointer is needed, because otherwise
-the pointer type would default to invalid types like
-int&* or void(*)()const).
-There seems to be no reason to support these "unique pointer to reference"
-and "unique pointer to abominable function type" specializations,
-or any specialization for a type that you couldn't form a raw pointer to.
-
            
-
-
            
-Prior to C++17, the major library implementations rejected such specializations
-as a side effect of the constraints for the
-unique_ptr(auto_ptr<U>&&) constructor
-being defined in terms of is_convertible<U*, T*>.
-This meant that overload resolution for any constructor of unique_ptr
-would attempt to form the type T* and fail if that was invalid.
-With the removal of auto_ptr in C++17, that constructor was removed
-and now unique_ptr<int&, D> can be instantiated
-(assuming any zombie definition of auto_ptr is not enabled by the library).
-This wasn't intentional, but just an accident caused by not explicitly
-forbidding such types.
-
            
-
-
            
-Discussion on the LWG reflector led to near-unanimous support for explicitly
-disallowing these specializations for non-pointable types.
-
            
-
-
            [2024-11-13; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after eight votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
-
              
-
            1. Modify 20.3.1.3.1 [unique.ptr.single.general] as indicated:
              
-
              
-
              -?-
-A program that instantiates the definition of
-unique_ptr<T, D>
-is ill-formed if T* is an invalid type.
-
              
-[Note:
-This prevents the intantiation of specializations such as
-unique_ptr<T&, D>
-and unique_ptr<int() const, D>.
-— end note]
-              
-
              
-
              -1-
-The default type for the template parameter D is default_delete.
-A client-supplied template argument D shall be a function object type
-(22.10 [function.objects]), lvalue reference to function,
-or lvalue reference to function object type for which,
-given a value d of type D and a value ptr of type
-unique_ptr<T, D>::pointer,
-the expression d(ptr) is valid and has the effect of disposing of the pointer
-as appropriate for that deleter.
-
              
-
              -2-
-If the deleter’s type D is not a reference type,
-D shall meet the Cpp17Destructible requirements (Table 35).
-
              
-
              -3-
-If the qualified-id remove_reference_t<D>::pointer
-is valid and denotes a type (13.10.3 [temp.deduct]),
-then unique_ptr<T, D>::pointer
-shall be a synonym for remove_reference_t<D>::pointer.
-Otherwise unique_ptr<T, D>::pointer shall be a synonym for
-element_type*.
-The type unique_ptr<T, D>::pointer shall meet the
-Cpp17NullablePointer requirements (Table 36).
-
              
-
              -4-
-[Example 1:
- Given an allocator type X (16.4.4.6.1 [allocator.requirements.general])
-and letting A be a synonym for allocator_traits<X>,
-the types A::pointer, A::const_pointer, A::void_pointer,
-and A::const_void_pointer may be used as
-unique_ptr<T, D>::pointer.
-— end example]
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4147(i). Precondition on inplace_vector::emplace
            
-
            Section: 23.2.4 [sequence.reqmts] Status: Tentatively Ready
- Submitter: Arthur O'Dwyer Opened: 2024-08-26 Last modified: 2024-09-18
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [sequence.reqmts].
            
-
            View all other issues in [sequence.reqmts].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-Inserting into the middle of an inplace_vector, just like inserting into the middle of a 
-vector or deque, requires that we construct the new element out-of-line, shift 
-down the trailing elements (Cpp17MoveAssignable), and then move-construct the new element 
-into place (Cpp17MoveInsertable). P0843R14 failed to make this change, but 
-it should have.
-
            
-
-
            [2024-09-18; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after nine votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
-
              
-
            1. Modify 23.2.4 [sequence.reqmts] as indicated:
              
-
-
              -a.emplace(p, args)
-
              
-
              
-
              
--19- Result: iterator.
-
              
--20- Preconditions: T is Cpp17EmplaceConstructible into X 
-from args. For vector, inplace_vector, and deque, 
-T is also Cpp17MoveInsertable into X and Cpp17MoveAssignable.
-
              
--21- Effects: Inserts an object of type T constructed with 
-std::forward<Args>(args)... before p.
-
              
-[Note 1: args can directly or indirectly refer to a value in a. 
-— end note]
-
              
--22- Returns: An iterator that points to the new element constructed from args 
-into a.
-
              
-
              
-
              
-
              2. 
-
-
            
-
-
-
-
-
-
-
            
-
            4148(i). unique_ptr::operator* should not allow dangling references
            
-
            Section: 20.3.1.3.5 [unique.ptr.single.observers] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-09-02 Last modified: 2024-09-18
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [unique.ptr.single.observers].
            
-
            View all other issues in [unique.ptr.single.observers].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-If unique_ptr<T,D>::element_type* and D::pointer
-are not the same type, it's possible for operator*() to return a dangling
-reference that has undefined behaviour.
-
            
-
            
-  struct deleter {
-    using pointer = long*;
-    void operator()(pointer) const {}
-  };
-  long l = 0;
-  std::unique_ptr<const int, deleter> p(&l);
-  int i = *p; // undefined
-
            
-
            
-We should make this case ill-formed.
-
            
-
-
            [2024-09-18; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after seven votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
              
-
            1. Modify 20.3.1.3.5 [unique.ptr.single.observers] as indicated:
              
-
              
-
              -constexpr add_lvalue_reference_t<T> operator*() const noexcept(noexcept(*declval<pointer>()));
-
              
-
              
-
              
--?- Mandates:
-reference_converts_from_temporary_v<add_lvalue_reference_t<T>,
-decltype(*declval<pointer>())>
-is false.
-
-
              
-
              
--1- Preconditions: get() != nullptr is true.
-
              
-
              
--2- Returns: *get().
-
              
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4153(i). Fix extra "-1" for philox_engine::max()
            
-
            Section: 29.5.4.5 [rand.eng.philox] Status: Tentatively Ready
- Submitter: Ruslan Arutyunyan Opened: 2024-09-18 Last modified: 2024-10-02
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [rand.eng.philox].
            
-
            View all other issues in [rand.eng.philox].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-There is a typo in philox_engine wording that makes "-1" two times
-instead of one for max() method.
-The reason for that typo is that the wording was originally inspired by
-mersenne_twister_engine but after getting feedback that what is written in
-the philox_engine synopsis is not C++ code, the authors introduced the
-m variable (as in subtract_with_carry_engine) but forgot to remove
-"-1" in the m definition.
-
            
-
            
-Note: after the proposed resolution below is applied the m variable
-could be reused in other places: basically in all places where the mod  2^w
-pattern appears (like subtract_with_carry_engine does).
-The authors don’t think it’s worth changing the rest of the wording to reuse
-the m variable.
-If somebody thinks otherwise, please provide such feedback.
-
            
-
-
            [2024-10-02; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after six votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
-
              
-
            1. Modify 29.5.4.5 [rand.eng.philox] as indicated:
              
-
              
--1-
-A philox_engine random number engine produces unsigned integer random numbers
-in the closed interval [0, m]),
-where m = 2w − 1
-and the template parameter w defines the range of the produced numbers.
-
              
-
              2. 
-
            
-
-
-
-
-
-
-
            
-
            4154(i). The Mandates for std::packaged_task's constructor from a callable entity should consider decaying
            
-
            Section: 32.10.10.2 [futures.task.members] Status: Ready
- Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-10-09
            
-
            Priority: 3
-
            
-
            View other active issues in [futures.task.members].
            
-
            View all other issues in [futures.task.members].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-Currently, 32.10.10.2 [futures.task.members]/3 states:
-
            
-Mandates:
-is_invocable_r_v<R, F&, ArgTypes...> is true.
-
            
-where F& can be a reference to a cv-qualified function object type.
-
            
-
            
-However, in mainstream implementations (libc++, libstdc++, and MSVC STL),
-the stored task object always has a cv-unqualified type,
-and thus the cv-qualification is unrecognizable in operator().
-
            
-
            
-Since 22.10.17.3.2 [func.wrap.func.con] uses a decayed type,
-perhaps we should also so specify for std::packaged_task.
-
            
-
-
            [2024-10-02; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll.
-
            
-
            
-"Fix preconditions, f doesn't need to be invocable, we only invoke the copy."
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            
-This wording is relative to N4988.
-
            
-
              
-
            1. Modify 32.10.10.2 [futures.task.members] as indicated:
              
-
              
-
              
--3- Mandates:
-is_invocable_r_v<R, Fdecay_t<F>&, ArgTypes...>
-is true.
-
              
-[...]
-
              
--5- Effects:
-Constructs a new packaged_task object with a shared state and initializes
-the object's stored task
-of type decay_t<F>
-with std::forward<F>(f).
-
              
-
              
-
              2. 
-
            
-
            
-
-
            [2024-10-02; Jonathan provides improved wording]
            
-
-
            Drop preconditions as suggested on reflector.
            
-
-
            [2024-10-02; LWG telecon]
            
-
-
            
-Clarify that "of type decay_t<F>"
-is supposed to be specifying the type of the stored task.
-
            
-
-
            [2024-10-09; LWG telecon: Move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
              
-
            1. Modify 32.10.10.2 [futures.task.members] as indicated:
              
-
              
-
              template<class F>
-  explicit packaged_task(F&& f);
              
-
              
--2- Constraints:
-remove_cvref_t<F> is not the same type as
-packaged_task<R(ArgTypes...)>.
-
              
-
              
--3- Mandates:
-is_invocable_r_v<R, Fdecay_t<F>&, ArgTypes...>
-is true.
-
              
-
              
--4- Preconditions:
-Invoking a copy of f behaves the same as invoking f.
-
-
              
-
              
--5- Effects:
-Constructs a new packaged_task object with
-a stored task of type decay_t<F> and
-a shared state
-. Initializes
-and initializes
-the object's stored task
-with std::forward<F>(f).
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4157(i). The resolution of LWG3465 was damaged by P2167R3
            
-
            Section: 17.11.6 [cmp.alg] Status: Tentatively Ready
- Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-10-02
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [cmp.alg].
            
-
            View all other issues in [cmp.alg].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-In the resolution of LWG 3465(i),
-F < E was required to be well-formed and
-implicitly convertible to bool.
-However, P2167R3 replaced the convertibility requirements
-with just "each of decltype(E == F) and decltype(E < F)
-models boolean-testable",
-which rendered the type of F < E underconstrained.
-
            
-
-
            [2024-10-02; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after seven votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4988.
-
            
-
              
-
            1. Modify 17.11.6 [cmp.alg] as indicated:
              
-
              
-(6.3) —
-Otherwise, if the expressions
-E == F, E < F, and F < E
-are all well-formed and each of decltype(E == F)
-and,
-decltype(E < F)
-, and decltype(F < E)
-models boolean-testable,
-
              
-  E == F ? partial_ordering::equivalent :
-  E < F  ? partial_ordering::less :
-  F < E  ? partial_ordering::greater :
-           partial_ordering::unordered
-
              
-except that E and F are evaluated only once.
-
              
-
              2. 
-
            
-
-
-
-
-
-
            
-
            4164(i). Missing guarantees for forward_list modifiers
            
-
            Section: 23.3.7.5 [forward.list.modifiers] Status: Ready
- Submitter: Jonathan Wakely Opened: 2024-10-05 Last modified: 2024-10-09
            
-
            Priority: 3
-
            
-
            View all other issues in [forward.list.modifiers].
            
-
            View all issues with Ready status.
            
-
            Discussion:
            
-
            
-The new std::list members added by P1206R7,
-insert_range(const_iterator, R&&),
-prepend_range(R&&), and
-append_range(R&&),
-have the same exception safety guarantee as
-std::list::insert(const_iterator, InputIterator, InputIterator), which is:
-
            
-Remarks:
-Does not affect the validity of iterators and references.
-If an exception is thrown, there are no effects.
-
            
-
            
-
            
-This guarantee was achieved for the new list functions simply by placing
-them in the same set of declarations as the existing insert overloads,
-at the start of 23.3.9.4 [list.modifiers].
-
            
-
-
            
-However, the new std::forward_list members,
-insert_range_after(const_iterator, R&&) and
-prepend_range(R&&),
-do not have the same guarantee as forward_list::insert_after.
-This looks like an omission caused by the fact that insert_after's
-exception safety guarantee is given in a separate paragraph at the start
-of 23.3.7.5 [forward.list.modifiers]:
-
            
-None of the overloads of insert_after
-shall affect the validity of iterators and references,
-and erase_after shall invalidate only iterators and references
-to the erased elements.
-If an exception is thrown during insert_after there shall be no effect.
-
            
-
            
-
-
            
-I think we should give similar guarantees for insert_range_after
-and prepend_range.
-The change might also be appropriate for emplace_after as well.
-A "no effects" guarantee is already given for push_front and emplace_front
-in 23.2.2.2 [container.reqmts] p66, although that doesn't say anything
-about iterator invalidation so we might want to add that to
-23.3.7.5 [forward.list.modifiers] too.
-For the functions that insert a single element, it's trivial to not modify
-the list if allocating a new node of constructing the element throws.
-The strong exception safety guarantee for the multi-element insertion functions
-is easily achieved by inserting into a temporary forward_list first,
-then using splice_after which is non-throwing.
-
            
-
-
-
            [2024-10-09; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll.
-
            
-
            It was suggested to change
-"If an exception is thrown by any of these member functions
-that insert elements there is no effect on the forward_list"
-to simply
-"If an exception is thrown by any of these member functions
-there is no effect on the forward_list"
-
            
-
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            This wording is relative to N4988.
            
-
-
              
-
            1. 
-
              Change 23.3.7.5 [forward.list.modifiers] as indicated:
              
-
              
-None of the overloads of insert_after shall
-member functions in this subclause that insert elements
-affect the validity of iterators and references,
-and erase_after shall invalidate invalidates
-only iterators and references to the erased elements.
-If an exception is thrown
-during insert_after
-by any of these member functions
-there shall be is no effect
-on the forward_list.
-
              
-
-
              2. 
-
            
-
-
            
-
-
            [2024-10-09; LWG suggested improved wording]
            
-
-
            
-The proposed resolution potentially mandates a change to resize when
-increasing the size, requiring implementations to "roll back" earlier
-insertions if a later one throws, so that the size is left unchanged.
-It appears that libstdc++ and MSVC already do this, libc++ does not.
-
            
-
-
            [2024-10-09; LWG telecon: Move to Ready]
            
-
-
-
-
-
            Proposed resolution:
            
-
            This wording is relative to N4988.
            
-
-
              
-
            1. 
-
              Change 23.3.7.5 [forward.list.modifiers] as indicated:
              
-
              
-
-None of the overloads of insert_after shall
-affect the validity of iterators and references,
-and erase_after shall invalidate
-only iterators and references to the erased elements.
-
-The member functions in this subclause do not
-affect the validity of iterators and references when inserting elements,
-and when erasing elements invalidate iterators and references
-to the erased elements only.
-
-If an exception is thrown
-during insert_after
-by any of these member functions
-there shall be is no effect
-on the container.
-
              
-
-
              2. 
-
            
-
-
-
-
-
-
-
-
            
-
            4169(i). std::atomic<T>'s default constructor should be constrained
            
-
            Section: 32.5.8.2 [atomics.types.operations] Status: Tentatively Ready
- Submitter: Giuseppe D'Angelo Opened: 2024-10-15 Last modified: 2024-11-13
            
-
            Priority: Not Prioritized
-
            
-
            View other active issues in [atomics.types.operations].
            
-
            View all other issues in [atomics.types.operations].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The current wording for std::atomic's default constructor in
-32.5.8.2 [atomics.types.operations] specifies:
-
            
-
            
-
            -constexpr atomic() noexcept(is_nothrow_default_constructible_v<T>);
-
            
-
            
-
            
-Mandates: is_default_constructible_v<T> is true.
-
            
-
            
-
            
-
            
-This wording has been added by P0883R2 for C++20, which changed
-std::atomic's default constructor to always value-initialize. Before,
-the behavior of this constructor was not well specified (this was LWG
-issue 2334(i)).
-
            
-The usage of a Mandates element in the specification has as a
-consequence that std::atomic<T> is always default constructible, even
-when T is not. For instance:
-
            
-
            
-
            -// not default constructible:
-struct NDC { NDC(int) {} };
-
-static_assert(std::is_default_constructible<std::atomic<NDC>>); // OK
-
            
-
            
-
            
-The above check is OK as per language rules, but this is user-hostile:
-actually using std::atomic<NDC>'s default constructor results in an
-error, despite the detection saying otherwise.
-
            
-Given that std::atomic<T> already requires T to be complete anyhow
-(32.5.8.1 [atomics.types.generic.general] checks for various type properties
-which require completeness) it would be more appropriate to use a
-constraint instead, so that std::atomic<T> is default constructible if
-and only if T also is.
-
            
-
-
            [2024-11-13; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after seven votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4993.
-
            
-
-
              
-
            1. Modify 32.5.8.2 [atomics.types.operations] as indicated:
              
-
-
              
-
              
-[Drafting note: There is implementation divergence at the moment; libstdc++ already
-implements the proposed resolution and has done so for a while.]
-
              
-
              
-
-
              
-
              -constexpr atomic() noexcept(is_nothrow_default_constructible_v<T>);
-
              
-
              
-
              
--1- ConstraintsMandates: is_default_constructible_v<T> is true.
-
              
--2- Effects: […]
-
              
-
              
-
              
-
-
              2. 
-
            
-
-
-
-
-
            
-
            4170(i). contiguous_iterator should require to_address(I{})
            
-
            Section: 24.3.4.14 [iterator.concept.contiguous] Status: Tentatively Ready
- Submitter: Casey Carter Opened: 2024-11-01 Last modified: 2024-11-13
            
-
            Priority: Not Prioritized
-
            
-
            View all other issues in [iterator.concept.contiguous].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The design intent of the contiguous_iterator concept is that iterators can be converted
-to pointers denoting the same sequence of elements. This enables a common range [i, j)
-or counted range i + [0, n) to be processed with extremely efficient low-level C
-or assembly code that operates on [to_address(i), to_address(j)) (respectively
-to_address(i) + [0, n)).
-
            
-A value-initialized iterator I{} can be used to denote the empty ranges [I{}, I{})
-and I{} + [0, 0). While the existing semantic requirements of contiguous_iterator enable us
-to convert both dereferenceable and past-the-end iterators with to_address, converting
-ranges involving value-initialized iterators to pointer ranges additionally needs
-to_address(I{}) to be well-defined. Note that to_address is already implicitly
-equality-preserving for contiguous_iterator arguments. Given this additional requirement
-to_address(I{}) == to_address(I{}) and to_address(I{}) == to_address(I{)) + 0
-both hold, so the two types of empty ranges involving value-initialized iterators convert
-to empty pointer ranges as desired.
-
            
-
-
            [2024-11-13; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after eight votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4993.
-
            
-
-
              
-
            1. Modify 24.3.4.14 [iterator.concept.contiguous] as indicated:
              
-
-
              
-
              
--1- The contiguous_iterator concept provides a guarantee that the denoted elements are stored contiguously
-in memory.
-
              
-
              
-
              -template<class I>
-  concept contiguous_iterator =
-    random_access_iterator<I> &&
-    derived_from<ITER_CONCEPT(I), contiguous_iterator_tag> &&
-    is_lvalue_reference_v<iter_reference_t<I>> &&
-    same_as<iter_value_t<I>, remove_cvref_t<iter_reference_t<I>>> &&
-    requires(const I& i) {
-      { to_address(i) } -> same_as<add_pointer_t<iter_reference_t<I>>>;
-    };
-
              
-
              
-
              
--2- Let a and b be dereferenceable iterators and c be a non-dereferenceable iterator of type
-I such that b is reachable from a and c is reachable from b, and let D be
-iter_difference_t<I>. The type I models contiguous_iterator only if
-
              
-
-
                
-
              1. (2.1) — to_address(a) == addressof(*a),
                2. 
-
              2. (2.2) — to_address(b) == to_address(a) + D(b - a),
                3. 
-
              3. (2.3) — to_address(c) == to_address(a) + D(c - a),
                4. 
-
              4. (2.?) — to_address(I{}) is well-defined,
                5. 
-
              5. (2.4) — ranges::iter_move(a) has the same type, value category, and effects as
-std::move(*a), and
                6. 
-
              6. (2.5) — if ranges::iter_swap(a, b) is well-formed, it has effects equivalent to
-ranges::swap(*a, *b).
                7. 
-
              
-
              
-
-
              2. 
-
            
-
-
-
-
 
 
diff --git a/lwg-status-date.html b/lwg-status-date.html
index 63a30dcd29..e202869ab2 100644
--- a/lwg-status-date.html
+++ b/lwg-status-date.html
@@ -67,8 +67,8 @@ 
            Index by Status and Date
            
 This document is the Index by Status and Date for the Library Active Issues List,
 Library Defect Reports and Accepted Issues, and Library Closed Issues List.
 
            
-
            Revised 2024-11-18 at 13:27:23 UTC
-
            Ready (15 issues)
            
+
            Revised 2024-11-19 at 16:10:33 UTC
+
            Voting (34 issues)
            
 
@@ -80,44 +80,53 @@ 
            Index by Status and Date
            
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
+
+
@@ -125,184 +134,174 @@ 
            Index by Status and Date
            
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
            
 
            
   Issue
   Duplicates
 
            
 
            4164(i)Ready23.3.7.5 [forward.list.modifiers]Missing guarantees for forward_list modifiers4126(i)Voting17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestanding
 Yes32
 
 
            
 
            4085(i)Ready26.12.2 [alg.rand.generate]ranges::generate_random's helper lambda should specify the return type4157(i)Voting17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R3
 Yes2
 
 
            
 
            4014(i)Ready29.5.4.4 [rand.eng.sub]LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code4144(i)Voting20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D>
 Yes2
 
 
            
 
            4154(i)Ready32.10.10.2 [futures.task.members]The Mandates for std::packaged_task's constructor from a callable entity should consider decaying4148(i)Voting20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling referencesYes
            3216(i)Voting20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_shared
 Yes
 3
 
 
            
 
            4024(i)Ready4024(i)Voting
 20.3.2.2.7 [util.smartptr.shared.create]
 Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite
 Yes
 
 
            
 
            4072(i)Ready22.5.8 [optional.comp.with.t]std::optional comparisons: constrain harder4113(i)Voting21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]>
 Yes1
 
 
            
 
            4134(i)Ready29.5.4.5 [rand.eng.philox]Issue with Philox algorithm specification3886(i)Voting22.5.3.1 [optional.optional.general]Monad mo' problems
 Yes13
 
 
            
 
            4027(i)Ready25.2 [ranges.syn]possibly-const-range should prefer returning const R&4141(i)Voting22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage"
 Yes2
 
 
            
 
            3899(i)Ready25.8.5 [coro.generator.promise]co_yielding elements of an lvalue generator is unnecessarily inefficient4072(i)Voting22.5.8 [optional.comp.with.t]std::optional comparisons: constrain harder
 Yes31
 
 
            
 
            3900(i)Ready25.8.5 [coro.generator.promise]The allocator_arg_t overloads of generator::promise_type::operator new
-should not be constrained4140(i)Voting22.9.2.1 [template.bitset.general]Useless default constructors for bit reference types
 Yes3
 
 
            
 
            4064(i)Ready27.5.1 [cstring.syn]Clarify that std::launder is not needed when using the result of std::memcpy4147(i)Voting23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplace
 Yes3
 
 
            
 
            3918(i)Ready26.11.6 [uninitialized.move]std::uninitialized_move/_n and guaranteed copy elision4164(i)Voting23.3.7.5 [forward.list.modifiers]Missing guarantees for forward_list modifiers
 Yes
 3
 
 
            
 
            4112(i)Ready25.5.2 [range.utility.helpers]has-arrow should required operator->() to be const-qualified4135(i)Voting23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as
+  bool
 Yes
 
 
 
            
 
            3436(i)Ready26.11.8 [specialized.construct]std::construct_at should support arrays4170(i)Voting24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{})
 Yes2
 
 
            
 
            4044(i)Ready31.7.10 [print.fun]Confusing requirements for std::print on POSIX platforms4027(i)Voting25.2 [ranges.syn]possibly-const-range should prefer returning const R&
 Yes32
 
 
            
-
            Tentatively Ready (19 issues)
            
-
-  
-  
-  
-  
-  
-  
-  
-
-
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
+
+
@@ -310,95 +309,84 @@ 
            Tentatively Ready (19 issues)
            
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
            
 
            IssueStatusSectionTitleProposed ResolutionPriorityDuplicates
            4144(i)Tentatively Ready20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D>4112(i)Voting25.5.2 [range.utility.helpers]has-arrow should required operator->() to be const-qualified
 Yes
 
 
 
            
 
            4170(i)Tentatively Ready24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{})3899(i)Voting25.8.5 [coro.generator.promise]co_yielding elements of an lvalue generator is unnecessarily inefficient
 Yes3
 
 
            
 
            4169(i)Tentatively Ready32.5.8.2 [atomics.types.operations]std::atomic<T>'s default constructor should be constrained3900(i)Voting25.8.5 [coro.generator.promise]The allocator_arg_t overloads of generator::promise_type::operator new
+should not be constrained
 Yes3
 
 
            
 
            4088(i)Tentatively Ready31.7.6.3.5 [ostream.formatted.print]println ignores the locale imbued in std::ostream4119(i)Voting25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed
 Yes
 
 
 
            
 
            4157(i)Tentatively Ready17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R33918(i)Voting26.11.6 [uninitialized.move]std::uninitialized_move/_n and guaranteed copy elision
 Yes3
 
 
            
 
            3216(i)Tentatively Ready20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_shared3436(i)Voting26.11.8 [specialized.construct]std::construct_at should support arrays
 Yes32
 
 
            
 
            4153(i)Tentatively Ready29.5.4.5 [rand.eng.philox]Fix extra "-1" for philox_engine::max()4085(i)Voting26.12.2 [alg.rand.generate]ranges::generate_random's helper lambda should specify the return type
 Yes2
 
 
            
 
            3886(i)Tentatively Ready22.5.3.1 [optional.optional.general]Monad mo' problems4064(i)Voting27.5.1 [cstring.syn]Clarify that std::launder is not needed when using the result of std::memcpy
 Yes
 3
 
 
            
 
            4084(i)Tentatively Ready4084(i)Voting
 28.3.4.3.3.3 [facet.num.put.virtuals]
 std::fixed ignores std::uppercase
 Yes
 
 
            
 
            4148(i)Tentatively Ready20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling references4142(i)Voting28.5.6.6 [format.parse.ctx]format_parse_context::check_dynamic_spec should require at least one type
 Yes
 
 
 
            
 
            4141(i)Tentatively Ready22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage"4014(i)Voting29.5.4.4 [rand.eng.sub]LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code
 Yes2
 
 
            
 
            4140(i)Tentatively Ready22.9.2.1 [template.bitset.general]Useless default constructors for bit reference types4134(i)Voting29.5.4.5 [rand.eng.philox]Issue with Philox algorithm specification
 Yes1
 
 
            
 
            4147(i)Tentatively Ready23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplace4153(i)Voting29.5.4.5 [rand.eng.philox]Fix extra "-1" for philox_engine::max()
 Yes
 
 
 
            
 
            4142(i)Tentatively Ready28.5.6.6 [format.parse.ctx]format_parse_context::check_dynamic_spec should require at least one type4124(i)Voting30.12 [time.format]Cannot format zoned_time with resolution coarser than seconds
 Yes
 
 
 
            
 
            4135(i)Tentatively Ready23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as
-  bool4088(i)Voting31.7.6.3.5 [ostream.formatted.print]println ignores the locale imbued in std::ostream
 Yes
 
 
 
            
 
            4126(i)Tentatively Ready17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestandingYes2
            4113(i)Tentatively Ready21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]>4044(i)Voting31.7.10 [print.fun]Confusing requirements for std::print on POSIX platforms
 Yes3
 
 
            
 
            4119(i)Tentatively Ready25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed4169(i)Voting32.5.8.2 [atomics.types.operations]std::atomic<T>'s default constructor should be constrained
 Yes
 
 
 
            
 
            4124(i)Tentatively Ready30.12 [time.format]Cannot format zoned_time with resolution coarser than seconds4154(i)Voting32.10.10.2 [futures.task.members]The Mandates for std::packaged_task's constructor from a callable entity should consider decaying
 Yes3
 
 
            
 
            
@@ -495,7 +483,7 @@ 
            Tentatively NAD (9 issues)
            
 
 
 
-
            New (439 issues)
            
+
            New (438 issues)
            
 
@@ -653,15 +641,6 @@ 
            New (439 issues)
            
-
-
-
-
-
-
-
-
-
@@ -4512,7 +4491,7 @@ 
            New (439 issues)
            
 
            
   Issue
 
 
            
 
            4130(i)New17.6.5 [ptr.launder]Preconditions for std::launder might be overly strictYes3
            
 3210(i)
 New
 
 
            
 
            
-
            Open (78 issues)
            
+
            Open (81 issues)
            
 
@@ -4524,6 +4503,33 @@ 
            Open (78 issues)
            
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -5226,7 +5232,7 @@ 
            Open (78 issues)
            
 
            
   Issue
   Duplicates
 
            
 
            4130(i)Open17.6.5 [ptr.launder]Preconditions for std::launder might be overly strictYes3
            3454(i)Open20.2.3 [pointer.traits]pointer_traits::pointer_to should be constexprYes
            2991(i)Open22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Yes
            
 2136(i)
 Open
 16.3.2 [structure]
 
 
            
 
            
-
            LEWG (28 issues)
            
+
            LEWG (26 issues)
            
 
@@ -5283,15 +5289,6 @@ 
            LEWG (28 issues)
            
-
-
-
-
-
-
-
-
-
@@ -5413,15 +5410,6 @@ 
            LEWG (28 issues)
            
-
-
-
-
-
-
-
-
-
diff --git a/lwg-status.html b/lwg-status.html
index a19fbcf5fe..e7c8ac435f 100644
--- a/lwg-status.html
+++ b/lwg-status.html
@@ -62,8 +62,8 @@ 
            Index by Status and Section
            Library Defect Reports and Accepted Issues, and Library Closed Issues List.
 
            
 
-
            Revised 2024-11-18 at 13:27:23 UTC
-
            Ready (15 issues)
            
+
            Revised 2024-11-19 at 16:10:33 UTC
+
            Voting (34 issues)
            
 
            
   Issue
 
 
            
 
            3454(i)LEWG20.2.3 [pointer.traits]pointer_traits::pointer_to should be constexprYes
            
 3445(i)
 LEWG
 19.2.1 [networking.ts::socket.iostream.cons]
 
 
            
 
            2991(i)LEWG22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Yes
            
 2884(i)
 LEWG
 23 [containers]
 
 
            
@@ -75,276 +75,228 @@ 
            Index by Status and Section
            
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
            
 
            
   Issue
   Duplicates
 
            
 
            4024(i)Ready20.3.2.2.7 [util.smartptr.shared.create]Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite4126(i)Voting17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestanding
 Yes
 2
 
 
            
 
            4072(i)Ready22.5.8 [optional.comp.with.t]std::optional comparisons: constrain harderYes1
            4164(i)Ready23.3.7.5 [forward.list.modifiers]Missing guarantees for forward_list modifiers4157(i)Voting17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R3
 Yes3
 
            4027(i)Ready25.2 [ranges.syn]possibly-const-range should prefer returning const R&Yes2
 
 
            
 
            4112(i)Ready25.5.2 [range.utility.helpers]has-arrow should required operator->() to be const-qualified4144(i)Voting20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D>
 Yes
 
 
 
            
 
            3899(i)Ready25.8.5 [coro.generator.promise]co_yielding elements of an lvalue generator is unnecessarily inefficient4148(i)Voting20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling references
 Yes3
 
            3900(i)Ready25.8.5 [coro.generator.promise]The allocator_arg_t overloads of generator::promise_type::operator new
-should not be constrainedYes3
 
 
            
 
            3918(i)Ready26.11.6 [uninitialized.move]std::uninitialized_move/_n and guaranteed copy elision3216(i)Voting20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_shared
 Yes
 3
 
 
            
 
            3436(i)Ready26.11.8 [specialized.construct]std::construct_at should support arrays4024(i)Voting20.3.2.2.7 [util.smartptr.shared.create]Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite
 Yes
 2
 
 
            
 
            4085(i)Ready26.12.2 [alg.rand.generate]ranges::generate_random's helper lambda should specify the return type4113(i)Voting21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]>
 Yes2
 
 
            
 
            4064(i)Ready27.5.1 [cstring.syn]Clarify that std::launder is not needed when using the result of std::memcpy3886(i)Voting22.5.3.1 [optional.optional.general]Monad mo' problems
 Yes
 3
 
 
            
 
            4014(i)Ready29.5.4.4 [rand.eng.sub]LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code4141(i)Voting22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage"
 Yes2
 
 
            
 
            4134(i)Ready29.5.4.5 [rand.eng.philox]Issue with Philox algorithm specification4072(i)Voting22.5.8 [optional.comp.with.t]std::optional comparisons: constrain harder
 Yes
 1
 
 
            
 
            4044(i)Ready31.7.10 [print.fun]Confusing requirements for std::print on POSIX platforms4140(i)Voting22.9.2.1 [template.bitset.general]Useless default constructors for bit reference types
 Yes3
 
            4154(i)Ready32.10.10.2 [futures.task.members]The Mandates for std::packaged_task's constructor from a callable entity should consider decayingYes3
 
 
            
-
            Tentatively Ready (19 issues)
            
-
-  
-  
-  
-  
-  
-  
-  
-
-
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
-
-
+
+
+
+
-
+
-
-
+
+
@@ -352,8 +304,8 @@ 
            Tentatively Ready (19 issues)
            
-
-
+
+
@@ -361,8 +313,26 @@ 
            Tentatively Ready (19 issues)
            
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -370,8 +340,8 @@ 
            Tentatively Ready (19 issues)
            
-
-
+
+
@@ -379,8 +349,8 @@ 
            Tentatively Ready (19 issues)
            
-
-
+
+
@@ -388,14 +358,32 @@ 
            Tentatively Ready (19 issues)
            
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
            
 
            IssueStatusSectionTitleProposed ResolutionPriorityDuplicates
            4126(i)Tentatively Ready17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestanding4147(i)Voting23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplace
 Yes2
 
 
            
 
            4157(i)Tentatively Ready17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R34164(i)Voting23.3.7.5 [forward.list.modifiers]Missing guarantees for forward_list modifiers
 Yes3
 
 
            
 
            4144(i)Tentatively Ready20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D>4135(i)Voting23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as
+  bool
 Yes
 
 
 
            
 
            4148(i)Tentatively Ready20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling references4170(i)Voting24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{})
 Yes
 
 
 
            
 
            3216(i)Tentatively Ready20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_shared4027(i)Voting25.2 [ranges.syn]possibly-const-range should prefer returning const R&
 Yes32
 
 
            
 
            4113(i)Tentatively Ready21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]>4112(i)Voting25.5.2 [range.utility.helpers]has-arrow should required operator->() to be const-qualified
 Yes
 
 
 
            
 
            3886(i)Tentatively Ready22.5.3.1 [optional.optional.general]Monad mo' problems3899(i)Voting25.8.5 [coro.generator.promise]co_yielding elements of an lvalue generator is unnecessarily inefficient
 Yes
 3
 
 
            
 
            4141(i)Tentatively Ready22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage"3900(i)Voting25.8.5 [coro.generator.promise]The allocator_arg_t overloads of generator::promise_type::operator new
+should not be constrained
 Yes3
 
 
            
 
            4140(i)Tentatively Ready22.9.2.1 [template.bitset.general]Useless default constructors for bit reference types4119(i)Voting25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed
 Yes
 
 
 
            
 
            4147(i)Tentatively Ready23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplace3918(i)Voting26.11.6 [uninitialized.move]std::uninitialized_move/_n and guaranteed copy elision
 Yes3
 
 
            
 
            4135(i)Tentatively Ready23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as
-  bool3436(i)Voting26.11.8 [specialized.construct]std::construct_at should support arrays
 Yes2
 
 
            
 
            4170(i)Tentatively Ready24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{})4085(i)Voting26.12.2 [alg.rand.generate]ranges::generate_random's helper lambda should specify the return type
 Yes2
 
 
            
 
            4119(i)Tentatively Ready25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed4064(i)Voting27.5.1 [cstring.syn]Clarify that std::launder is not needed when using the result of std::memcpy
 Yes3
 
 
            
 
            4084(i)Tentatively Ready4084(i)Voting
 28.3.4.3.3.3 [facet.num.put.virtuals]
 std::fixed ignores std::uppercase
 Yes
 
 
            
 
            4142(i)Tentatively Ready4142(i)Voting
 28.5.6.6 [format.parse.ctx]
 format_parse_context::check_dynamic_spec should require at least one type
 Yes
 
 
            
 
            4153(i)Tentatively Ready4014(i)Voting29.5.4.4 [rand.eng.sub]LWG 3809 changes behavior of some existing std::subtract_with_carry_engine codeYes2
            4134(i)Voting29.5.4.5 [rand.eng.philox]Issue with Philox algorithm specificationYes1
            4153(i)Voting
 29.5.4.5 [rand.eng.philox]
 Fix extra "-1" for philox_engine::max()
 Yes
 
 
            
 
            4124(i)Tentatively Ready4124(i)Voting
 30.12 [time.format]
 Cannot format zoned_time with resolution coarser than seconds
 Yes
 
 
            
 
            4088(i)Tentatively Ready4088(i)Voting
 31.7.6.3.5 [ostream.formatted.print]
 println ignores the locale imbued in std::ostream
 Yes
 
 
            
 
            4169(i)Tentatively Ready4044(i)Voting31.7.10 [print.fun]Confusing requirements for std::print on POSIX platformsYes3
            4169(i)Voting
 32.5.8.2 [atomics.types.operations]
 std::atomic<T>'s default constructor should be constrained
 Yes
 
 
 
            4154(i)Voting32.10.10.2 [futures.task.members]The Mandates for std::packaged_task's constructor from a callable entity should consider decayingYes3
            
 
            
 
            Tentatively NAD (9 issues)
            
 
@@ -490,7 +478,7 @@ 
            Tentatively NAD (9 issues)
            
 
            
 
            
 
            
-
            New (439 issues)
            
+
            New (438 issues)
            
 
@@ -974,15 +962,6 @@ 
            New (439 issues)
            
-
-
-
-
-
-
-
-
-
@@ -4507,7 +4486,7 @@ 
            New (439 issues)
            
 
            
   Issue
 
 
            
 
            4130(i)New17.6.5 [ptr.launder]Preconditions for std::launder might be overly strictYes3
            
 3624(i)
 New
 
 
            
 
            
-
            Open (78 issues)
            
+
            Open (81 issues)
            
 
@@ -4564,6 +4543,15 @@ 
            Open (78 issues)
            
+
+
+
+
+
+
+
+
+
@@ -4591,6 +4579,15 @@ 
            Open (78 issues)
            
+
+
+
+
+
+
+
+
+
@@ -4690,6 +4687,15 @@ 
            Open (78 issues)
            
+
+
+
+
+
+
+
+
+
@@ -5221,7 +5227,7 @@ 
            Open (78 issues)
            
 
            
   Issue
 
 
            
 
            4130(i)Open17.6.5 [ptr.launder]Preconditions for std::launder might be overly strictYes3
            
 2398(i)
 Open
 17.7.3 [type.info]
 
 
            
 
            3454(i)Open20.2.3 [pointer.traits]pointer_traits::pointer_to should be constexprYes
            
 2262(i)
 Open
 20.3.1.3 [unique.ptr.single]
 
 
            
 
            2991(i)Open22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Yes
            
 2833(i)
 Open
 22.6.3.2 [variant.ctor]
 
 
            
 
            
-
            LEWG (28 issues)
            
+
            LEWG (26 issues)
            
 
@@ -5242,15 +5248,6 @@ 
            LEWG (28 issues)
            
-
-
-
-
-
-
-
-
-
@@ -5287,15 +5284,6 @@ 
            LEWG (28 issues)
            
-
-
-
-
-
-
-
-
-
diff --git a/lwg-tentative.html b/lwg-tentative.html
index 10f295daa4..868aee0581 100644
--- a/lwg-tentative.html
+++ b/lwg-tentative.html
@@ -54,432 +54,8 @@
 
-
            Revised 2024-11-18 at 13:27:23 UTC
+
            Revised 2024-11-19 at 16:10:33 UTC
 
            Tentative Issues
            
-
            
-
            3216(i). Rebinding the allocator before calling construct/destroy in allocate_shared
            
-
            Section: 20.3.2.2.7 [util.smartptr.shared.create] Status: Tentatively Ready
- Submitter: Billy O'Neal III Opened: 2019-06-11 Last modified: 2024-10-02
            
-
            Priority: 3
-
            
-
            View other active issues in [util.smartptr.shared.create].
            
-
            View all other issues in [util.smartptr.shared.create].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-The new allocate_shared wording says we need to rebind the allocator back to T's
-type before we can call construct or destroy, but this is suboptimal (might make
-extra unnecessary allocator copies), and is inconsistent with the containers' behavior, which call
-allocator construct on whatever T they want. (For example,
-std::list<T, alloc<T>> rebinds to alloc<_ListNode<T>>,
-but calls construct(T*) without rebinding back)
-
            
-It seems like we should be consistent with the containers and not require a rebind here. PR would
-look something like this, relative to N4810; I'm still not super happy with this wording because
-it looks like it might be saying a copy of the allocator must be made we would like to avoid…
-
            
-
-
            [2019-07 Issue Prioritization]
            
-
-
            Priority to 3 after discussion on the reflector.
            
-
            Previous resolution [SUPERSEDED]:
            
-
            
-
-
            This wording is relative to N4810.
            
-
-
              
-
            1. Modify 20.3.2.2.7 [util.smartptr.shared.create] as indicated:
              
-
-
              
-
              
-[Drafting note: The edits to change pv to pu were suggested by Jonathan
-Wakely (thanks!). This wording also has the remove_cv_t fixes specified by LWG 3210(i)
-— if that change is rejected some of those have to be stripped here.]
-
              
-
              
-
-
              
-
              -template<class T, ...>
-  shared_ptr<T> make_shared(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared(const A& a, args);
-template<class T, ...>
-  shared_ptr<T> make_shared_default_init(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared_default_init(const A& a, args);
-
              
-
              
-
              
--2- Requires: […]
-
              
-[…]
-
              
--7- Remarks:
-
              
-
                
-
              1. (7.1) — […]
                2. 
-
              2. […]
                3. 
-
              3. (7.5) — When a (sub)object of a non-array type U is specified to have an initial
-value of v, or U(l...), where l... is a list of constructor arguments,
-allocate_shared shall initialize this (sub)object via the expression
-
                
-
                  
-
                1. (7.5.1) — allocator_traits<A2>::construct(a2, pvu, v) or
                  2. 
-
                2. (7.5.2) — allocator_traits<A2>::construct(a2, pvu, l...)
                  3. 
-
                
-
                
-respectively, where pvu is a pointer of type
-remove_cv_t<U>* pointsing to storage suitable to hold
-an object of type remove_cv_t<U> and a2 of type
-A2 is a potentially rebound copy of the allocator a
-passed to allocate_shared such that its value_type is remove_cv_t<U>.
-
                
-
                4. 
-
              4. (7.6) — […]
                5. 
-
              5. (7.7) — When a (sub)object of non-array type U is specified to have a default
-initial value, allocate_shared shall initializes this (sub)object via
-the expression allocator_traits<A2>::construct(a2, pvu), where
-pvu is a pointer of type remove_cv_t<U>*
-pointsing to storage suitable to hold an object of type
-remove_cv_t<U> and a2 of type A2 is a
-potentially rebound copy of the allocator a passed to allocate_shared
-such that its value_type is remove_cv_t<U>.
                6. 
-
              6. […]
                7. 
-
              7. (7.12) — When a (sub)object of non-array type U that was initialized by
-allocate_shared is to be destroyed, it is destroyed via the expression
-allocator_traits<A2>::destroy(a2, pvu) where
-pvu is a pointer of type remove_cv_t<U>*
-pointsing to that object of type remove_cv_t<U> and
-a2 of type A2 is a potentially rebound copy of the
-allocator a passed to allocate_shared such that its value_type is
-remove_cv_t<U>.
                8. 
-
              
-
              
-
              
-
              2. 
-
            
-
            
-
-
            [2024-08-23; Jonathan provides updated wording]
            
-
-
            
-make_shared_default_init and allocate_shared_default_init were renamed
-by P1973R1 so this needs a rebase.
-The edit to (7.11) is just for consistency, so that pv is always void*
-and pu is remove_cv_t<U>*.
-Accepting this proposed resolution would also resolve issue 3210(i).
-
            
-
-
-
            [2024-10-02; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after six votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            This wording is relative to N4988.
            
-
-
              
-
            1. Modify 20.3.2.2.7 [util.smartptr.shared.create] as indicated:
              
-
-
              
-
              -template<class T, ...>
-  shared_ptr<T> make_shared(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared(const A& a, args);
-template<class T, ...>
-  shared_ptr<T> make_shared_for_overwrite(args);
-template<class T, class A, ...>
-  shared_ptr<T> allocate_shared_for_overwrite(const A& a, args);
-
              
-
              
-
              
--2- Preconditions: […]
-
              
-[…]
-
              
--7- Remarks:
-
              
-
                
-
              1. (7.1) — […]
                2. 
-
              2. […]
                3. 
-
              3. (7.5) — When a (sub)object of a non-array type U is specified to have an initial
-value of v, or U(l...), where l... is a list of constructor arguments,
-allocate_shared shall initialize this (sub)object via the expression
-
                
-
                  
-
                1. (7.5.1) — allocator_traits<A2>::construct(a2, pvu, v) or
                  2. 
-
                2. (7.5.2) — allocator_traits<A2>::construct(a2, pvu, l...)
                  3. 
-
                
-
                
-respectively, where pvu is a pointer of type
-remove_cv_t<U>* pointsing to storage suitable to hold
-an object of type remove_cv_t<U> and a2 of type
-A2 is a potentially rebound copy of the allocator a
-passed to allocate_shared such that its value_type is remove_cv_t<U>.
-
                
-
                4. 
-
              4. (7.6) — […]
                5. 
-
              5. (7.7) — When a (sub)object of non-array type U is specified to have a default
-initial value, allocate_shared shall initializes this (sub)object via
-the expression allocator_traits<A2>::construct(a2, pvu), where
-pvu is a pointer of type remove_cv_t<U>*
-pointsing to storage suitable to hold an object of type
-remove_cv_t<U> and a2 of type A2 is a
-potentially rebound copy of the allocator a passed to allocate_shared
-such that its value_type is remove_cv_t<U>.
                6. 
-
              6. […]
                7. 
-
              7. 
-
                [Drafting note:
-Issue 4024(i) will add make_shared_for_overwrite
-and allocate_shared_for_overwrite to (7.11) but that doesn't conflict with this next edit.]
-
                
-
                (7.11) — When a (sub)object of non-array type U that was initialized by
-make_shared is to be destroyed, it is destroyed via the expression
-pvu->~U() where pvu
-points to that object of type U.
                8. 
-
              8. (7.12) — When a (sub)object of non-array type U that was initialized by
-allocate_shared is to be destroyed, it is destroyed via the expression
-allocator_traits<A2>::destroy(a2, pvu) where
-pvu is a pointer of type remove_cv_t<U>*
-pointsing to that object of type remove_cv_t<U> and
-a2 of type A2 is a potentially rebound copy of the
-allocator a passed to allocate_shared such that its value_type is
-remove_cv_t<U>.
                9. 
-
              
-
              
-
              
-
              2. 
-
            
-
-
-
-
-
            
-
            3886(i). Monad mo' problems
            
-
            Section: 22.5.3.1 [optional.optional.general], 22.8.6.1 [expected.object.general] Status: Tentatively Ready
- Submitter: Casey Carter Opened: 2023-02-13 Last modified: 2024-09-19
            
-
            Priority: 3
-
            
-
            View other active issues in [optional.optional.general].
            
-
            View all other issues in [optional.optional.general].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-While implementing P2505R5 "Monadic Functions for std::expected" we found it odd that
-the template type parameter for the assignment operator that accepts an argument by forwarding reference is
-defaulted, but the template type parameter for value_or is not. For consistency, it would seem that
-meow.value_or(woof) should accept the same arguments woof as does
-meow = woof, even when those arguments are braced-initializers.
-
            
-That said, it would be peculiar to default the template type parameter of value_or to T
-instead of remove_cv_t<T>. For expected<const vector<int>, int> meow{unexpect, 42};,
-for example, meow.value_or({1, 2, 3}) would create a temporary const vector<int>
-for the argument and return a copy of that argument. Were the default template argument instead
-remove_cv_t<T>, meow.value_or({1, 2, 3}) could move construct its return value
-from the argument vector<int>. For the same reason, the constructor that accepts a forwarding
-reference with a default template argument of T should default that argument to remove_cv_t<T>.
-
            
-For consistency, it would be best to default the template argument of the perfect-forwarding construct,
-perfect-forwarding assignment operator, and value_or to remove_cv_t<T>. Since all of
-the arguments presented apply equally to optional, we believe optional should be changed
-consistently with expected. MSVCSTL has prototyped these changes successfully.
-
            
-
-
            [2023-03-22; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll.
-
            
-
            [2024-09-18; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after six votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4928.
-
            
-
-
              
-
            1. Modify 22.5.3.1 [optional.optional.general] as indicated:
              
-
-
              
-
              -namespace std {
-  template<class T>
-  class optional {
-  public:
-    […]
-    template<class U = remove_cv_t<T>>
-      constexpr explicit(see below) optional(U&&);
-    […]
-    template<class U = remove_cv_t<T>> constexpr optional& operator=(U&&);
-    […]
-    template<class U = remove_cv_t<T>> constexpr T value_or(U&&) const &;
-    template<class U = remove_cv_t<T>> constexpr T value_or(U&&) &&;
-    […]
-  };
-  […]
-}
-
              
-
              
-
-
              2. 
-
-
            2. Modify 22.5.3.2 [optional.ctor] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>> constexpr explicit(see below) optional(U&& v);
-
              
-
              
-
              
--23- Constraints: […]
-
              
-
              
-
              
-
-
              3. 
-
-
            3. Modify 22.5.3.4 [optional.assign] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>> constexpr optional& operator=(U&& v);
-
              
-
              
-
              
--12- Constraints: […]
-
              
-
              
-
              
-
-
              4. 
-
-
            4. Modify 22.5.3.7 [optional.observe] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>> constexpr T value_or(U&& v) const &;
-
              
-
              
-
              
--15- Mandates: […]
-
              
-[…]
-
              
-
              
-
              -template<class U = remove_cv_t<T>> constexpr T value_or(U&& v) &&;
-
              
-
              
-
              
--17- Mandates: […]
-
              
-
              
-
              
-
-
              5. 
-
-
            5. Modify 22.8.6.1 [expected.object.general] as indicated:
              
-
-
              
-
              -namespace std {
-  template<class T, class E>
-  class expected {
-  public:
-    […]
-    template<class U = remove_cv_t<T>>
-      constexpr explicit(see below) expected(U&& v);
-    […]
-    template<class U = remove_cv_t<T>> constexpr expected& operator=(U&&);
-    […]
-    template<class U = remove_cv_t<T>> constexpr T value_or(U&&) const &;
-    template<class U = remove_cv_t<T>> constexpr T value_or(U&&) &&;
-    […]
-  };
-  […]
-}
-
              
-
              
-
-
              6. 
-
-
            6. Modify 22.8.6.2 [expected.object.cons] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>>
-  constexpr explicit(!is_convertible_v<U, T>) expected(U&& v);
-
              
-
              
-
              
--23- Constraints: […]
-
              
-
              
-
              
-
-
              7. 
-
-
            7. Modify 22.8.6.4 [expected.object.assign] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>>
-  constexpr expected& operator=(U&& v);
-
              
-
              
-
              
--9- Constraints: […]
-
              
-
              
-
              
-
-
              8. 
-
-
            8. Modify 22.8.6.6 [expected.object.obs] as indicated:
              
-
-
              
-
              -template<class U = remove_cv_t<T>> constexpr T value_or(U&& v) const &;
-
              
-
              
-
              
--16- Mandates: […]
-
              
-[…]
-
              
-
              
-
              -template<class U = remove_cv_t<T>> constexpr T value_or(U&& v) &&;
-
              
-
              
-
              
--18- Mandates: […]
-
              
-
              
-
              
-
-
              9. 
-
-
            
-
-
-
-
-
 
            3908(i). enumerate_view::iterator constructor is explicit
            Section: 25.7.24.3 [range.enumerate.iterator] Status: Tentatively NAD
@@ -1290,224 +866,31 @@ 
            40064084(i). std::fixed ignores std::uppercase
            
-
            Section: 28.3.4.3.3.3 [facet.num.put.virtuals] Status: Tentatively Ready
- Submitter: Jonathan Wakely Opened: 2024-04-30 Last modified: 2024-09-19
            
-
            Priority: 3
-
            
-
            View other active issues in [facet.num.put.virtuals].
            
-
            View all other issues in [facet.num.put.virtuals].
            
-
            View all issues with Tentatively Ready status.
            
-
            Discussion:
            
-
            
-In Table 114 – Floating-point conversions [tab:facet.num.put.fp]
-we specify that a floating-point value should be printed as if by %f
-when (flags & floatfield) == fixed.
-This ignores whether uppercase is also set in flags,
-meaning there is no way to use the conversion specifier %F
-that was added to printf in C99.
+
            4095(i). ranges::fold_meow should explicitly spell out the return type
            
+
            Section: 26.4 [algorithm.syn], 26.6.18 [alg.fold] Status: Tentatively NAD
+ Submitter: Hewill Kang Opened: 2024-05-03 Last modified: 2024-06-24
            
+
            Priority: Not Prioritized
 
            
+
            View all other issues in [algorithm.syn].
            
+
            View all issues with Tentatively NAD status.
            
+
            Discussion:
            
-That's fine for finite values, because 1.23 in fixed format has
-no exponent character and no hex digits that would need to use uppercase.
-But %f and %F are not equivalent for non-finite values,
-because %F prints "NAN" and "INF" (or "INFINITY").
-It seems there is no way to print "NAN" or "INF" using std::num_put.
-
            
-
            
-Libstdc++ and MSVC print "inf" for the following code,
-but libc++ prints "INF" which I think is non-conforming:
-
            
-
                std::cout << std::uppercase << std::fixed << std::numeric_limits<double>::infinity();
-
            
-
            
-The libc++ behaviour seems more useful and less surprising.
-
            
-
-
            [2024-05-08; Reflector poll]
            
-
-
            
-Set priority to 3 after reflector poll. Send to LEWG.
-
            
-
            [2024-09-17; LEWG mailing list vote]
            
-
-
            
-Set status to Open after LEWG approved the proposed change.
-
            
-
            [2024-09-19; Reflector poll]
            
-
-
            
-Set status to Tentatively Ready after eight votes in favour during reflector poll.
-
            
-
-
-
-
            Proposed resolution:
            
-
            
-This wording is relative to N4981.
-
            
-
              
-
            1. Modify 28.3.4.3.3.3 [facet.num.put.virtuals] as indicated:
              
-
-
              
-
            
 
            
   Issue
 
 
            
 
            3454(i)LEWG20.2.3 [pointer.traits]pointer_traits::pointer_to should be constexprYes
            
 2922(i)
 LEWG
 21.3.3 [meta.type.synop]
 348
 
            
 
            2991(i)LEWG22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Yes
            
 2307(i)
 LEWG
 23 [containers]
 
 
 
 
 
            
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
            
-Table 114 – Floating-point conversions [tab:facet.num.put.fp]
-
            Statestdio equivalent
            
-floatfield == ios_base::fixed && !uppercase
-%f
            floatfield == ios_base::fixed%F
            floatfield == ios_base::scientific && !uppercase%e
            floatfield == ios_base::scientific%E
            
-
-floatfield == (ios_base::fixed | ios_base::scientific)` && !uppercase
-
-%a
            floatfield == (ios_base::fixed | ios_base::scientific)%A
            !uppercase%g
            otherwise%G
            
-
    -

    • - - - - - - - -
    -

    4088(i). println ignores the locale imbued in std::ostream

    -

    Section: 31.7.6.3.5 [ostream.formatted.print] Status: Tentatively Ready - Submitter: Jens Maurer Opened: 2024-04-30 Last modified: 2024-10-03

    -

    Priority: Not Prioritized -

    -

    View other active issues in [ostream.formatted.print].

    -

    View all other issues in [ostream.formatted.print].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -31.7.6.3.5 [ostream.formatted.print] specifies that std::print uses the locale -imbued in the std::ostream& argument for formatting, by using this equivalence: -

    -
    -
    -vformat(os.getloc(), fmt, args);
-
    -
    -

    -(in the vformat_(non)unicode delegation). -

    -However, std::println ignores the std::ostream's locale -for its locale-dependent formatting: -

    -
    -
    -print(os, "{}\n", format(fmt, std::forward<Args>(args)...));
-
    -
    -

    -This is inconsistent. -

    - -

    [2024-10-03; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4981. -

    - -
      - -

    1. Modify 31.7.6.3.5 [ostream.formatted.print] as indicated:

      - -
      -
      -template<class... Args>
-  void println(ostream& os, format_string<Args...> fmt, Args&&... args);
-
      -
      -

      --2- Effects: Equivalent to: -

      -
      -
      -print(os, "{}\n", format(os.getloc(), fmt, std::forward<Args>(args)...));
-
      -
      -
      -
      - -
      2. -
    - - - - - - -
    -

    4095(i). ranges::fold_meow should explicitly spell out the return type

    -

    Section: 26.4 [algorithm.syn], 26.6.18 [alg.fold] Status: Tentatively NAD - Submitter: Hewill Kang Opened: 2024-05-03 Last modified: 2024-06-24

    -

    Priority: Not Prioritized -

    -

    View all other issues in [algorithm.syn].

    -

    View all issues with Tentatively NAD status.

    -

    Discussion:

    -

    -Unlike other algorithms, the return types of ranges::fold_meow are specified in terms of -auto and see below, and its implementation details depend on the return types of -other overloads through decltype(fold_meow(...)). -

    -This makes determining the return type of a certain overload (such as fold_right_last) -extremely difficult even for experts, requiring several trips back and forth to different overloads -to finally understand what the actual return type is. The situation is even worse for newbies because -such a form of specifying the return type makes it impossible for the IDE to deduce the real return type, -which is extremely user-unfriendly. -

    -I think that explicitly specifying the return type for these overloads not only greatly improves -readability but also offloads the compiler from deducing the return type, which can definitely be -considered an improvement. -

    -The proposed resolution does not touch the Effects clause and only changes the function signature -to seek minimal changes. +Unlike other algorithms, the return types of ranges::fold_meow are specified in terms of +auto and see below, and its implementation details depend on the return types of +other overloads through decltype(fold_meow(...)). +

    +This makes determining the return type of a certain overload (such as fold_right_last) +extremely difficult even for experts, requiring several trips back and forth to different overloads +to finally understand what the actual return type is. The situation is even worse for newbies because +such a form of specifying the return type makes it impossible for the IDE to deduce the real return type, +which is extremely user-unfriendly. +

    +I think that explicitly specifying the return type for these overloads not only greatly improves +readability but also offloads the compiler from deducing the return type, which can definitely be +considered an improvement. +

    +The proposed resolution does not touch the Effects clause and only changes the function signature +to seek minimal changes.

    [2024-06-24; Reflector poll: NAD]

    @@ -1791,1355 +1174,5 @@

    40954113(i). Disallow has_unique_object_representations<Incomplete[]>

    -

    Section: 21.3.5.4 [meta.unary.prop] Status: Tentatively Ready - Submitter: Jonathan Wakely Opened: 2024-06-25 Last modified: 2024-08-02

    -

    Priority: Not Prioritized -

    -

    View other active issues in [meta.unary.prop].

    -

    View all other issues in [meta.unary.prop].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -The type completeness requirements for has_unique_object_representations say: -

    -T shall be a complete type, cv void, or an array of unknown bound. -
    -

    -

    -This implies that the trait works for all arrays of unknown bound, -whether the element type is complete or not. That seems to be incorrect, -because has_unique_object_representations_v<Incomplete[]> -is required to have the same result as -has_unique_object_representations_v<Incomplete> -which is ill-formed if Incomplete is an incomplete class type. -

    - -

    -I think we need the element type to be complete to be able to give an answer. -Alternatively, if the intended result for an array of unknown bound is false -(maybe because there can be no objects of type T[], or because we can't -know that two objects declared as extern T a[]; and extern T b[]; have -the same number of elements?) then the condition for the trait needs to be -special-cased as false for arrays of unknown bound. -The current spec is inconsistent, we can't allow arrays of unknown bound -and apply the current rules to determine the trait's result. -

    - -

    [2024-08-02; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4981. -

    - -
      -

    1. Modify 21.3.5.4 [meta.unary.prop] as indicated:

      - -
      - - - - - - - - - - - - -
      TemplateConditionPreconditions
      ………
      -
      template<class T>
-struct has_unique_object_representations;
      -      		 -For an array type T, the same result as -has_unique_object_representations_v<remove_all_extents_t<T>>, -otherwise see below. - -remove_all_extents_t<T> -T -shall be a complete type, -or cv void, or an array of unknown bound. -
      -
      -
      -

      -[Drafting note: We could use remove_extent_t<T> -to remove just the first array dimension, because only that first one can -have an unknown bound. -The proposed resolution uses remove_all_extents_t<T> -for consistency with the Condition column.] -

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

    4119(i). generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed

    -

    Section: 25.8.5 [coro.generator.promise] Status: Tentatively Ready - Submitter: Hewill Kang Opened: 2024-07-11 Last modified: 2024-08-02

    -

    Priority: Not Prioritized -

    -

    View other active issues in [coro.generator.promise].

    -

    View all other issues in [coro.generator.promise].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -The nested coroutine is specified to return generator<yielded, ranges::range_value_t<R>, Alloc> -which can be problematic as the value type of R is really irrelevant to yielded, -unnecessarily violating the generator's Mandates (demo): -

    -
    -#include <generator>
-#include <vector>
-
-std::generator<std::span<int>> f() {
-  std::vector<int> v;
-  co_yield v; // ok
-}
-
-std::generator<std::span<int>> g() {
-  std::vector<std::vector<int>> v;
-  co_yield std::ranges::elements_of(v); // hard error
-}
-
    -

    -This proposed resolution is to change the second template parameter from range_value_t<R> -to void since that type doesn't matter to us. -

    - -

    [2024-08-02; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4986. -

    -
      -

    1. Modify 25.8.5 [coro.generator.promise] as indicated:

      - -
      -
      -template<ranges::input_range R, class Alloc>
-  requires convertible_to<ranges::range_reference_t<R>, yielded>
-  auto yield_value(ranges::elements_of<R, Alloc> r);
-
      -
      -

      --13- Effects: Equivalent to: -

      -
      -auto nested = [](allocator_arg_t, Alloc, ranges::iterator_t<R> i, ranges::sentinel_t<R> s)
-  -> generator<yielded, ranges::range_value_t<R>void, Alloc> {
-    for (; i != s; ++i) {
-      co_yield static_cast<yielded>(*i);
-    }
-  };
-return yield_value(ranges::elements_of(nested(
-  allocator_arg, r.allocator, ranges::begin(r.range), ranges::end(r.range))));
-
      -[…] -
      -
      -
      2. -
    - - - - - -
    -

    4124(i). Cannot format zoned_time with resolution coarser than seconds

    -

    Section: 30.12 [time.format] Status: Tentatively Ready - Submitter: Jonathan Wakely Opened: 2024-07-26 Last modified: 2024-08-02

    -

    Priority: Not Prioritized -

    -

    View other active issues in [time.format].

    -

    View all other issues in [time.format].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -The -std::formatter<std::chrono::zoned_time<Duration, TimeZonePtr>> -specialization calls tp.get_local_time() for the object it passes to its -base class' format function. But get_local_time() does not return a -local_time<Duration>, it returns -local_time<common_type_t<Duration, seconds>>. -The base class' format function is only defined for -local_time<Duration>. -That means this is ill-formed, even though the static assert passes: -

    using namespace std::chrono;
-  static_assert( std::formattable<zoned_time<minutes>, char> );
-  zoned_time<minutes> zt;
-  (void) std::format("{}", zt); // error: cannot convert local_time<seconds> to local_time<minutes>
-
    -

    - -

    -Additionally, it's not specified what output you should get for: -

    std::format("{}", local_time_format(zt.get_local_time()));
-
    -30.12 [time.format] p7 says it's formatted as if by streaming to an -ostringstream, -but there is no operator<< for local-time-format-t. -Presumably it should give the same result as operator<< for -a zoned_time, i.e. "{:L%F %T %Z}" with padding adjustments etc. -

    -

    -The proposed resolution below has been implemented in libstdc++. -

    - -

    [2024-08-02; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4986. -

    - -
      -

    1. Modify 30.12 [time.format] as indicated:

      - -
      -
      -template<classDuration, class charT>
-  struct formatter<chrono::local-time-format-t<Duration>, charT>;
-
      -

      -17- -Let f be a locale-time-format-t<Duration> object -passed to formatter::format. -

      -

      -18- Remarks: -If the chrono-specs is omitted, the result is equivalent to -using %F %T %Z as the chrono-specs. -If %Z is used, -it is replaced with *f.abbrev if f.abbrev is not a null pointer value. -If %Z is used and f.abbrev is a null pointer value, -an exception of type format_error is thrown. -If %z (or a modified variant of %z) is used, -it is formatted with the value of *f.offset_sec if f.offset_sec is -not a null pointer value. -If %z (or a modified variant of %z) is used and f.offset_sec -is a null pointer value, then an exception of type format_error is thrown. -

      -
      -  template<class Duration, class TimeZonePtr, class charT>
-  struct formatter<chrono::zoned_time<Duration, TimeZonePtr>, charT>
-      : formatter<chrono::local-time-format-t<common_type_t<Duration, seconds>>, charT> {
-    template<class FormatContext>
-      typename FormatContext::iterator
-      format(const chrono::zoned_time<Duration, TimeZonePtr>& tp, FormatContext& ctx) const;
-  };
-
      -
      -template<class FormatContext>
-  typename FormatContext::iterator
-    format(const chrono::zoned_time<Duration, TimeZonePtr>& tp, FormatContext& ctx) const;
-
      -

      -19- Effects: Equivalent to: -

      -
      -sys_info info = tp.get_info();
-return formatter<chrono::local-time-format-t<common_type_t<Duration, seconds>>, charT>::
-         format({tp.get_local_time(), &info.abbrev, &info.offset}, ctx);
-
      -
      -

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

    4126(i). Some feature-test macros for fully freestanding features are not yet marked freestanding

    -

    Section: 17.3.2 [version.syn] Status: Tentatively Ready - Submitter: Jiang An Opened: 2024-07-24 Last modified: 2024-08-02

    -

    Priority: 2 -

    -

    View other active issues in [version.syn].

    -

    View all other issues in [version.syn].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -Currently (N4986), it's a bit weird in 17.3.2 [version.syn] that some feature-test -macros are not marked freestanding, despite the indicated features being fully freestanding. The -freestanding status seems sometimes implicitly covered by "also in" headers that are mostly or all -freestanding, but sometimes not. -

    -I think it's more consistent to ensure feature-test macros for fully freestanding features are also freestanding. -

    - -

    [2024-08-02; Reflector poll]

    - -

    -Set priority to 2 and set status to Tentatively Ready after seven votes in favour during reflector poll. -

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4986. -

    - -
      -

    1. Modify 17.3.2 [version.syn] as indicated:

      - -
      -

      -[Drafting note: <charconv> is not fully freestanding, but all functions made constexpr -by P2291R3 are furtherly made freestanding by P2338R4. ] -

      -
      - -
      -
      -[…]
-#define __cpp_lib_common_reference                  202302L // freestanding, also in <type_traits>
-#define __cpp_lib_common_reference_wrapper          202302L // freestanding, also in <functional>
-[…]                                                                              
-#define __cpp_lib_constexpr_charconv                202207L // freestanding, also in <charconv>
-[…]                                                                              
-#define __cpp_lib_coroutine                         201902L // freestanding, also in <coroutine>
-[…]                                                                              
-#define __cpp_lib_is_implicit_lifetime              202302L // freestanding, also in <type_traits>
-[…]                                                                              
-#define __cpp_lib_is_virtual_base_of                202406L // freestanding, also in <type_traits>
-[…]                                                                              
-#define __cpp_lib_is_within_lifetime                202306L // freestanding, also in <type_traits>
-[…]                                                                              
-#define __cpp_lib_mdspan                            202406L // freestanding, also in <mdspan>
-[…]                                                                              
-#define __cpp_lib_ratio                             202306L // freestanding, also in <ratio>
-[…]                                                                              
-#define __cpp_lib_span_initializer_list             202311L // freestanding, also in <span>
-[…]                                                                              
-#define __cpp_lib_submdspan                         202403L // freestanding, also in <mdspan>
-[…]                                                                              
-#define __cpp_lib_to_array                          201907L // freestanding, also in <array>
-[…]
-
      -
      - -
      2. - -
    - - - - - -
    -

    4135(i). The helper lambda of std::erase for list should specify return type as - bool

    -

    Section: 23.3.7.7 [forward.list.erasure], 23.3.9.6 [list.erasure] Status: Tentatively Ready - Submitter: Hewill Kang Opened: 2024-08-07 Last modified: 2024-08-21

    -

    Priority: Not Prioritized -

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -std::erase for list is specified to return -erase_if(c, [&](auto& elem) { return elem == value; }). -However, the template parameter Predicate of erase_if only requires that the -type of decltype(pred(...)) satisfies boolean-testable, i.e., the -return type of elem == value is not necessarily bool. -

    -This means it's worth explicitly specifying the lambda's return type as bool to avoid some -pedantic cases (demo): -

    -
    -#include <list>
-
-struct Bool {
-  Bool(const Bool&) = delete;
-  operator bool() const;
-};
-
-struct Int {
-  Bool& operator==(Int) const;
-};
-
-int main() {
-  std::list<Int> l;
-  std::erase(l, Int{}); // unnecessary hard error
-}
-
    - -

    [2024-08-21; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    - -
      - -

    1. Modify 23.3.7.7 [forward.list.erasure] as indicated:

      - -
      -
      -template<class T, class Allocator, class U = T>
-  typename forward_list<T, Allocator>::size_type
-    erase(forward_list<T, Allocator>& c, const U& value);
-
      -
      -

      --1- Effects: Equivalent to: - return erase_if(c, [&](const auto& elem) -> bool { return elem == value; }); -

      -
      -
      -
      2. - -

    2. Modify 23.3.9.6 [list.erasure] as indicated:

      - -
      -
      -template<class T, class Allocator, class U = T>
-  typename list<T, Allocator>::size_type
-    erase(list<T, Allocator>& c, const U& value);
-
      -
      -

      --1- Effects: Equivalent to: - return erase_if(c, [&](const auto& elem) -> bool { return elem == value; }); -

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

    4140(i). Useless default constructors for bit reference types

    -

    Section: 22.9.2.1 [template.bitset.general], 23.3.12.1 [vector.bool.pspc] Status: Tentatively Ready - Submitter: Jonathan Wakely Opened: 2024-08-21 Last modified: 2024-09-18

    -

    Priority: Not Prioritized -

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -The standard shows a private default constructor for -bitset<N>::reference -but does not define its semantics, and nothing in the spec refers to it. -It was present in C++98, then in C++11 it got noexcept added to it, -and in C++23 it was made constexpr by P2417R2. That's quite -a lot of churn for an unusuable member function with no definition. -

    -

    -In libstdc++ it's declared as private, but never defined. -In libc++ it doesn't exist at all. -In MSVC it is private and defined (and presumably used somewhere). -There's no reason for the standard to declare it. -Implementers can define it as private if they want to, or not. -The spec doesn't need to say anything for that to be true. -We can also remove the friend declaration, because implementers know how to -do that too. -

    -

    -I suspect it was added as private originally so that it didn't look like -reference should have an implicitly-defined default constructor, -which would have been the case in previous standards with no other -constructors declared. -However, C++20 added reference(const reference&) = default; -which suppresses the implicit default constructor, so declaring the -default constructor as private is now unnecessary. -

    -

    -Jiang An pointed out in an editorial pull request that -vector<bool, Alloc>::reference -has exactly the same issue. -

    - -

    [2024-09-18; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    - -
      -

    1. Modify 22.9.2.1 [template.bitset.general] as indicated:

      -
      -
      -namespace std {
-  template<size_t N> class bitset {
-  public:
-    // bit reference
-    class reference {
-      friend class bitset;
-      constexpr reference() noexcept;
-
-    public:
-      constexpr reference(const reference&) = default;
-      constexpr ~reference();
-      constexpr reference& operator=(bool x) noexcept;            // for b[i] = x;
-      constexpr reference& operator=(const reference&) noexcept;  // for b[i] = b[j];
-      constexpr bool operator~() const noexcept;                  // flips the bit
-      constexpr operator bool() const noexcept;                   // for x = b[i];
-      constexpr reference& flip() noexcept;                       // for b[i].flip();
-    };
-
      -
      -
      2. - -

    2. Modify 23.3.12.1 [vector.bool.pspc], vector<bool, Allocator> synopsis, as indicated:

      -
      -
      -namespace std {
-  template<class Allocator>
-  class vector<bool, Allocator> {
-  public:
-    // types
-    […]
-    // bit reference
-    class reference {
-      friend class vector;
-      constexpr reference() noexcept;
-
-    public:
-      constexpr reference(const reference&) = default;
-      constexpr ~reference();
-      constexpr operator bool() const noexcept;
-      constexpr reference& operator=(bool x) noexcept;
-      constexpr reference& operator=(const reference& x) noexcept;
-      constexpr const reference& operator=(bool x) const noexcept;
-      constexpr void flip() noexcept;   // flips the bit
-    };
-
      -
      -
      3. -
    - - - - - - -
    -

    4141(i). Improve prohibitions on "additional storage"

    -

    Section: 22.5.3.1 [optional.optional.general], 22.6.3.1 [variant.variant.general], 22.8.6.1 [expected.object.general], 22.8.7.1 [expected.void.general] Status: Tentatively Ready - Submitter: Jonathan Wakely Opened: 2024-08-22 Last modified: 2024-09-18

    -

    Priority: Not Prioritized -

    -

    View other active issues in [optional.optional.general].

    -

    View all other issues in [optional.optional.general].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -This issue was split out from issue 4015(i). -

    -

    -optional, variant and expected all use similar wording to require -their contained value to be a subobject, rather than dynamically allocated -and referred to by a pointer, e.g. -

    -When an instance of optional<T> contains a value, -it means that an object of type T, referred to as the -optional object’s contained value, -is allocated within the storage of the optional object. -Implementations are not permitted to use additional storage, -such as dynamic memory, to allocate its contained value. -
    -

    - -

    -During the LWG reviews of P2300 in St. Louis, concerns were -raised about the form of this wording and whether it's normatively meaningful. -Except for the special case of standard-layout class types, the standard has -very few requirements on where or how storage for subobjects is allocated. -The library should not be trying to dictate more than the language guarantees. -It would be better to refer to wording from 6.7.2 [intro.object] -such as subobject, provides storage, or nested within. -Any of these terms would provide the desired properties, without using -different (and possibly inconsistent) terminology. -

    -

    -Using an array of bytes to provide storage for the contained value would -make it tricky to meet the constexpr requirements of types like optional. -This means in practice, the most restrictive of these terms, subobject, -is probably accurate and the only plausible implementation strategy. -However, I don't see any reason to outlaw other implementation strategies that -might be possible in future (say, with a constexpr type cast, or non-standard -compiler-specific instrinics). -For this reason, the proposed resolution below uses nested within, -which provides the desired guarantee without imposing additional restrictions -on implementations. -

    - -

    [2024-09-18; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    - -
      -

    1. Modify 22.5.3.1 [optional.optional.general] as indicated:

      - -
      -[Drafting note: -This edit modifies the same paragraph as issue 4015(i), -but that other issue intentionally doesn't touch the affected sentence here -(except for removing the italics on "contained value"). -The intention is that the merge conflict can be resolved in the obvious way: -"An optional object's contained value -is nested within (6.7.2 [intro.object]) the optional object."] -
      - -
      -

      --1- -Any instance of optional<T> at any given time either -contains a value or does not contain a value. -When an instance of optional<T> contains a value, -it means that an object of type T, -referred to as the optional object's contained value, -is -allocated within the storage of -nested within (6.7.2 [intro.object]) -the optional object. - -Implementations are not permitted to use additional storage, -such as dynamic memory, to allocate its contained value. - -When an object of type optional<T> -is contextually converted to bool, -the conversion returns true if the object contains a value; -otherwise the conversion returns false. -

      -
      -
      2. - -

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

      - -
      -

      --1- -Any instance of variant at any given time either -holds a value of one of its alternative types or holds no value. -When an instance of variant holds a value of alternative type T, -it means that a value of type T, -referred to as the variant object's contained value, -is -allocated within the storage of -nested within (6.7.2 [intro.object]) -the variant object. - -Implementations are not permitted to use additional storage, -such as dynamic memory, to allocate the contained value. - -

      -
      -
      3. - -

    3. Modify 22.8.6.1 [expected.object.general] as indicated:

      - -
      -

      --1- -Any object of type expected<T, E> either contains -a value of type T or a value of type E -within its own storage -nested within (6.7.2 [intro.object]) it. - -Implementations are not permitted to use additional storage, -such as dynamic memory, -to allocate the object of type T or the object of type E. - -Member has_val indicates whether the -expected<T, E> object contains an object of type T. -

      -
      -
      4. - -

    4. Modify 22.8.7.1 [expected.void.general] as indicated:

      - -
      -

      --1- -Any object of type expected<T, E> either represents -a value of type T, or contains a value of type E -within its own storage -nested within (6.7.2 [intro.object]) it. - -Implementations are not permitted to use additional storage, -such as dynamic memory, to allocate the object of type E. - -Member has_val indicates whether the -expected<T, E> represents a value of type T. -

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

    4142(i). format_parse_context::check_dynamic_spec should require at least one type

    -

    Section: 28.5.6.6 [format.parse.ctx] Status: Tentatively Ready - Submitter: Jonathan Wakely Opened: 2024-08-28 Last modified: 2024-09-18

    -

    Priority: Not Prioritized -

    -

    View all other issues in [format.parse.ctx].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -The Mandates: conditions for format_parse_context::check_dynamic_spec -are: -

    --14- Mandates: -The types in Ts... are unique. Each type in Ts... is one of bool, -char_type, int, unsigned int, long long int, unsigned long long int, -float, double, long double, const char_type*, -basic_string_view<char_type>, or const void*. -
    -

    -

    -There seems to be no reason to allow Ts to be an empty pack, -that's not useful. There is no valid arg-id value that can be passed to it -if the list of types is empty, since arg(n) will never be one of the types -in an empty pack. So it's never a constant expression if the pack is empty. -

    - -

    [2024-09-18; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    - -
      -

    1. Modify 28.5.6.6 [format.parse.ctx] as indicated:

      - -
      template<class... Ts>
-  constexpr void check_dynamic_spec(size_t id) noexcept;
-
      -
      -

      --14- Mandates: -sizeof...(Ts) ≥ 1. -The types in Ts... are unique. Each type in Ts... is one of bool, -char_type, int, unsigned int, long long int, unsigned long long int, -float, double, long double, const char_type*, -basic_string_view<char_type>, or const void*. -

      -

      --15- Remarks: -A call to this function is a core constant expression only if: -

        -
      1. (15.1) — id < num_args_ is true and
        2. -
      2. (15.2) — the type of the corresponding format argument -(after conversion to basic_format_arg<Context>) -is one of the types in Ts....
        3. -
      -

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

    4144(i). Disallow unique_ptr<T&, D>

    -

    Section: 20.3.1.3.1 [unique.ptr.single.general] Status: Tentatively Ready - Submitter: Jonathan Wakely Opened: 2024-08-30 Last modified: 2024-11-13

    -

    Priority: Not Prioritized -

    -

    View all other issues in [unique.ptr.single.general].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -It seems that we currently allow nonsensical specializations of unique_ptr -such as unique_ptr<int&, D> -and unique_ptr<void()const, D> -(a custom deleter that defines D::pointer is needed, because otherwise -the pointer type would default to invalid types like -int&* or void(*)()const). -There seems to be no reason to support these "unique pointer to reference" -and "unique pointer to abominable function type" specializations, -or any specialization for a type that you couldn't form a raw pointer to. -

    - -

    -Prior to C++17, the major library implementations rejected such specializations -as a side effect of the constraints for the -unique_ptr(auto_ptr<U>&&) constructor -being defined in terms of is_convertible<U*, T*>. -This meant that overload resolution for any constructor of unique_ptr -would attempt to form the type T* and fail if that was invalid. -With the removal of auto_ptr in C++17, that constructor was removed -and now unique_ptr<int&, D> can be instantiated -(assuming any zombie definition of auto_ptr is not enabled by the library). -This wasn't intentional, but just an accident caused by not explicitly -forbidding such types. -

    - -

    -Discussion on the LWG reflector led to near-unanimous support for explicitly -disallowing these specializations for non-pointable types. -

    - -

    [2024-11-13; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    - -
      -

    1. Modify 20.3.1.3.1 [unique.ptr.single.general] as indicated:

      -
      -

      -?- -A program that instantiates the definition of -unique_ptr<T, D> -is ill-formed if T* is an invalid type. -
      -[Note: -This prevents the intantiation of specializations such as -unique_ptr<T&, D> -and unique_ptr<int() const, D>. -— end note] -       -

      -

      -1- -The default type for the template parameter D is default_delete. -A client-supplied template argument D shall be a function object type -(22.10 [function.objects]), lvalue reference to function, -or lvalue reference to function object type for which, -given a value d of type D and a value ptr of type -unique_ptr<T, D>::pointer, -the expression d(ptr) is valid and has the effect of disposing of the pointer -as appropriate for that deleter. -

      -

      -2- -If the deleter’s type D is not a reference type, -D shall meet the Cpp17Destructible requirements (Table 35). -

      -

      -3- -If the qualified-id remove_reference_t<D>::pointer -is valid and denotes a type (13.10.3 [temp.deduct]), -then unique_ptr<T, D>::pointer -shall be a synonym for remove_reference_t<D>::pointer. -Otherwise unique_ptr<T, D>::pointer shall be a synonym for -element_type*. -The type unique_ptr<T, D>::pointer shall meet the -Cpp17NullablePointer requirements (Table 36). -

      -

      -4- -[Example 1: - Given an allocator type X (16.4.4.6.1 [allocator.requirements.general]) -and letting A be a synonym for allocator_traits<X>, -the types A::pointer, A::const_pointer, A::void_pointer, -and A::const_void_pointer may be used as -unique_ptr<T, D>::pointer. -— end example] -

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

    4147(i). Precondition on inplace_vector::emplace

    -

    Section: 23.2.4 [sequence.reqmts] Status: Tentatively Ready - Submitter: Arthur O'Dwyer Opened: 2024-08-26 Last modified: 2024-09-18

    -

    Priority: Not Prioritized -

    -

    View other active issues in [sequence.reqmts].

    -

    View all other issues in [sequence.reqmts].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -Inserting into the middle of an inplace_vector, just like inserting into the middle of a -vector or deque, requires that we construct the new element out-of-line, shift -down the trailing elements (Cpp17MoveAssignable), and then move-construct the new element -into place (Cpp17MoveInsertable). P0843R14 failed to make this change, but -it should have. -

    - -

    [2024-09-18; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    - -
      -

    1. Modify 23.2.4 [sequence.reqmts] as indicated:

      - -
      -a.emplace(p, args)
-
      -
      -

      --19- Result: iterator. -

      --20- Preconditions: T is Cpp17EmplaceConstructible into X -from args. For vector, inplace_vector, and deque, -T is also Cpp17MoveInsertable into X and Cpp17MoveAssignable. -

      --21- Effects: Inserts an object of type T constructed with -std::forward<Args>(args)... before p. -

      -[Note 1: args can directly or indirectly refer to a value in a. -— end note] -

      --22- Returns: An iterator that points to the new element constructed from args -into a. -

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

    4148(i). unique_ptr::operator* should not allow dangling references

    -

    Section: 20.3.1.3.5 [unique.ptr.single.observers] Status: Tentatively Ready - Submitter: Jonathan Wakely Opened: 2024-09-02 Last modified: 2024-09-18

    -

    Priority: Not Prioritized -

    -

    View other active issues in [unique.ptr.single.observers].

    -

    View all other issues in [unique.ptr.single.observers].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -If unique_ptr<T,D>::element_type* and D::pointer -are not the same type, it's possible for operator*() to return a dangling -reference that has undefined behaviour. -

    -
    
-  struct deleter {
-    using pointer = long*;
-    void operator()(pointer) const {}
-  };
-  long l = 0;
-  std::unique_ptr<const int, deleter> p(&l);
-  int i = *p; // undefined
-
    -

    -We should make this case ill-formed. -

    - -

    [2024-09-18; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    -
      -

    1. Modify 20.3.1.3.5 [unique.ptr.single.observers] as indicated:

      -
      -
      -constexpr add_lvalue_reference_t<T> operator*() const noexcept(noexcept(*declval<pointer>()));
-
      -
      -

      --?- Mandates: -reference_converts_from_temporary_v<add_lvalue_reference_t<T>, -decltype(*declval<pointer>())> -is false. - -

      -

      --1- Preconditions: get() != nullptr is true. -

      -

      --2- Returns: *get(). -

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

    4153(i). Fix extra "-1" for philox_engine::max()

    -

    Section: 29.5.4.5 [rand.eng.philox] Status: Tentatively Ready - Submitter: Ruslan Arutyunyan Opened: 2024-09-18 Last modified: 2024-10-02

    -

    Priority: Not Prioritized -

    -

    View other active issues in [rand.eng.philox].

    -

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

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -There is a typo in philox_engine wording that makes "-1" two times -instead of one for max() method. -The reason for that typo is that the wording was originally inspired by -mersenne_twister_engine but after getting feedback that what is written in -the philox_engine synopsis is not C++ code, the authors introduced the -m variable (as in subtract_with_carry_engine) but forgot to remove -"-1" in the m definition. -

    -

    -Note: after the proposed resolution below is applied the m variable -could be reused in other places: basically in all places where the mod 2^w -pattern appears (like subtract_with_carry_engine does). -The authors don’t think it’s worth changing the rest of the wording to reuse -the m variable. -If somebody thinks otherwise, please provide such feedback. -

    - -

    [2024-10-02; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    - -
      -

    1. Modify 29.5.4.5 [rand.eng.philox] as indicated:

      -
      --1- -A philox_engine random number engine produces unsigned integer random numbers -in the closed interval [0, m]), -where m = 2w − 1 -and the template parameter w defines the range of the produced numbers. -
      -
      2. -
    - - - - - - -
    -

    4157(i). The resolution of LWG3465 was damaged by P2167R3

    -

    Section: 17.11.6 [cmp.alg] Status: Tentatively Ready - Submitter: Jiang An Opened: 2024-09-18 Last modified: 2024-10-02

    -

    Priority: Not Prioritized -

    -

    View other active issues in [cmp.alg].

    -

    View all other issues in [cmp.alg].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -In the resolution of LWG 3465(i), -F < E was required to be well-formed and -implicitly convertible to bool. -However, P2167R3 replaced the convertibility requirements -with just "each of decltype(E == F) and decltype(E < F) -models boolean-testable", -which rendered the type of F < E underconstrained. -

    - -

    [2024-10-02; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4988. -

    -
      -

    1. Modify 17.11.6 [cmp.alg] as indicated:

      -
      -(6.3) — -Otherwise, if the expressions -E == F, E < F, and F < E -are all well-formed and each of decltype(E == F) -and, -decltype(E < F) -, and decltype(F < E) -models boolean-testable, -
      
-  E == F ? partial_ordering::equivalent :
-  E < F  ? partial_ordering::less :
-  F < E  ? partial_ordering::greater :
-           partial_ordering::unordered
-
      -except that E and F are evaluated only once. -
      -
      2. -
    - - - - - -
    -

    4169(i). std::atomic<T>'s default constructor should be constrained

    -

    Section: 32.5.8.2 [atomics.types.operations] Status: Tentatively Ready - Submitter: Giuseppe D'Angelo Opened: 2024-10-15 Last modified: 2024-11-13

    -

    Priority: Not Prioritized -

    -

    View other active issues in [atomics.types.operations].

    -

    View all other issues in [atomics.types.operations].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -The current wording for std::atomic's default constructor in -32.5.8.2 [atomics.types.operations] specifies: -

    -
    -
    -constexpr atomic() noexcept(is_nothrow_default_constructible_v<T>);
-
    -
    -

    -Mandates: is_default_constructible_v<T> is true. -

    -
    -
    -

    -This wording has been added by P0883R2 for C++20, which changed -std::atomic's default constructor to always value-initialize. Before, -the behavior of this constructor was not well specified (this was LWG -issue 2334(i)). -

    -The usage of a Mandates element in the specification has as a -consequence that std::atomic<T> is always default constructible, even -when T is not. For instance: -

    -
    -
    -// not default constructible:
-struct NDC { NDC(int) {} };
-
-static_assert(std::is_default_constructible<std::atomic<NDC>>); // OK
-
    -
    -

    -The above check is OK as per language rules, but this is user-hostile: -actually using std::atomic<NDC>'s default constructor results in an -error, despite the detection saying otherwise. -

    -Given that std::atomic<T> already requires T to be complete anyhow -(32.5.8.1 [atomics.types.generic.general] checks for various type properties -which require completeness) it would be more appropriate to use a -constraint instead, so that std::atomic<T> is default constructible if -and only if T also is. -

    - -

    [2024-11-13; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4993. -

    - -
      -

    1. Modify 32.5.8.2 [atomics.types.operations] as indicated:

      - -
      -

      -[Drafting note: There is implementation divergence at the moment; libstdc++ already -implements the proposed resolution and has done so for a while.] -

      -
      - -
      -
      -constexpr atomic() noexcept(is_nothrow_default_constructible_v<T>);
-
      -
      -

      --1- ConstraintsMandates: is_default_constructible_v<T> is true. -

      --2- Effects: […] -

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

    4170(i). contiguous_iterator should require to_address(I{})

    -

    Section: 24.3.4.14 [iterator.concept.contiguous] Status: Tentatively Ready - Submitter: Casey Carter Opened: 2024-11-01 Last modified: 2024-11-13

    -

    Priority: Not Prioritized -

    -

    View all other issues in [iterator.concept.contiguous].

    -

    View all issues with Tentatively Ready status.

    -

    Discussion:

    -

    -The design intent of the contiguous_iterator concept is that iterators can be converted -to pointers denoting the same sequence of elements. This enables a common range [i, j) -or counted range i + [0, n) to be processed with extremely efficient low-level C -or assembly code that operates on [to_address(i), to_address(j)) (respectively -to_address(i) + [0, n)). -

    -A value-initialized iterator I{} can be used to denote the empty ranges [I{}, I{}) -and I{} + [0, 0). While the existing semantic requirements of contiguous_iterator enable us -to convert both dereferenceable and past-the-end iterators with to_address, converting -ranges involving value-initialized iterators to pointer ranges additionally needs -to_address(I{}) to be well-defined. Note that to_address is already implicitly -equality-preserving for contiguous_iterator arguments. Given this additional requirement -to_address(I{}) == to_address(I{}) and to_address(I{}) == to_address(I{)) + 0 -both hold, so the two types of empty ranges involving value-initialized iterators convert -to empty pointer ranges as desired. -

    - -

    [2024-11-13; Reflector poll]

    - -

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

    - - - -

    Proposed resolution:

    -

    -This wording is relative to N4993. -

    - -
      -

    1. Modify 24.3.4.14 [iterator.concept.contiguous] as indicated:

      - -
      -

      --1- The contiguous_iterator concept provides a guarantee that the denoted elements are stored contiguously -in memory. -

      -
      -
      -template<class I>
-  concept contiguous_iterator =
-    random_access_iterator<I> &&
-    derived_from<ITER_CONCEPT(I), contiguous_iterator_tag> &&
-    is_lvalue_reference_v<iter_reference_t<I>> &&
-    same_as<iter_value_t<I>, remove_cvref_t<iter_reference_t<I>>> &&
-    requires(const I& i) {
-      { to_address(i) } -> same_as<add_pointer_t<iter_reference_t<I>>>;
-    };
-
      -
      -

      --2- Let a and b be dereferenceable iterators and c be a non-dereferenceable iterator of type -I such that b is reachable from a and c is reachable from b, and let D be -iter_difference_t<I>. The type I models contiguous_iterator only if -

      - -
        -

      1. (2.1) — to_address(a) == addressof(*a),

        2. -

      2. (2.2) — to_address(b) == to_address(a) + D(b - a),

        3. -

      3. (2.3) — to_address(c) == to_address(a) + D(c - a),

        4. -

      4. (2.?) — to_address(I{}) is well-defined,

        5. -

      5. (2.4) — ranges::iter_move(a) has the same type, value category, and effects as -std::move(*a), and

        6. -

      6. (2.5) — if ranges::iter_swap(a, b) is well-formed, it has effects equivalent to -ranges::swap(*a, *b).

        7. -
      -
      - -
      2. -
    - - - - diff --git a/lwg-toc.html b/lwg-toc.html index 45a1600a2b..b9b92ae17b 100644 --- a/lwg-toc.html +++ b/lwg-toc.html @@ -59,7 +59,7 @@

    Table of Contents

    Reference ISO/IEC IS 14882:2024(E)

    This document is the Table of Contents for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    -

    Revised 2024-11-18 at 13:27:23 UTC +

    Revised 2024-11-19 at 16:10:33 UTC

    @@ -22782,8 +22782,8 @@

    Table of Contents

    - - + + @@ -24821,8 +24821,8 @@

    Table of Contents

    - - + + @@ -26825,8 +26825,8 @@

    Table of Contents

    - - + + @@ -26987,8 +26987,8 @@

    Table of Contents

    - - + + @@ -30907,8 +30907,8 @@

    Table of Contents

    - - + + @@ -31024,8 +31024,8 @@

    Table of Contents

    - - + + @@ -31034,8 +31034,8 @@

    Table of Contents

    - +should not be constrained (Status: Voting)">3900(i) + @@ -31197,8 +31197,8 @@

    Table of Contents

    - - + + @@ -32069,8 +32069,8 @@

    Table of Contents

    - - + + @@ -32159,8 +32159,8 @@

    Table of Contents

    - - + + @@ -32186,8 +32186,8 @@

    Table of Contents

    - - + + @@ -32341,8 +32341,8 @@

    Table of Contents

    - - + + @@ -32521,8 +32521,8 @@

    Table of Contents

    - - + + @@ -32593,8 +32593,8 @@

    Table of Contents

    - - + + @@ -32701,8 +32701,8 @@

    Table of Contents

    - - + + @@ -32710,8 +32710,8 @@

    Table of Contents

    - - + + @@ -32737,8 +32737,8 @@

    Table of Contents

    - - + + @@ -32955,8 +32955,8 @@

    Table of Contents

    - - + + @@ -32964,8 +32964,8 @@

    Table of Contents

    - - + + @@ -33020,8 +33020,8 @@

    Table of Contents

    - - + + @@ -33067,8 +33067,8 @@

    Table of Contents

    - - + + @@ -33085,8 +33085,8 @@

    Table of Contents

    - - + + @@ -33121,8 +33121,8 @@

    Table of Contents

    - - + + @@ -33157,8 +33157,8 @@

    Table of Contents

    - - + + @@ -33167,8 +33167,8 @@

    Table of Contents

    - + bool (Status: Voting)">4135(i) + @@ -33213,8 +33213,8 @@

    Table of Contents

    - - + + @@ -33222,8 +33222,8 @@

    Table of Contents

    - - + + @@ -33231,8 +33231,8 @@

    Table of Contents

    - - + + @@ -33249,8 +33249,8 @@

    Table of Contents

    - - + + @@ -33276,8 +33276,8 @@

    Table of Contents

    - - + + @@ -33285,8 +33285,8 @@

    Table of Contents

    - - + + @@ -33330,8 +33330,8 @@

    Table of Contents

    - - + + @@ -33339,8 +33339,8 @@

    Table of Contents

    - - + + @@ -33366,8 +33366,8 @@

    Table of Contents

    - - + + @@ -33429,8 +33429,8 @@

    Table of Contents

    - - + + @@ -33476,8 +33476,8 @@

    Table of Contents

    - - + + @@ -33485,8 +33485,8 @@

    Table of Contents

    - - + + diff --git a/lwg-unresolved.html b/lwg-unresolved.html index f2320c2bd5..577b19eefc 100644 --- a/lwg-unresolved.html +++ b/lwg-unresolved.html @@ -54,7 +54,7 @@ -

    Revised 2024-11-18 at 13:27:23 UTC +

    Revised 2024-11-19 at 16:10:33 UTC

    Unresolved Issues

    423(i). Effects of negative streamsize in iostreams

    @@ -19723,13 +19723,13 @@

    29902991(i). variant copy constructor missing noexcept(see below)

    -

    Section: 22.6.3.2 [variant.ctor] Status: LEWG - Submitter: Peter Dimov Opened: 2017-06-27 Last modified: 2017-07-12

    +

    Section: 22.6.3.2 [variant.ctor] Status: Open + Submitter: Peter Dimov Opened: 2017-06-27 Last modified: 2024-11-19

    Priority: Not Prioritized

    View other active issues in [variant.ctor].

    View all other issues in [variant.ctor].

    -

    View all issues with LEWG status.

    +

    View all issues with Open status.

    Discussion:

    The copy constructor of std::variant is not conditionally noexcept (I think @@ -19754,6 +19754,15 @@

    2991P0088R1 the copy constructor was conditionally noexcept +in the synopsis, but not the detailed description. This was pointed out +during LWG review in Jacksonville. +The approved paper, P008R3, doesn't have it in either place. +

    +

    Proposed resolution:

    @@ -19804,7 +19813,7 @@

    29913003(i). <future> still has type-erased allocators in promise

    Section: 32.10.6 [futures.promise] Status: LEWG - Submitter: Billy O'Neal III Opened: 2017-07-16 Last modified: 2024-10-02

    + Submitter: Billy O'Neal III Opened: 2017-07-16 Last modified: 2024-11-19

    Priority: 2

    View other active issues in [futures.promise].

    @@ -19926,6 +19935,9 @@

    3003Proposed resolution:

    @@ -19996,7 +20008,7 @@

    3003 [Drafting note: -Issue 4154(i) alters these Mandates: and Effects: +Issue 4154(i) alters these Mandates: and Effects: but the two edits should combine cleanly.]

    -4- Preconditions: @@ -26668,7 +26680,7 @@

    32103216(i).]

    +

    [2024-10-02; will be resolved by issue 3216(i).]

    @@ -31177,12 +31189,12 @@

    34513454(i). pointer_traits::pointer_to should be constexpr

    -

    Section: 20.2.3 [pointer.traits] Status: LEWG - Submitter: Alisdair Meredith Opened: 2020-06-21 Last modified: 2022-07-21

    +

    Section: 20.2.3 [pointer.traits] Status: Open + Submitter: Alisdair Meredith Opened: 2020-06-21 Last modified: 2024-11-19

    Priority: Not Prioritized

    View all other issues in [pointer.traits].

    -

    View all issues with LEWG status.

    +

    View all issues with Open status.

    Discussion:

    Trying to implement a constexpr std::list (inspired by Tim Song's @@ -31214,6 +31226,12 @@

    3454Proposed resolution:

    @@ -32032,7 +32050,7 @@

    34863436(i). +There may be some interaction with LWG 3436(i).

    @@ -52318,7 +52336,7 @@

    4015[optional.optional.general] p1 and p2. On the reflector Daniel requested to keep the "additional storage" prohibition, -so that will be addressed by issue 4141(i) instead. +so that will be addressed by issue 4141(i) instead.

    [2024-10-02; Jonathan tweaks proposed resolution]

    @@ -60950,12 +60968,12 @@

    41294130(i). Preconditions for std::launder might be overly strict

    -

    Section: 17.6.5 [ptr.launder] Status: New - Submitter: Jiang An Opened: 2024-07-30 Last modified: 2024-10-02

    +

    Section: 17.6.5 [ptr.launder] Status: Open + Submitter: Jiang An Opened: 2024-07-30 Last modified: 2024-11-19

    Priority: 3

    View all other issues in [ptr.launder].

    -

    View all issues with New status.

    +

    View all issues with Open status.

    Discussion:

    From issue cplusplus/draft#4553 @@ -60973,6 +60991,9 @@

    4130Proposed resolution:

    diff --git a/unresolved-index.html b/unresolved-index.html index f9eea1beed..b277d574f5 100644 --- a/unresolved-index.html +++ b/unresolved-index.html @@ -66,7 +66,7 @@

    Index by Section

    This document is the Index by Section for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    Index by Section

    (view only non-Ready open issues)

    -

    Revised 2024-11-18 at 13:27:23 UTC +

    Revised 2024-11-19 at 16:10:33 UTC

    Section 3 (2 issues)

    (view only non-Ready open issues)

    Issue
    2991(i)LEWG2991(i)Open 22.6.3.2 [variant.ctor] variant copy constructor missing noexcept(see below) Yes
    3216(i)Tentatively Ready3216(i)Voting 20.3.2.2.7 [util.smartptr.shared.create] Rebinding the allocator before calling construct/destroy in allocate_shared Yes
    3436(i)Ready3436(i)Voting 26.11.8 [specialized.construct] std::construct_at should support arrays Yes
    3454(i)LEWG3454(i)Open 20.2.3 [pointer.traits] pointer_traits::pointer_to should be constexpr Yes
    3886(i)Tentatively Ready3886(i)Voting 22.5.3.1 [optional.optional.general] Monad mo' problems Yes
    3899(i)Ready3899(i)Voting 25.8.5 [coro.generator.promise] co_yielding elements of an lvalue generator is unnecessarily inefficient Yes
    3900(i)ReadyVoting 25.8.5 [coro.generator.promise] The allocator_arg_t overloads of generator::promise_type::operator new should not be constrained
    3918(i)Ready3918(i)Voting 26.11.6 [uninitialized.move] std::uninitialized_move/_n and guaranteed copy elision Yes
    4014(i)Ready4014(i)Voting 29.5.4.4 [rand.eng.sub] LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code Yes
    4024(i)Ready4024(i)Voting 20.3.2.2.7 [util.smartptr.shared.create] Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite Yes
    4027(i)Ready4027(i)Voting 25.2 [ranges.syn] possibly-const-range should prefer returning const R& Yes
    4044(i)Ready4044(i)Voting 31.7.10 [print.fun] Confusing requirements for std::print on POSIX platforms Yes
    4064(i)Ready4064(i)Voting 27.5.1 [cstring.syn] Clarify that std::launder is not needed when using the result of std::memcpy Yes
    4072(i)Ready4072(i)Voting 22.5.8 [optional.comp.with.t] std::optional comparisons: constrain harder Yes
    4084(i)Tentatively Ready4084(i)Voting 28.3.4.3.3.3 [facet.num.put.virtuals] std::fixed ignores std::uppercase Yes
    4085(i)Ready4085(i)Voting 26.12.2 [alg.rand.generate] ranges::generate_random's helper lambda should specify the return type Yes
    4088(i)Tentatively Ready4088(i)Voting 31.7.6.3.5 [ostream.formatted.print] println ignores the locale imbued in std::ostream Yes
    4112(i)Ready4112(i)Voting 25.5.2 [range.utility.helpers] has-arrow should required operator->() to be const-qualified Yes
    4113(i)Tentatively Ready4113(i)Voting 21.3.5.4 [meta.unary.prop] Disallow has_unique_object_representations<Incomplete[]> Yes
    4119(i)Tentatively Ready4119(i)Voting 25.8.5 [coro.generator.promise] generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed Yes
    4124(i)Tentatively Ready4124(i)Voting 30.12 [time.format] Cannot format zoned_time with resolution coarser than seconds Yes
    4126(i)Tentatively Ready4126(i)Voting 17.3.2 [version.syn] Some feature-test macros for fully freestanding features are not yet marked freestanding Yes
    4130(i)New4130(i)Open 17.6.5 [ptr.launder] Preconditions for std::launder might be overly strict Yes
    4134(i)Ready4134(i)Voting 29.5.4.5 [rand.eng.philox] Issue with Philox algorithm specification Yes
    4135(i)Tentatively ReadyVoting 23.3.7.7 [forward.list.erasure] The helper lambda of std::erase for list should specify return type as bool
    4140(i)Tentatively Ready4140(i)Voting 22.9.2.1 [template.bitset.general] Useless default constructors for bit reference types Yes
    4141(i)Tentatively Ready4141(i)Voting 22.5.3.1 [optional.optional.general] Improve prohibitions on "additional storage" Yes
    4142(i)Tentatively Ready4142(i)Voting 28.5.6.6 [format.parse.ctx] format_parse_context::check_dynamic_spec should require at least one type Yes
    4144(i)Tentatively Ready4144(i)Voting 20.3.1.3.1 [unique.ptr.single.general] Disallow unique_ptr<T&, D> Yes
    4147(i)Tentatively Ready4147(i)Voting 23.2.4 [sequence.reqmts] Precondition on inplace_vector::emplace Yes
    4148(i)Tentatively Ready4148(i)Voting 20.3.1.3.5 [unique.ptr.single.observers] unique_ptr::operator* should not allow dangling references Yes
    4153(i)Tentatively Ready4153(i)Voting 29.5.4.5 [rand.eng.philox] Fix extra "-1" for philox_engine::max() Yes
    4154(i)Ready4154(i)Voting 32.10.10.2 [futures.task.members] The Mandates for std::packaged_task's constructor from a callable entity should consider decaying Yes
    4157(i)Tentatively Ready4157(i)Voting 17.11.6 [cmp.alg] The resolution of LWG3465 was damaged by P2167R3 Yes
    4164(i)Ready4164(i)Voting 23.3.7.5 [forward.list.modifiers] Missing guarantees for forward_list modifiers Yes
    4169(i)Tentatively Ready4169(i)Voting 32.5.8.2 [atomics.types.operations] std::atomic<T>'s default constructor should be constrained Yes
    4170(i)Tentatively Ready4170(i)Voting 24.3.4.14 [iterator.concept.contiguous] contiguous_iterator should require to_address(I{}) Yes
    @@ -676,8 +676,8 @@

    Section 17 (30 issues)

    - - + + @@ -987,8 +987,8 @@

    Section 20 (22 issues)

    - - + + @@ -1624,21 +1624,21 @@

    Section 22 (47 issues)

    - + - + - + - - + + - + - + diff --git a/unresolved-prioritized.html b/unresolved-prioritized.html index 7cad2b9d62..ba0a2c1bfd 100644 --- a/unresolved-prioritized.html +++ b/unresolved-prioritized.html @@ -60,7 +60,7 @@

    Table of Contents

    This document is the Table of Contents for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List, sorted by priority.

    -

    Revised 2024-11-18 at 13:27:23 UTC +

    Revised 2024-11-19 at 16:10:33 UTC

    Priority 1 (2 issues)

    4130(i)New4130(i)Open 17.6.5 [ptr.launder] Preconditions for std::launder might be overly strict Yes Duplicates
    3454(i)LEWG3454(i)Open 20.2.3 [pointer.traits] pointer_traits::pointer_to should be constexpr Yes
    2833(i)2991(i) Open 22.6.3.2 [variant.ctor]Library needs to specify what it means when it declares a function constexprvariant copy constructor missing noexcept(see below) Yes2
    2991(i)LEWG2833(i)Open 22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Library needs to specify what it means when it declares a function constexpr Yes2
    @@ -1003,8 +1003,8 @@

    Priority 3 (378 issues)

    - - + + @@ -4732,8 +4732,8 @@

    Not Prioritized (58 issues)

    - - + + @@ -4822,8 +4822,8 @@

    Not Prioritized (58 issues)

    - - + + diff --git a/unresolved-status-date.html b/unresolved-status-date.html index 4e3a81e0a2..55611cca8d 100644 --- a/unresolved-status-date.html +++ b/unresolved-status-date.html @@ -67,8 +67,8 @@

    Index by Status and Date

    This document is the Index by Status and Date for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    -

    Revised 2024-11-18 at 13:27:23 UTC -

    New (439 issues)

    +

    Revised 2024-11-19 at 16:10:33 UTC +

    New (438 issues)

    4130(i)New4130(i)Open 17.6.5 [ptr.launder] Preconditions for std::launder might be overly strict Yes
    3454(i)LEWG3454(i)Open 20.2.3 [pointer.traits] pointer_traits::pointer_to should be constexpr Yes 348
    2991(i)LEWG2991(i)Open 22.6.3.2 [variant.ctor] variant copy constructor missing noexcept(see below) Yes
    @@ -226,15 +226,6 @@

    Index by Status and Date

    - - - - - - - - - @@ -4085,7 +4076,7 @@

    Index by Status and Date

    Issue
    4130(i)New17.6.5 [ptr.launder]Preconditions for std::launder might be overly strictYes3
    3210(i) New
    -

    Open (78 issues)

    +

    Open (81 issues)

    @@ -4097,6 +4088,33 @@

    Open (78 issues)

    + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -4799,7 +4817,7 @@

    Open (78 issues)

    Issue Duplicates
    4130(i)Open17.6.5 [ptr.launder]Preconditions for std::launder might be overly strictYes3
    3454(i)Open20.2.3 [pointer.traits]pointer_traits::pointer_to should be constexprYes
    2991(i)Open22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Yes
    2136(i) Open 16.3.2 [structure]
    -

    LEWG (28 issues)

    +

    LEWG (26 issues)

    @@ -4856,15 +4874,6 @@

    LEWG (28 issues)

    - - - - - - - - - @@ -4986,15 +4995,6 @@

    LEWG (28 issues)

    - - - - - - - - - diff --git a/unresolved-status.html b/unresolved-status.html index 4a00daedaa..790d28b5f8 100644 --- a/unresolved-status.html +++ b/unresolved-status.html @@ -62,8 +62,8 @@

    Index by Status and Section

    Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    -

    Revised 2024-11-18 at 13:27:23 UTC -

    New (439 issues)

    +

    Revised 2024-11-19 at 16:10:33 UTC +

    New (438 issues)

    Issue
    3454(i)LEWG20.2.3 [pointer.traits]pointer_traits::pointer_to should be constexprYes
    3445(i) LEWG 19.2.1 [networking.ts::socket.iostream.cons]
    2991(i)LEWG22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Yes
    2884(i) LEWG 23 [containers]
    @@ -547,15 +547,6 @@

    Index by Status and Section

    - - - - - - - - - @@ -4080,7 +4071,7 @@

    Index by Status and Section

    Issue
    4130(i)New17.6.5 [ptr.launder]Preconditions for std::launder might be overly strictYes3
    3624(i) New
    -

    Open (78 issues)

    +

    Open (81 issues)

    @@ -4137,6 +4128,15 @@

    Open (78 issues)

    + + + + + + + + + @@ -4164,6 +4164,15 @@

    Open (78 issues)

    + + + + + + + + + @@ -4263,6 +4272,15 @@

    Open (78 issues)

    + + + + + + + + + @@ -4794,7 +4812,7 @@

    Open (78 issues)

    Issue
    4130(i)Open17.6.5 [ptr.launder]Preconditions for std::launder might be overly strictYes3
    2398(i) Open 17.7.3 [type.info]
    3454(i)Open20.2.3 [pointer.traits]pointer_traits::pointer_to should be constexprYes
    2262(i) Open 20.3.1.3 [unique.ptr.single]
    2991(i)Open22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Yes
    2833(i) Open 22.6.3.2 [variant.ctor]
    -

    LEWG (28 issues)

    +

    LEWG (26 issues)

    @@ -4815,15 +4833,6 @@

    LEWG (28 issues)

    - - - - - - - - - @@ -4860,15 +4869,6 @@

    LEWG (28 issues)

    - - - - - - - - - diff --git a/unresolved-toc.html b/unresolved-toc.html index 6126b8a9ff..e29e9b3be2 100644 --- a/unresolved-toc.html +++ b/unresolved-toc.html @@ -59,7 +59,7 @@

    Table of Contents

    Reference ISO/IEC IS 14882:2024(E)

    This document is the Table of Contents for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    -

    Revised 2024-11-18 at 13:27:23 UTC +

    Revised 2024-11-19 at 16:10:33 UTC

    Issue
    3454(i)LEWG20.2.3 [pointer.traits]pointer_traits::pointer_to should be constexprYes
    2922(i) LEWG 21.3.3 [meta.type.synop] 348
    2991(i)LEWG22.6.3.2 [variant.ctor]variant copy constructor missing noexcept(see below)Yes
    2307(i) LEWG 23 [containers]
    @@ -1399,8 +1399,8 @@

    Table of Contents

    - - + + @@ -2318,8 +2318,8 @@

    Table of Contents

    - - + + @@ -4897,8 +4897,8 @@

    Table of Contents

    - - + + diff --git a/votable-index.html b/votable-index.html index c2b5d28cb1..d2746465d0 100644 --- a/votable-index.html +++ b/votable-index.html @@ -66,7 +66,7 @@

    Index by Section

    This document is the Index by Section for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    Index by Section

    (view only non-Ready open issues)

    -

    Revised 2024-11-18 at 13:27:23 UTC +

    Revised 2024-11-19 at 16:10:33 UTC

    Section 17 (2 issues)

    (view only non-Ready open issues)

    Issue
    2991(i)LEWG2991(i)Open 22.6.3.2 [variant.ctor] variant copy constructor missing noexcept(see below) Yes
    3454(i)LEWG3454(i)Open 20.2.3 [pointer.traits] pointer_traits::pointer_to should be constexpr Yes
    4130(i)New4130(i)Open 17.6.5 [ptr.launder] Preconditions for std::launder might be overly strict Yes
    @@ -80,8 +80,8 @@

    Index by Section

    - - + + @@ -89,8 +89,8 @@

    Index by Section

    - - + + @@ -111,8 +111,8 @@

    Section 20 (4 issues)

    - - + + @@ -120,8 +120,8 @@

    Section 20 (4 issues)

    - - + + @@ -129,21 +129,21 @@

    Section 20 (4 issues)

    - - + + - + - + - - + + - + - +
    Duplicates
    4126(i)Tentatively Ready4126(i)Voting 17.3.2 [version.syn] Some feature-test macros for fully freestanding features are not yet marked freestanding Yes
    4157(i)Tentatively Ready4157(i)Voting 17.11.6 [cmp.alg] The resolution of LWG3465 was damaged by P2167R3 Yes Duplicates
    4144(i)Tentatively Ready4144(i)Voting 20.3.1.3.1 [unique.ptr.single.general] Disallow unique_ptr<T&, D> Yes
    4148(i)Tentatively Ready4148(i)Voting 20.3.1.3.5 [unique.ptr.single.observers] unique_ptr::operator* should not allow dangling references Yes
    4024(i)Ready3216(i)Voting 20.3.2.2.7 [util.smartptr.shared.create]Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwriteRebinding the allocator before calling construct/destroy in allocate_shared Yes23
    3216(i)Tentatively Ready4024(i)Voting 20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_sharedUnderspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite Yes32
    @@ -160,8 +160,8 @@

    Section 21 (1 issues)

    Duplicates -4113(i) -Tentatively Ready +4113(i) +Voting 21.3.5.4 [meta.unary.prop] Disallow has_unique_object_representations<Incomplete[]> Yes @@ -182,8 +182,8 @@

    Section 22 (4 issues)

    Duplicates -3886(i) -Tentatively Ready +3886(i) +Voting 22.5.3.1 [optional.optional.general] Monad mo' problems Yes @@ -191,8 +191,8 @@

    Section 22 (4 issues)

    -4141(i) -Tentatively Ready +4141(i) +Voting 22.5.3.1 [optional.optional.general] Improve prohibitions on "additional storage" Yes @@ -200,8 +200,8 @@

    Section 22 (4 issues)

    -4072(i) -Ready +4072(i) +Voting 22.5.8 [optional.comp.with.t] std::optional comparisons: constrain harder Yes @@ -209,8 +209,8 @@

    Section 22 (4 issues)

    -4140(i) -Tentatively Ready +4140(i) +Voting 22.9.2.1 [template.bitset.general] Useless default constructors for bit reference types Yes @@ -231,8 +231,8 @@

    Section 23 (3 issues)

    Duplicates -4147(i) -Tentatively Ready +4147(i) +Voting 23.2.4 [sequence.reqmts] Precondition on inplace_vector::emplace Yes @@ -240,8 +240,8 @@

    Section 23 (3 issues)

    -4164(i) -Ready +4164(i) +Voting 23.3.7.5 [forward.list.modifiers] Missing guarantees for forward_list modifiers Yes @@ -250,8 +250,8 @@

    Section 23 (3 issues)

    4135(i) -Tentatively Ready + bool (Status: Voting)">4135(i) +Voting 23.3.7.7 [forward.list.erasure] The helper lambda of std::erase for list should specify return type as bool @@ -273,8 +273,8 @@

    Section 24 (1 issues)

    Duplicates -4170(i) -Tentatively Ready +4170(i) +Voting 24.3.4.14 [iterator.concept.contiguous] contiguous_iterator should require to_address(I{}) Yes @@ -295,8 +295,8 @@

    Section 25 (5 issues)

    Duplicates -4027(i) -Ready +4027(i) +Voting 25.2 [ranges.syn] possibly-const-range should prefer returning const R& Yes @@ -304,8 +304,8 @@

    Section 25 (5 issues)

    -4112(i) -Ready +4112(i) +Voting 25.5.2 [range.utility.helpers] has-arrow should required operator->() to be const-qualified Yes @@ -313,8 +313,8 @@

    Section 25 (5 issues)

    -3899(i) -Ready +3899(i) +Voting 25.8.5 [coro.generator.promise] co_yielding elements of an lvalue generator is unnecessarily inefficient Yes @@ -323,8 +323,8 @@

    Section 25 (5 issues)

    3900(i) -Ready +should not be constrained (Status: Voting)">3900(i) +Voting 25.8.5 [coro.generator.promise] The allocator_arg_t overloads of generator::promise_type::operator new should not be constrained @@ -333,8 +333,8 @@

    Section 25 (5 issues)

    -4119(i) -Tentatively Ready +4119(i) +Voting 25.8.5 [coro.generator.promise] generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed Yes @@ -343,6 +343,7 @@

    Section 25 (5 issues)

    Section 26 (3 issues)

    +

    (view only non-Ready open issues)

    @@ -354,8 +355,8 @@

    Section 26 (3 issues)

    - - + + @@ -363,8 +364,8 @@

    Section 26 (3 issues)

    - - + + @@ -372,8 +373,8 @@

    Section 26 (3 issues)

    - - + + @@ -382,6 +383,7 @@

    Section 26 (3 issues)

    Issue Duplicates
    3918(i)Ready3918(i)Voting 26.11.6 [uninitialized.move] std::uninitialized_move/_n and guaranteed copy elision Yes
    3436(i)Ready3436(i)Voting 26.11.8 [specialized.construct] std::construct_at should support arrays Yes
    4085(i)Ready4085(i)Voting 26.12.2 [alg.rand.generate] ranges::generate_random's helper lambda should specify the return type Yes

    Section 27 (1 issues)

    +

    (view only non-Ready open issues)

    @@ -393,8 +395,8 @@

    Section 27 (1 issues)

    - - + + @@ -415,8 +417,8 @@

    Section 28 (2 issues)

    - - + + @@ -424,8 +426,8 @@

    Section 28 (2 issues)

    - - + + @@ -446,8 +448,8 @@

    Section 29 (3 issues)

    - - + + @@ -455,8 +457,8 @@

    Section 29 (3 issues)

    - - + + @@ -464,8 +466,8 @@

    Section 29 (3 issues)

    - - + + @@ -486,8 +488,8 @@

    Section 30 (1 issues)

    - - + + @@ -508,8 +510,8 @@

    Section 31 (2 issues)

    - - + + @@ -517,8 +519,8 @@

    Section 31 (2 issues)

    - - + + @@ -539,8 +541,8 @@

    Section 32 (2 issues)

    - - + + @@ -548,8 +550,8 @@

    Section 32 (2 issues)

    - - + + diff --git a/votable-status-date.html b/votable-status-date.html index 578c67b4ae..37697840ef 100644 --- a/votable-status-date.html +++ b/votable-status-date.html @@ -67,8 +67,8 @@

    Index by Status and Date

    This document is the Index by Status and Date for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    -

    Revised 2024-11-18 at 13:27:23 UTC -

    Ready (15 issues)

    +

    Revised 2024-11-19 at 16:10:33 UTC +

    Voting (34 issues)

    Issue Duplicates
    4064(i)Ready4064(i)Voting 27.5.1 [cstring.syn] Clarify that std::launder is not needed when using the result of std::memcpy Yes Duplicates
    4084(i)Tentatively Ready4084(i)Voting 28.3.4.3.3.3 [facet.num.put.virtuals] std::fixed ignores std::uppercase Yes
    4142(i)Tentatively Ready4142(i)Voting 28.5.6.6 [format.parse.ctx] format_parse_context::check_dynamic_spec should require at least one type Yes Duplicates
    4014(i)Ready4014(i)Voting 29.5.4.4 [rand.eng.sub] LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code Yes
    4134(i)Ready4134(i)Voting 29.5.4.5 [rand.eng.philox] Issue with Philox algorithm specification Yes
    4153(i)Tentatively Ready4153(i)Voting 29.5.4.5 [rand.eng.philox] Fix extra "-1" for philox_engine::max() Yes Duplicates
    4124(i)Tentatively Ready4124(i)Voting 30.12 [time.format] Cannot format zoned_time with resolution coarser than seconds Yes Duplicates
    4088(i)Tentatively Ready4088(i)Voting 31.7.6.3.5 [ostream.formatted.print] println ignores the locale imbued in std::ostream Yes
    4044(i)Ready4044(i)Voting 31.7.10 [print.fun] Confusing requirements for std::print on POSIX platforms Yes Duplicates
    4169(i)Tentatively Ready4169(i)Voting 32.5.8.2 [atomics.types.operations] std::atomic<T>'s default constructor should be constrained Yes
    4154(i)Ready4154(i)Voting 32.10.10.2 [futures.task.members] The Mandates for std::packaged_task's constructor from a callable entity should consider decaying Yes
    @@ -80,44 +80,53 @@

    Index by Status and Date

    - - - - + + + + - + - - - - + + + + - + - - - - + + + + - + - - - - + + + + + + + + + + + + + - - + + @@ -125,184 +134,174 @@

    Index by Status and Date

    - - - - + + + + - + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - - - - + + + + - - - - + + + + - + - - - - + + + + - + -
    Issue Duplicates
    4164(i)Ready23.3.7.5 [forward.list.modifiers]Missing guarantees for forward_list modifiers4126(i)Voting17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestanding Yes32
    4085(i)Ready26.12.2 [alg.rand.generate]ranges::generate_random's helper lambda should specify the return type4157(i)Voting17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R3 Yes2
    4014(i)Ready29.5.4.4 [rand.eng.sub]LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code4144(i)Voting20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D> Yes2
    4154(i)Ready32.10.10.2 [futures.task.members]The Mandates for std::packaged_task's constructor from a callable entity should consider decaying4148(i)Voting20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling referencesYes
    3216(i)Voting20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_shared Yes 3
    4024(i)Ready4024(i)Voting 20.3.2.2.7 [util.smartptr.shared.create] Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite Yes
    4072(i)Ready22.5.8 [optional.comp.with.t]std::optional comparisons: constrain harder4113(i)Voting21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]> Yes1
    4134(i)Ready29.5.4.5 [rand.eng.philox]Issue with Philox algorithm specification3886(i)Voting22.5.3.1 [optional.optional.general]Monad mo' problems Yes13
    4027(i)Ready25.2 [ranges.syn]possibly-const-range should prefer returning const R&4141(i)Voting22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage" Yes2
    3899(i)Ready25.8.5 [coro.generator.promise]co_yielding elements of an lvalue generator is unnecessarily inefficient4072(i)Voting22.5.8 [optional.comp.with.t]std::optional comparisons: constrain harder Yes31
    3900(i)Ready25.8.5 [coro.generator.promise]The allocator_arg_t overloads of generator::promise_type::operator new -should not be constrained4140(i)Voting22.9.2.1 [template.bitset.general]Useless default constructors for bit reference types Yes3
    4064(i)Ready27.5.1 [cstring.syn]Clarify that std::launder is not needed when using the result of std::memcpy4147(i)Voting23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplace Yes3
    3918(i)Ready26.11.6 [uninitialized.move]std::uninitialized_move/_n and guaranteed copy elision4164(i)Voting23.3.7.5 [forward.list.modifiers]Missing guarantees for forward_list modifiers Yes 3
    4112(i)Ready25.5.2 [range.utility.helpers]has-arrow should required operator->() to be const-qualified4135(i)Voting23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as + bool Yes
    3436(i)Ready26.11.8 [specialized.construct]std::construct_at should support arrays4170(i)Voting24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{}) Yes2
    4044(i)Ready31.7.10 [print.fun]Confusing requirements for std::print on POSIX platforms4027(i)Voting25.2 [ranges.syn]possibly-const-range should prefer returning const R& Yes32
    -

    Tentatively Ready (19 issues)

    - - - - - - - - - - - - - - + + + + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - - + + @@ -310,95 +309,84 @@

    Tentatively Ready (19 issues)

    - - - - + + + + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - - - - + + + + - - - - + + + + - - - - - - - - - - - - - + + + + - + - - - - + + + + - - - - + + + + - +
    IssueStatusSectionTitleProposed ResolutionPriorityDuplicates
    4144(i)Tentatively Ready20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D>4112(i)Voting25.5.2 [range.utility.helpers]has-arrow should required operator->() to be const-qualified Yes
    4170(i)Tentatively Ready24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{})3899(i)Voting25.8.5 [coro.generator.promise]co_yielding elements of an lvalue generator is unnecessarily inefficient Yes3
    4169(i)Tentatively Ready32.5.8.2 [atomics.types.operations]std::atomic<T>'s default constructor should be constrained3900(i)Voting25.8.5 [coro.generator.promise]The allocator_arg_t overloads of generator::promise_type::operator new +should not be constrained Yes3
    4088(i)Tentatively Ready31.7.6.3.5 [ostream.formatted.print]println ignores the locale imbued in std::ostream4119(i)Voting25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed Yes
    4157(i)Tentatively Ready17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R33918(i)Voting26.11.6 [uninitialized.move]std::uninitialized_move/_n and guaranteed copy elision Yes3
    3216(i)Tentatively Ready20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_shared3436(i)Voting26.11.8 [specialized.construct]std::construct_at should support arrays Yes32
    4153(i)Tentatively Ready29.5.4.5 [rand.eng.philox]Fix extra "-1" for philox_engine::max()4085(i)Voting26.12.2 [alg.rand.generate]ranges::generate_random's helper lambda should specify the return type Yes2
    3886(i)Tentatively Ready22.5.3.1 [optional.optional.general]Monad mo' problems4064(i)Voting27.5.1 [cstring.syn]Clarify that std::launder is not needed when using the result of std::memcpy Yes 3
    4084(i)Tentatively Ready4084(i)Voting 28.3.4.3.3.3 [facet.num.put.virtuals] std::fixed ignores std::uppercase Yes
    4148(i)Tentatively Ready20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling references4142(i)Voting28.5.6.6 [format.parse.ctx]format_parse_context::check_dynamic_spec should require at least one type Yes
    4141(i)Tentatively Ready22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage"4014(i)Voting29.5.4.4 [rand.eng.sub]LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code Yes2
    4140(i)Tentatively Ready22.9.2.1 [template.bitset.general]Useless default constructors for bit reference types4134(i)Voting29.5.4.5 [rand.eng.philox]Issue with Philox algorithm specification Yes1
    4147(i)Tentatively Ready23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplace4153(i)Voting29.5.4.5 [rand.eng.philox]Fix extra "-1" for philox_engine::max() Yes
    4142(i)Tentatively Ready28.5.6.6 [format.parse.ctx]format_parse_context::check_dynamic_spec should require at least one type4124(i)Voting30.12 [time.format]Cannot format zoned_time with resolution coarser than seconds Yes
    4135(i)Tentatively Ready23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as - bool4088(i)Voting31.7.6.3.5 [ostream.formatted.print]println ignores the locale imbued in std::ostream Yes
    4126(i)Tentatively Ready17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestandingYes2
    4113(i)Tentatively Ready21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]>4044(i)Voting31.7.10 [print.fun]Confusing requirements for std::print on POSIX platforms Yes3
    4119(i)Tentatively Ready25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed4169(i)Voting32.5.8.2 [atomics.types.operations]std::atomic<T>'s default constructor should be constrained Yes
    4124(i)Tentatively Ready30.12 [time.format]Cannot format zoned_time with resolution coarser than seconds4154(i)Voting32.10.10.2 [futures.task.members]The Mandates for std::packaged_task's constructor from a callable entity should consider decaying Yes3
    diff --git a/votable-status.html b/votable-status.html index 8da97b22d9..a7d31d0a83 100644 --- a/votable-status.html +++ b/votable-status.html @@ -62,8 +62,8 @@

    Index by Status and Section

    Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    -

    Revised 2024-11-18 at 13:27:23 UTC -

    Ready (15 issues)

    +

    Revised 2024-11-19 at 16:10:33 UTC +

    Voting (34 issues)

    @@ -75,276 +75,228 @@

    Index by Status and Section

    - - - - + + + + - - - - - - - - - - - - - + + + + - - - - - - - - - - - - - + + + + - - - - + + + + - - - - - - - - - - - - - + + + + - - - - + + + + - - - - + + + + - + - - - - + + + + - - - - + + + + - + - - - - + + + + - - - - + + + + - - - - - - - - - -
    Issue Duplicates
    4024(i)Ready20.3.2.2.7 [util.smartptr.shared.create]Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite4126(i)Voting17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestanding Yes 2
    4072(i)Ready22.5.8 [optional.comp.with.t]std::optional comparisons: constrain harderYes1
    4164(i)Ready23.3.7.5 [forward.list.modifiers]Missing guarantees for forward_list modifiers4157(i)Voting17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R3 Yes3
    4027(i)Ready25.2 [ranges.syn]possibly-const-range should prefer returning const R&Yes2
    4112(i)Ready25.5.2 [range.utility.helpers]has-arrow should required operator->() to be const-qualified4144(i)Voting20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D> Yes
    3899(i)Ready25.8.5 [coro.generator.promise]co_yielding elements of an lvalue generator is unnecessarily inefficient4148(i)Voting20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling references Yes3
    3900(i)Ready25.8.5 [coro.generator.promise]The allocator_arg_t overloads of generator::promise_type::operator new -should not be constrainedYes3
    3918(i)Ready26.11.6 [uninitialized.move]std::uninitialized_move/_n and guaranteed copy elision3216(i)Voting20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_shared Yes 3
    3436(i)Ready26.11.8 [specialized.construct]std::construct_at should support arrays4024(i)Voting20.3.2.2.7 [util.smartptr.shared.create]Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite Yes 2
    4085(i)Ready26.12.2 [alg.rand.generate]ranges::generate_random's helper lambda should specify the return type4113(i)Voting21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]> Yes2
    4064(i)Ready27.5.1 [cstring.syn]Clarify that std::launder is not needed when using the result of std::memcpy3886(i)Voting22.5.3.1 [optional.optional.general]Monad mo' problems Yes 3
    4014(i)Ready29.5.4.4 [rand.eng.sub]LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code4141(i)Voting22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage" Yes2
    4134(i)Ready29.5.4.5 [rand.eng.philox]Issue with Philox algorithm specification4072(i)Voting22.5.8 [optional.comp.with.t]std::optional comparisons: constrain harder Yes 1
    4044(i)Ready31.7.10 [print.fun]Confusing requirements for std::print on POSIX platforms4140(i)Voting22.9.2.1 [template.bitset.general]Useless default constructors for bit reference types Yes3
    4154(i)Ready32.10.10.2 [futures.task.members]The Mandates for std::packaged_task's constructor from a callable entity should consider decayingYes3
    -

    Tentatively Ready (19 issues)

    - - - - - - - - - - - - - - + + + + - + - - - - + + + + - + - - - - + + + + - - - - + + + + - - - - + + + + - + - - - - + + + + - - - - + + + + - - - - + + + + - + - - - - + + + + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - + - - - - + + + + - + - - + + @@ -352,8 +304,8 @@

    Tentatively Ready (19 issues)

    - - + + @@ -361,8 +313,26 @@

    Tentatively Ready (19 issues)

    - - + + + + + + + + + + + + + + + + + + + + @@ -370,8 +340,8 @@

    Tentatively Ready (19 issues)

    - - + + @@ -379,8 +349,8 @@

    Tentatively Ready (19 issues)

    - - + + @@ -388,14 +358,32 @@

    Tentatively Ready (19 issues)

    - - + + + + + + + + + + + + + + + + + + + +
    IssueStatusSectionTitleProposed ResolutionPriorityDuplicates
    4126(i)Tentatively Ready17.3.2 [version.syn]Some feature-test macros for fully freestanding features are not yet marked freestanding4147(i)Voting23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplace Yes2
    4157(i)Tentatively Ready17.11.6 [cmp.alg]The resolution of LWG3465 was damaged by P2167R34164(i)Voting23.3.7.5 [forward.list.modifiers]Missing guarantees for forward_list modifiers Yes3
    4144(i)Tentatively Ready20.3.1.3.1 [unique.ptr.single.general]Disallow unique_ptr<T&, D>4135(i)Voting23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as + bool Yes
    4148(i)Tentatively Ready20.3.1.3.5 [unique.ptr.single.observers]unique_ptr::operator* should not allow dangling references4170(i)Voting24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{}) Yes
    3216(i)Tentatively Ready20.3.2.2.7 [util.smartptr.shared.create]Rebinding the allocator before calling construct/destroy in allocate_shared4027(i)Voting25.2 [ranges.syn]possibly-const-range should prefer returning const R& Yes32
    4113(i)Tentatively Ready21.3.5.4 [meta.unary.prop]Disallow has_unique_object_representations<Incomplete[]>4112(i)Voting25.5.2 [range.utility.helpers]has-arrow should required operator->() to be const-qualified Yes
    3886(i)Tentatively Ready22.5.3.1 [optional.optional.general]Monad mo' problems3899(i)Voting25.8.5 [coro.generator.promise]co_yielding elements of an lvalue generator is unnecessarily inefficient Yes 3
    4141(i)Tentatively Ready22.5.3.1 [optional.optional.general]Improve prohibitions on "additional storage"3900(i)Voting25.8.5 [coro.generator.promise]The allocator_arg_t overloads of generator::promise_type::operator new +should not be constrained Yes3
    4140(i)Tentatively Ready22.9.2.1 [template.bitset.general]Useless default constructors for bit reference types4119(i)Voting25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed Yes
    4147(i)Tentatively Ready23.2.4 [sequence.reqmts]Precondition on inplace_vector::emplace3918(i)Voting26.11.6 [uninitialized.move]std::uninitialized_move/_n and guaranteed copy elision Yes3
    4135(i)Tentatively Ready23.3.7.7 [forward.list.erasure]The helper lambda of std::erase for list should specify return type as - bool3436(i)Voting26.11.8 [specialized.construct]std::construct_at should support arrays Yes2
    4170(i)Tentatively Ready24.3.4.14 [iterator.concept.contiguous]contiguous_iterator should require to_address(I{})4085(i)Voting26.12.2 [alg.rand.generate]ranges::generate_random's helper lambda should specify the return type Yes2
    4119(i)Tentatively Ready25.8.5 [coro.generator.promise]generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed4064(i)Voting27.5.1 [cstring.syn]Clarify that std::launder is not needed when using the result of std::memcpy Yes3
    4084(i)Tentatively Ready4084(i)Voting 28.3.4.3.3.3 [facet.num.put.virtuals] std::fixed ignores std::uppercase Yes
    4142(i)Tentatively Ready4142(i)Voting 28.5.6.6 [format.parse.ctx] format_parse_context::check_dynamic_spec should require at least one type Yes
    4153(i)Tentatively Ready4014(i)Voting29.5.4.4 [rand.eng.sub]LWG 3809 changes behavior of some existing std::subtract_with_carry_engine codeYes2
    4134(i)Voting29.5.4.5 [rand.eng.philox]Issue with Philox algorithm specificationYes1
    4153(i)Voting 29.5.4.5 [rand.eng.philox] Fix extra "-1" for philox_engine::max() Yes
    4124(i)Tentatively Ready4124(i)Voting 30.12 [time.format] Cannot format zoned_time with resolution coarser than seconds Yes
    4088(i)Tentatively Ready4088(i)Voting 31.7.6.3.5 [ostream.formatted.print] println ignores the locale imbued in std::ostream Yes
    4169(i)Tentatively Ready4044(i)Voting31.7.10 [print.fun]Confusing requirements for std::print on POSIX platformsYes3
    4169(i)Voting 32.5.8.2 [atomics.types.operations] std::atomic<T>'s default constructor should be constrained Yes
    4154(i)Voting32.10.10.2 [futures.task.members]The Mandates for std::packaged_task's constructor from a callable entity should consider decayingYes3
    diff --git a/votable-toc.html b/votable-toc.html index 4aee5e5360..c3c1652086 100644 --- a/votable-toc.html +++ b/votable-toc.html @@ -59,7 +59,7 @@

    Table of Contents

    Reference ISO/IEC IS 14882:2024(E)

    This document is the Table of Contents for the Library Active Issues List, Library Defect Reports and Accepted Issues, and Library Closed Issues List.

    -

    Revised 2024-11-18 at 13:27:23 UTC +

    Revised 2024-11-19 at 16:10:33 UTC

    @@ -71,8 +71,8 @@

    Table of Contents

    - - + + @@ -80,8 +80,8 @@

    Table of Contents

    - - + + @@ -89,8 +89,8 @@

    Table of Contents

    - - + + @@ -98,8 +98,8 @@

    Table of Contents

    - - + + @@ -108,8 +108,8 @@

    Table of Contents

    - +should not be constrained (Status: Voting)">3900(i) + @@ -118,8 +118,8 @@

    Table of Contents

    - - + + @@ -127,8 +127,8 @@

    Table of Contents

    - - + + @@ -136,8 +136,8 @@

    Table of Contents

    - - + + @@ -145,8 +145,8 @@

    Table of Contents

    - - + + @@ -154,8 +154,8 @@

    Table of Contents

    - - + + @@ -163,8 +163,8 @@

    Table of Contents

    - - + + @@ -172,8 +172,8 @@

    Table of Contents

    - - + + @@ -181,8 +181,8 @@

    Table of Contents

    - - + + @@ -190,8 +190,8 @@

    Table of Contents

    - - + + @@ -199,8 +199,8 @@

    Table of Contents

    - - + + @@ -208,8 +208,8 @@

    Table of Contents

    - - + + @@ -217,8 +217,8 @@

    Table of Contents

    - - + + @@ -226,8 +226,8 @@

    Table of Contents

    - - + + @@ -235,8 +235,8 @@

    Table of Contents

    - - + + @@ -244,8 +244,8 @@

    Table of Contents

    - - + + @@ -253,8 +253,8 @@

    Table of Contents

    - - + + @@ -263,8 +263,8 @@

    Table of Contents

    - + bool (Status: Voting)">4135(i) + @@ -273,8 +273,8 @@

    Table of Contents

    - - + + @@ -282,8 +282,8 @@

    Table of Contents

    - - + + @@ -291,8 +291,8 @@

    Table of Contents

    - - + + @@ -300,8 +300,8 @@

    Table of Contents

    - - + + @@ -309,8 +309,8 @@

    Table of Contents

    - - + + @@ -318,8 +318,8 @@

    Table of Contents

    - - + + @@ -327,8 +327,8 @@

    Table of Contents

    - - + + @@ -336,8 +336,8 @@

    Table of Contents

    - - + + @@ -345,8 +345,8 @@

    Table of Contents

    - - + + @@ -354,8 +354,8 @@

    Table of Contents

    - - + + @@ -363,8 +363,8 @@

    Table of Contents

    - - + + @@ -372,8 +372,8 @@

    Table of Contents

    - - + +
    Issue Duplicates
    3216(i)Tentatively Ready3216(i)Voting 20.3.2.2.7 [util.smartptr.shared.create] Rebinding the allocator before calling construct/destroy in allocate_shared Yes
    3436(i)Ready3436(i)Voting 26.11.8 [specialized.construct] std::construct_at should support arrays Yes
    3886(i)Tentatively Ready3886(i)Voting 22.5.3.1 [optional.optional.general] Monad mo' problems Yes
    3899(i)Ready3899(i)Voting 25.8.5 [coro.generator.promise] co_yielding elements of an lvalue generator is unnecessarily inefficient Yes
    3900(i)ReadyVoting 25.8.5 [coro.generator.promise] The allocator_arg_t overloads of generator::promise_type::operator new should not be constrained
    3918(i)Ready3918(i)Voting 26.11.6 [uninitialized.move] std::uninitialized_move/_n and guaranteed copy elision Yes
    4014(i)Ready4014(i)Voting 29.5.4.4 [rand.eng.sub] LWG 3809 changes behavior of some existing std::subtract_with_carry_engine code Yes
    4024(i)Ready4024(i)Voting 20.3.2.2.7 [util.smartptr.shared.create] Underspecified destruction of objects created in std::make_shared_for_overwrite/std::allocate_shared_for_overwrite Yes
    4027(i)Ready4027(i)Voting 25.2 [ranges.syn] possibly-const-range should prefer returning const R& Yes
    4044(i)Ready4044(i)Voting 31.7.10 [print.fun] Confusing requirements for std::print on POSIX platforms Yes
    4064(i)Ready4064(i)Voting 27.5.1 [cstring.syn] Clarify that std::launder is not needed when using the result of std::memcpy Yes
    4072(i)Ready4072(i)Voting 22.5.8 [optional.comp.with.t] std::optional comparisons: constrain harder Yes
    4084(i)Tentatively Ready4084(i)Voting 28.3.4.3.3.3 [facet.num.put.virtuals] std::fixed ignores std::uppercase Yes
    4085(i)Ready4085(i)Voting 26.12.2 [alg.rand.generate] ranges::generate_random's helper lambda should specify the return type Yes
    4088(i)Tentatively Ready4088(i)Voting 31.7.6.3.5 [ostream.formatted.print] println ignores the locale imbued in std::ostream Yes
    4112(i)Ready4112(i)Voting 25.5.2 [range.utility.helpers] has-arrow should required operator->() to be const-qualified Yes
    4113(i)Tentatively Ready4113(i)Voting 21.3.5.4 [meta.unary.prop] Disallow has_unique_object_representations<Incomplete[]> Yes
    4119(i)Tentatively Ready4119(i)Voting 25.8.5 [coro.generator.promise] generator::promise_type::yield_value(ranges::elements_of<R, Alloc>)'s nested generator may be ill-formed Yes
    4124(i)Tentatively Ready4124(i)Voting 30.12 [time.format] Cannot format zoned_time with resolution coarser than seconds Yes
    4126(i)Tentatively Ready4126(i)Voting 17.3.2 [version.syn] Some feature-test macros for fully freestanding features are not yet marked freestanding Yes
    4134(i)Ready4134(i)Voting 29.5.4.5 [rand.eng.philox] Issue with Philox algorithm specification Yes
    4135(i)Tentatively ReadyVoting 23.3.7.7 [forward.list.erasure] The helper lambda of std::erase for list should specify return type as bool
    4140(i)Tentatively Ready4140(i)Voting 22.9.2.1 [template.bitset.general] Useless default constructors for bit reference types Yes
    4141(i)Tentatively Ready4141(i)Voting 22.5.3.1 [optional.optional.general] Improve prohibitions on "additional storage" Yes
    4142(i)Tentatively Ready4142(i)Voting 28.5.6.6 [format.parse.ctx] format_parse_context::check_dynamic_spec should require at least one type Yes
    4144(i)Tentatively Ready4144(i)Voting 20.3.1.3.1 [unique.ptr.single.general] Disallow unique_ptr<T&, D> Yes
    4147(i)Tentatively Ready4147(i)Voting 23.2.4 [sequence.reqmts] Precondition on inplace_vector::emplace Yes
    4148(i)Tentatively Ready4148(i)Voting 20.3.1.3.5 [unique.ptr.single.observers] unique_ptr::operator* should not allow dangling references Yes
    4153(i)Tentatively Ready4153(i)Voting 29.5.4.5 [rand.eng.philox] Fix extra "-1" for philox_engine::max() Yes
    4154(i)Ready4154(i)Voting 32.10.10.2 [futures.task.members] The Mandates for std::packaged_task's constructor from a callable entity should consider decaying Yes
    4157(i)Tentatively Ready4157(i)Voting 17.11.6 [cmp.alg] The resolution of LWG3465 was damaged by P2167R3 Yes
    4164(i)Ready4164(i)Voting 23.3.7.5 [forward.list.modifiers] Missing guarantees for forward_list modifiers Yes
    4169(i)Tentatively Ready4169(i)Voting 32.5.8.2 [atomics.types.operations] std::atomic<T>'s default constructor should be constrained Yes
    4170(i)Tentatively Ready4170(i)Voting 24.3.4.14 [iterator.concept.contiguous] contiguous_iterator should require to_address(I{}) Yes