C++ Standard Library Issues List (Revision D125)

Index by Section

Reference ISO/IEC IS 14882:2024(E)

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-14 at 11:34:10 UTC

Section 3 (2 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3513⁽ⁱ⁾	New	3.42 [defns.prog.def.type]	Fix definition of program-defined based on its uses	Yes	3
4005⁽ⁱ⁾	New	3.47 [defns.required.behavior]	"Required behavior" too narrowly defined	No	2

Section 4 (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3669⁽ⁱ⁾	New	4.1.2 [intro.abstract]	`std::filesystem` operations should be observable behaviour	No	3

Section 6 (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
2506⁽ⁱ⁾	SG1	6.9.2 [intro.multithread]	Underspecification of atomics	No	3

Section 16 (43 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3105⁽ⁱ⁾	New	16 [library]	`T1` is convertible to `T2`	No	3
2949⁽ⁱ⁾	New	16 [library]	Unclear complexity requirements: space vs. time	No	4
3538⁽ⁱ⁾	New	16.2 [library.c]	§[library.c] C library functions are not addressable	No	2
2136⁽ⁱ⁾	Open	16.3.2 [structure]	Postconditions vs. exceptions	Yes	3
3556⁽ⁱ⁾	New	16.3.2.3 [structure.requirements]	Specification of when semantic constraints are imposed by use of concepts is unclear	No	3
3193⁽ⁱ⁾	New	16.3.2.4 [structure.specifications]	Mandates: and Expects: elements are not defined for types	Yes	3
3401⁽ⁱ⁾	New	16.3.2.4 [structure.specifications]	Is "as if by" equivalent to "equivalent to"?	No	3
3977⁽ⁱ⁾	New	16.3.3.3.3 [bitmask.types]	`constexpr` and `noexcept` for operators for bitmask types	Yes	3
3092⁽ⁱ⁾	Open	16.3.3.3.3 [bitmask.types]	Unclear semantics of `enum class` bitmask types	Yes	3
3620⁽ⁱ⁾	New	16.3.3.3.4.1 [character.seq.general]	What are execution character sets and execution wide-character sets (after P2314R4)?	No	3
4049⁽ⁱ⁾	New	16.4.2 [organization]	C `<foo.h>` headers not in freestanding	Yes	3
3690⁽ⁱ⁾	New	16.4.2.2 [contents]	`std::make_from_tuple` etc. should find all tuple-like `std::get` overloads	Yes	3
3240⁽ⁱ⁾	New	16.4.3.2 [using.headers]	Headers declare more than entities	No	3
3640⁽ⁱ⁾	New	16.4.4 [utility.requirements]	Clarify which exceptions are propagated	Yes	3
4075⁽ⁱ⁾	SG1	16.4.4 [utility.requirements]	Thread stability requirement on constructors and destructors	No	3
2146⁽ⁱ⁾	Open	16.4.4.2 [utility.arg.requirements]	Are reference types `Copy`/`Move-Constructible`/`Assignable` or `Destructible`?	No	3
2152⁽ⁱ⁾	LEWG	16.4.4.3 [swappable.requirements]	Instances of standard container types are not swappable	Yes	3
4155⁽ⁱ⁾	New	16.4.4.4 [nullablepointer.requirements]	Cpp17NullablePointer should require that some expression can be contextually converted to bool	Yes	3
3044⁽ⁱ⁾	New	16.4.4.6 [allocator.requirements]	Strange specification of `max_size()` for an allocator	Yes	3
3267⁽ⁱ⁾	New	16.4.4.6 [allocator.requirements]	Rebound allocators and `is_always_equal`	Yes	4
3157⁽ⁱ⁾	New	16.4.4.6 [allocator.requirements]	Allocator `destroy` and fancy pointer operations must be non-throwing	Yes	3
2461⁽ⁱ⁾	New	16.4.4.6 [allocator.requirements]	Interaction between allocators and container exception safety guarantees	No	3
4128⁽ⁱ⁾	New	16.4.4.6.1 [allocator.requirements.general]	Allocator requirements should not allow rebinding conversions to be explicit	Yes	3
4065⁽ⁱ⁾	New	16.4.4.6.1 [allocator.requirements.general]	Requirements for fancy pointers might be insufficient for self-referential implementation of containers	Yes	3
3682⁽ⁱ⁾	New	16.4.4.6.1 [allocator.requirements.general]	A Cpp17Allocator type can't silently ignore an unsupported alignment	No	3
4047⁽ⁱ⁾	New	16.4.5.2.1 [namespace.std]	Explicitly specifying template arguments for `std::swap` should not be supported	No	4
3926⁽ⁱ⁾	New	16.4.5.2.1 [namespace.std]	Which namespace `std` is the mentioned one?	Yes	4
3928⁽ⁱ⁾	New	16.4.5.2.2 [namespace.posix]	Non-top-level namespace `posix` shouldn't be reserved	Yes	3
3550⁽ⁱ⁾	New	16.4.5.3 [reserved.names]	Names reserved by C for standard library not reserved by C++	No	3
4149⁽ⁱ⁾	New	16.4.5.3.3 [macro.names]	User defined macros without standard headers (294 redux)	Yes
4033⁽ⁱ⁾	New	16.4.5.3.3 [macro.names]	§[macro.names] defining macros after importing the standard library	Yes	3
3920⁽ⁱ⁾	New	16.4.5.3.4 [extern.names]	Bad footnotes claiming external linkage for entities defined as macros	No	3
3142⁽ⁱ⁾	New	16.4.5.8 [res.on.functions]	`std::foo<incomplete>` should be ill-formed NDR	Yes	3
3511⁽ⁱ⁾	New	16.4.5.9 [res.on.arguments]	Clarify global permission to move	Yes	3
4068⁽ⁱ⁾	New	16.4.5.11 [res.on.requirements]	Terminology for objects whose types model a concept	No
3429⁽ⁱ⁾	New	16.4.5.11 [res.on.requirements]	"models" should subsume like "satisfies"	Yes	3
4100⁽ⁱ⁾	New	16.4.6.4 [global.functions]	Default arguments and signatures of standard library non-member functions	Yes	3
2695⁽ⁱ⁾	New	16.4.6.5 [member.functions]	"As if" unclear in [member.functions]	No	3
2414⁽ⁱ⁾	Open	16.4.6.9 [reentrancy]	Member function reentrancy should be implementation-defined	Yes	3
4145⁽ⁱ⁾	New	16.4.6.10 [res.on.data.races]	Unclear how [res.on.data.races] apply to templated functions	No	3
4129⁽ⁱ⁾	New	16.4.6.10 [res.on.data.races]	Possibly incorrect wording for data race avoidance	Yes
3854⁽ⁱ⁾	New	16.4.6.13 [res.on.exception.handling]	§[res.on.exception.handling]/3 should not be applied to all standard library types	No	3
3229⁽ⁱ⁾	New	16.4.6.13 [res.on.exception.handling]	§[res.on.exception.handling]#3 cannot apply to types with implicitly declared destructors	Yes	3

Section 17 (30 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3217⁽ⁱ⁾	New	17.3.1 [support.limits.general]	`<memory>` and `<execution>` should define `__cpp_lib_parallel_algorithm`	Yes	3
3931⁽ⁱ⁾	New	17.3.2 [version.syn]	Too many paper bump `__cpp_lib_ranges`	Yes	3
2248⁽ⁱ⁾	New	17.3.5 [numeric.limits]	`numeric_limits::is_iec559` misnamed	No	4
2730⁽ⁱ⁾	Open	17.3.5 [numeric.limits]	`numeric_limits` primary template definition	No	3
3922⁽ⁱ⁾	New	17.3.5.1 [numeric.limits.general]	It's unclear whether `numeric_limits` can be specialized by users	Yes	3
3923⁽ⁱ⁾	New	17.3.5.1 [numeric.limits.general]	The specification of `numeric_limits` doesn't clearly distinguish between implementation requirements and user requirements	Yes	3
3370⁽ⁱ⁾	New	17.4.1 [cstdint.syn]	§[cstdint.syn]p2 and §[headers]p5 are not sufficiently clear	No	3
3084⁽ⁱ⁾	New	17.5 [support.start.term]	Termination in C++ is unclear	No	3
2815⁽ⁱ⁾	New	17.5 [support.start.term]	`quick_exit` can deadlock	Yes	3
3086⁽ⁱ⁾	New	17.6.3.2 [new.delete.single]	Possible problem in §[new.delete.single]	Yes	3
2737⁽ⁱ⁾	New	17.6.3.2 [new.delete.single]	Consider relaxing object size restrictions for single-object allocation functions	No	3
2303⁽ⁱ⁾	New	17.6.3.4 [new.delete.placement]	Explicit instantiation of `std::vector<UserType>` broken?	No	3
2508⁽ⁱ⁾	New	17.6.3.5 [new.delete.dataraces]	§[new.delete.dataraces] wording needs to be updated	No	3
4130⁽ⁱ⁾	New	17.6.5 [ptr.launder]	Preconditions for `std::launder` might be overly strict	Yes	3
3624⁽ⁱ⁾	New	17.7 [support.rtti]	Inconsistency of `<typeinfo>`, `<initializer_list>`, and `<compare>` in the standard library	Yes	3
2398⁽ⁱ⁾	Open	17.7.3 [type.info]	`type_info`'s destructor shouldn't be required to be virtual	Yes	3
4087⁽ⁱ⁾	SG16	17.9.3 [exception]	Standard exception messages have unspecified encoding	Yes	3
2453⁽ⁱ⁾	New	17.10 [support.initlist]	§[iterator.range] and now [iterator.container] aren't available via `<initializer_list>`	No	3
2493⁽ⁱ⁾	New	17.10 [support.initlist]	`initializer_list` supports incomplete classes	No	4
4051⁽ⁱ⁾	New	17.11.2 [cmp.categories]	A less hacky and more useful way to compare comparison category types	Yes
3584⁽ⁱ⁾	New	17.11.3 [cmp.common]	Clarify common comparison category conversions	Yes	3
3587⁽ⁱ⁾	New	17.11.4 [cmp.concept]	`std::three_way_comparable_with<T, U, void>` can be satisfied but can't be modeled	No	3
3932⁽ⁱ⁾	New	17.11.6 [cmp.alg]	Expression-equivalence is sometimes unimplementable when passing prvalue expressions to comparison CPOs	No	3
3491⁽ⁱ⁾	New	17.11.6 [cmp.alg]	What is a "decayed type"?	No	3
3653⁽ⁱ⁾	New	17.12.2 [coroutine.syn]	`<coroutine>` is freestanding, but uses `std::hash` which is not	No	3
3945⁽ⁱ⁾	New	17.13.2 [cstdarg.syn]	§[cstdarg.syn] 'Compatible types' are undefined	No	3
3954⁽ⁱ⁾	New	17.14.1 [support.c.headers.general]	Feature-test macros in C headers (`<stddef.h>` etc.)	No	3
3883⁽ⁱ⁾	New	17.14.7 [support.c.headers.other]	§[support.c.headers.other] Ambiguity in the requirements for includes	Yes	4
3799⁽ⁱ⁾	New	17.14.7 [support.c.headers.other]	Should `<math.h>` provide 3-argument `::hypot` overloads?	No	3
3484⁽ⁱ⁾	New	17.14.7 [support.c.headers.other]	Should `<stddef.h>` declare `::nullptr_t`?	Yes	3

Section 18 (5 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3895⁽ⁱ⁾	New	18.3 [concepts.syn]	Various relation concepts are missing default values of the second template parameters	Yes	3
3608⁽ⁱ⁾	New	18.4.4 [concept.convertible]	`convertible_to` and temporary-bound references	No	3
3459⁽ⁱ⁾	New	18.4.4 [concept.convertible]	Why doesn't `std::convertible_to` have semantic requirement when `To` is reference-to-function type?	No	3
4165⁽ⁱ⁾	New	18.4.9 [concept.swappable]	Should swapping a built-in array or `std::array` with itself result in UB?	No
4041⁽ⁱ⁾	New	18.4.9 [concept.swappable]	The requirements on literal type in [concept.swappable] should be removed	Yes	4

Section 19 (8 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3011⁽ⁱ⁾	Open	19.3 [assertions]	Requirements for `assert(E)` inconsistent with C	No	2
4156⁽ⁱ⁾	New	19.5.3.2 [syserr.errcat.virtuals]	`error_category` messages have unspecified encoding	Yes
3019⁽ⁱ⁾	New	19.5.3.4 [syserr.errcat.derived]	Presentation of "program defined classes derived from `error_category`" [syserr.errcat.derived] unclear and contains mistakes	No	3
3053⁽ⁱ⁾	New	19.5.4.1 [syserr.errcode.overview]	Prohibit `error_code` construction from rvalues of `error_category`	Yes	3
3162⁽ⁱ⁾	New	19.5.8.2 [syserr.syserr.members]	`system_error::system_error(error_code ec)` not explicit	Yes	3
3625⁽ⁱ⁾	New	19.6.2 [stacktrace.syn]	Should `<stacktrace>` provide range access function templates?	Yes	3
3507⁽ⁱ⁾	Open	19.6.3.4 [stacktrace.entry.query]	P0881R7 ("stacktrace") does not define "actual file name", "actual line number"	No	2
3626⁽ⁱ⁾	New	19.6.4.1 [stacktrace.basic.overview]	Is `std::basic_stacktrace` required to use contiguous storage?	Yes	3

Section 20 (22 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3454⁽ⁱ⁾	LEWG	20.2.3 [pointer.traits]	`pointer_traits::pointer_to` should be `constexpr`	Yes
4058⁽ⁱ⁾	New	20.2.4 [pointer.conversion]	`std::to_address()` should be SFINAE-friendly	Yes
2421⁽ⁱ⁾	New	20.2.5 [ptr.align]	Non-specification of handling zero size in `std::align` [ptr.align]	No	3
4168⁽ⁱ⁾	New	20.2.6 [obj.lifetime]	`std::start_lifetime_as` inadvertently has undefined behavior due to use of `std::bit_cast`	Yes
3192⁽ⁱ⁾	New	20.2.8.2 [allocator.uses.construction]	§[allocator.uses.construction] functions misbehave for `const` types	Yes	3
3665⁽ⁱ⁾	New	20.2.9.2 [allocator.traits.types]	Is `std::allocator_traits<Alloc>::rebind_alloc` SFINAE-friendly?	No	3
3916⁽ⁱ⁾	New	20.2.10 [default.allocator]	`allocator`, `polymorphic_allocator`, and containers should forbid cv-qualified types	No	3
3917⁽ⁱ⁾	New	20.2.10 [default.allocator]	Validity of `allocator<void>` and possibly `polymorphic_allocator<void>` should be clarified	Yes	3
3684⁽ⁱ⁾	New	20.2.10.2 [allocator.members]	`std::allocator<T>::allocate_at_least` in constant evaluation	Yes	3
3159⁽ⁱ⁾	New	20.3.1.3 [unique.ptr.single]	§[unique.ptr.single] requirements on deleter may be too strict	No	3
2262⁽ⁱ⁾	Open	20.3.1.3 [unique.ptr.single]	Requirement for `unique_ptr<T>::get_deleter()(p)` to be able to destroy the `unique_ptr`	Yes	3
3911⁽ⁱ⁾	New	20.3.1.3.5 [unique.ptr.single.observers]	`unique_ptr`'s `operator*` is missing a mandate	Yes	3
2594⁽ⁱ⁾	New	20.3.2.2 [util.smartptr.shared]	Contradicting definition of empty `shared_ptr` on `shared_ptr(nullptr, d)`	Yes	3
4110⁽ⁱ⁾	New	20.3.2.2.2 [util.smartptr.shared.const]	`shared_ptr(nullptr_t, Deleter)` is overconstrained, breaking some sensible deleters	Yes
4032⁽ⁱ⁾	New	20.3.2.2.2 [util.smartptr.shared.const]	Possibly invalid types in the constraints of constructors of `std::shared_ptr`	Yes	4
2906⁽ⁱ⁾	New	20.3.2.2.2 [util.smartptr.shared.const]	There is no ability to supply an allocator for the control block when constructing a `shared_ptr` from a `unique_ptr`	No	3
2751⁽ⁱ⁾	New	20.3.2.2.3 [util.smartptr.shared.dest]	`shared_ptr` deleter not specified to observe expired `weak_ptr` instances	No	4
3210⁽ⁱ⁾	New	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	3
3681⁽ⁱ⁾	New	20.4.1 [mem.res.syn]	Further considerations on LWG 3679	No	4
3637⁽ⁱ⁾	New	20.4.2 [mem.res.class]	`pmr::memory_resource::do_allocate` needs clarification	No	3
3634⁽ⁱ⁾	New	20.4.4 [mem.res.global]	When are static-duration `memory_resource` objects destroyed?	No	3
2848⁽ⁱ⁾	New	20.4.5.2 [mem.res.pool.options]	Pass-through threshold for pool allocator	No	3

Section 21 (20 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
2290⁽ⁱ⁾	Open	21 [meta]	Top-level "SFINAE"-based constraints should get a separate definition in Clause 17	Yes	3
2452⁽ⁱ⁾	Core	21 [meta]	`is_constructible`, etc. and default arguments	No	3
2845⁽ⁱ⁾	New	21.3.2 [meta.rqmts]	`enable_if`, `result_of`, `common_type` and `aligned_storage` do not meet the definition of `TransformationTrait`	No	3
2939⁽ⁱ⁾	Open	21.3.3 [meta.type.synop]	Some type-completeness constraints of traits are overspecified	Yes	2
3099⁽ⁱ⁾	Open	21.3.3 [meta.type.synop]	`is_assignable<Incomplete&, Incomplete&>`	Yes	2
2922⁽ⁱ⁾	LEWG	21.3.3 [meta.type.synop]	The `*_constant<>` templates do not make use of `template<auto>`	No
3967⁽ⁱ⁾	New	21.3.5.4 [meta.unary.prop]	The specification for `std::is_nothrow_*` traits may be ambiguous in some cases involving `noexcept(false)`	No
3929⁽ⁱ⁾	New	21.3.5.4 [meta.unary.prop]	Preconditions for type traits should be Mandates	Yes	3
2827⁽ⁱ⁾	New	21.3.5.4 [meta.unary.prop]	`is_trivially_constructible` and non-trivial destructors	No	3
3697⁽ⁱ⁾	New	21.3.5.4 [meta.unary.prop]	Preconditions of `reference_constructs_from_temporary/reference_converts_from_temporary` seem wrong	Yes	3
2496⁽ⁱ⁾	New	21.3.5.4 [meta.unary.prop]	Certain hard-to-avoid errors not in the immediate context are not allowed to be triggered by the evaluation of type traits	No	3
2116⁽ⁱ⁾	Open	21.3.5.4 [meta.unary.prop]	`is_nothrow_constructible` and destructors	No	3
2358⁽ⁱ⁾	Open	21.3.5.4 [meta.unary.prop]	Apparently-bogus definition of `is_empty` type trait	Yes	3
2077⁽ⁱ⁾	Open	21.3.5.4 [meta.unary.prop]	Further incomplete constraints for type traits	No	3
3486⁽ⁱ⁾	LEWG	21.3.5.4 [meta.unary.prop]	`is_constructible<T[], T...>` may be misleading in C++20	No
3400⁽ⁱ⁾	New	21.3.7 [meta.rel]	Does `is_nothrow_convertible` consider destruction of the destination type?	No	3
4028⁽ⁱ⁾	New	21.3.7 [meta.rel]	`std::is_(nothrow_)convertible` should be reworded to avoid dependence on the `return` statement	Yes
3174⁽ⁱ⁾	New	21.3.7 [meta.rel]	Precondition on `is_convertible` is too strong	Yes	3
3205⁽ⁱ⁾	New	21.3.8.7 [meta.trans.other]	`decay_t` in the new `common_type` fallback should be `remove_cvref_t`	Yes	3
4138⁽ⁱ⁾	New	21.3.11 [meta.const.eval]	`is_within_lifetime` should mandate `is_object`	Yes

Section 22 (47 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
2153⁽ⁱ⁾	LEWG	22.2.2 [utility.swap]	Narrowing of the non-member `swap` contract	No	2
3902⁽ⁱ⁾	New	22.2.6 [declval]	Return type of `std::declval<cv void>` should be (cv-unqualified) `void`	Yes	4
2599⁽ⁱ⁾	New	22.2.6 [declval]	Library incomplete type permission phrase is unclear	No	3
3342⁽ⁱ⁾	New	22.3.2 [pairs.pair]	Library wording uses "initializes `x` with `y`", which is underspecified	No	3
2289⁽ⁱ⁾	Open	22.3.2 [pairs.pair]	`constexpr` guarantees of defaulted functions still insufficient	No	3
2766⁽ⁱ⁾	New	22.3.3 [pairs.spec]	Swapping non-swappable types	Yes	3
3166⁽ⁱ⁾	New	22.3.4 [pair.astuple]	No such descriptive element as Value:	No	3
3378⁽ⁱ⁾	New	22.4.2 [tuple.syn]	`tuple_size_v/tuple_element_t` should be available when `tuple_size/tuple_element` are	Yes	3
3583⁽ⁱ⁾	New	22.4.4.2 [tuple.cnstr]	Clarify if/when short circuiting applies to conditions in Constraints: elements	No	3
2528⁽ⁱ⁾	New	22.4.4.2 [tuple.cnstr]	Order of `std::tuple` construction unspecified	No	3
4040⁽ⁱ⁾	New	22.4.7 [tuple.helper]	Contradictory specification of `std::tuple_size`	No	3
3882⁽ⁱ⁾	New	22.4.9 [tuple.rel]	`tuple` relational operators have confused friendships	Yes	3
3728⁽ⁱ⁾	New	22.4.9 [tuple.rel]	Can't make neither head nor tail of the description of `operator<=>(tuple, tuple)`	Yes	4
2472⁽ⁱ⁾	New	22.4.9 [tuple.rel]	Heterogeneous comparisons in the standard library can result in ambiguities	No	3
532⁽ⁱ⁾	LEWG	22.4.9 [tuple.rel]	Tuple comparison	Yes		348
2990⁽ⁱ⁾	Open	22.5.3 [optional.optional]	`optional::value_type` is not always a value type	Yes	3
2811⁽ⁱ⁾	New	22.5.3.2 [optional.ctor]	"Selected constructor" wording is incorrect for `optional`/`variant`/`any`	Yes	3
2746⁽ⁱ⁾	New	22.5.3.4 [optional.assign]	Inconsistency between requirements for `emplace` between `optional` and `variant`	Yes	3
3424⁽ⁱ⁾	New	22.5.3.7 [optional.observe]	`optional::value_or` should never return a cv-qualified type	Yes	3
2829⁽ⁱ⁾	Open	22.5.3.7 [optional.observe]	LWG 2740 leaves behind vacuous words	No	2
4015⁽ⁱ⁾	Open	22.5.3.8 [optional.monadic]	LWG 3973 broke `const` overloads of `std::optional` monadic operations	Yes	1
3613⁽ⁱ⁾	New	22.5.4 [optional.nullopt]	Specify that `nullopt_t` is copyable	Yes	3
3627⁽ⁱ⁾	New	22.5.9 [optional.specalg]	Inconsistent specifications for `std::make_optional` overloads	Yes	3
2881⁽ⁱ⁾	New	22.6.3 [variant.variant]	Adopt section III of P0308R0	No	3
3215⁽ⁱ⁾	New	22.6.3.2 [variant.ctor]	`variant` default constructor has vague `constexpr` requirements	No	2
2833⁽ⁱ⁾	Open	22.6.3.2 [variant.ctor]	Library needs to specify what it means when it declares a function `constexpr`	Yes	2
2991⁽ⁱ⁾	LEWG	22.6.3.2 [variant.ctor]	`variant` copy constructor missing `noexcept(see below)`	Yes
3991⁽ⁱ⁾	New	22.6.3.4 [variant.assign]	`variant`'s move assignment should not be guaranteed to produce a valueless by exception state	Yes	3
3069⁽ⁱ⁾	New	22.6.3.4 [variant.assign]	Move assigning `variant`'s subobject corrupts data	Yes	3
3416⁽ⁱ⁾	New	22.7.4 [any.class]	The Throws: specification of `std::any` does not mention allocation	No	3
3423⁽ⁱ⁾	New	22.7.5 [any.nonmembers]	`std::any_cast` should never return a cv-qualified type	Yes	3
3688⁽ⁱ⁾	New	22.8.4 [expected.bad]	Exception specifications of copy/move member functions of `std::bad_expected_access`	No	2
3891⁽ⁱ⁾	New	22.8.6.1 [expected.object.general]	LWG 3870 breaks `std::expected<cv T, E>`	Yes	2
4026⁽ⁱ⁾	New	22.8.6.4 [expected.object.assign]	Assignment operators of `std::expected` should propagate triviality	Yes	2
2348⁽ⁱ⁾	Open	22.9.2 [template.bitset]	`charT('1')` is not the wide equivalent of `'1'`	Yes	3
3805⁽ⁱ⁾	New	22.10 [function.objects]	Expression evaluating to a call wrapper is a prvalue, not an object	No	4
4007⁽ⁱ⁾	New	22.10.4 [func.require]	Mystic prohibition of calling a `volatile`-qualified perfect forwarding call wrapper	Yes	3
3046⁽ⁱ⁾	New	22.10.6 [refwrap]	Do not require `reference_wrapper` to support non-referenceable function types	Yes	3
2491⁽ⁱ⁾	New	22.10.8 [comparisons]	`std::less<T*>` in constant expression	Yes	3
2547⁽ⁱ⁾	New	22.10.8 [comparisons]	Container requirements (and other library text) should say "strict total order", not just "total order"	No	3
3979⁽ⁱ⁾	New	22.10.13 [func.not.fn]	Should we reject `std::bind_front<42>()` and its friends?	Yes	4
3493⁽ⁱ⁾	New	22.10.17.3.2 [func.wrap.func.con]	The constructor of `std::function` taking an `F` is missing a constraint	Yes	3
3680⁽ⁱ⁾	New	22.10.17.4.3 [func.wrap.move.ctor]	Constructor of `move_only_function` with empty `ref`-qualifier is over-constrained	Yes	2
3642⁽ⁱ⁾	New	22.10.17.4.3 [func.wrap.move.ctor]	`move_only_function` assignment operators seem to be defined suboptimal	Yes	3
4127⁽ⁱ⁾	New	22.10.18.3 [func.search.bm]	The Standard Library should not use predicates of the form `pred(*i) != false`	Yes	3
3512⁽ⁱ⁾	New	22.10.19 [unord.hash]	Incorrect exception safety guarantee for unordered containers	No	3
3968⁽ⁱ⁾	New	22.11.8 [bit.endian]	`std::endian::native` value should be more specific about object representations	Yes	4

Section 23 (55 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
2307⁽ⁱ⁾	LEWG	23 [containers]	Should the Standard Library use `explicit` only when necessary?	No	2
2885⁽ⁱ⁾	LEWG	23 [containers]	The relational operators of `optional` and `variant` completely reflect the semantics of the element types — this is inconsistent with other types in the library	No
2884⁽ⁱ⁾	LEWG	23 [containers]	Relational operators for containers should sfinae; if the underlying type is not comparable, neither should the container be	No
3059⁽ⁱ⁾	New	23.2 [container.requirements]	Wrong requirements for map-like associative container assignment?	No	3
2269⁽ⁱ⁾	New	23.2.2 [container.requirements.general]	Container iterators and argument-dependent lookup	No	4
2321⁽ⁱ⁾	Open	23.2.2 [container.requirements.general]	Moving containers should (usually) be required to preserve iterators	Yes	3
1521⁽ⁱ⁾	Open	23.2.2 [container.requirements.general]	Requirements on internal pointer representations in containers	Yes	3
3976⁽ⁱ⁾	New	23.2.2.5 [container.alloc.reqmts]	What does it mean for a type to be "allocator aware"?	No
3297⁽ⁱ⁾	New	23.2.4 [sequence.reqmts]	Useless sequence container requirement	Yes	3
2705⁽ⁱ⁾	New	23.2.4 [sequence.reqmts]	Questionable precondition on Sequence containers `a.assign(n, t)`	Yes	3
2206⁽ⁱ⁾	Open	23.2.4 [sequence.reqmts]	Inaccuracy in `initializer_list` constructor requirements	Yes	3
4159⁽ⁱ⁾	New	23.2.5 [container.node]	Uses-allocator construction mechanisms should be opted out for node handles	Yes	3
3438⁽ⁱ⁾	New	23.2.5.1 [container.node.overview]	§[container.node.overview] missing `multiset`/`map` cases	No	3
3227⁽ⁱ⁾	New	23.2.7 [associative.reqmts]	Ambiguity issue for `extract` in ordered and unordered associative containers	Yes	3
2362⁽ⁱ⁾	New	23.2.7 [associative.reqmts]	unique, associative `emplace()` should not move/copy the `mapped_type` constructor arguments when no insertion happens	No	3
2844⁽ⁱ⁾	Open	23.2.7 [associative.reqmts]	Stability of `a_uniq.insert(i, j)`	No	3
2227⁽ⁱ⁾	Open	23.2.7 [associative.reqmts]	Stateful comparison objects in associative containers	No	3
2215⁽ⁱ⁾	Open	23.2.7 [associative.reqmts]	(unordered) associative container functors should be `CopyConstructible`	Yes	3
4132⁽ⁱ⁾	New	23.2.7.1 [associative.reqmts.general]	Throws specifications need to include `boolean-testable` operations	Yes	3
3577⁽ⁱ⁾	New	23.2.7.1 [associative.reqmts.general]	Merging an (unordered) associative container with itself	No	3
3691⁽ⁱ⁾	New	23.2.7.1 [associative.reqmts.general]	Replacement of keys in associative containers	Yes	3
3578⁽ⁱ⁾	New	23.2.7.1 [associative.reqmts.general]	Iterator SCARYness in the context of associative container merging	No	3
4046⁽ⁱ⁾	New	23.2.7.2 [associative.reqmts.except]	Effects of inserting into or erasing from flat container adaptors when an exception is thrown need to be more permissive	No	2
1175⁽ⁱ⁾	Open	23.2.8 [unord.req]	`unordered` complexity	Yes	3
2198⁽ⁱ⁾	Open	23.2.8 [unord.req]	`max_load_factor(z)` makes no strong guarantees, but bans useful behavior	Yes	3
2189⁽ⁱ⁾	Open	23.2.8.2 [unord.req.except]	Throwing `swap` breaks unordered containers' state	No	3
617⁽ⁱ⁾	Open	23.3.3 [array]	`std::array` is a sequence that doesn't satisfy the sequence requirements?	No	3
3219⁽ⁱ⁾	New	23.3.3.1 [array.overview]	`std::array` overview container requirements are incorrect	Yes	3
2823⁽ⁱ⁾	Open	23.3.3.1 [array.overview]	`std::array` initialization is still not permissive enough	Yes	3
3488⁽ⁱ⁾	Open	23.3.3.4 [array.special]	Is `array<const int, 0>` swappable or not?	Yes	3
2157⁽ⁱ⁾	Open	23.3.3.5 [array.zero]	How does `std::array<T,0>` initialization work when `T` is not default-constructible?	Yes	3
4123⁽ⁱ⁾	New	23.3.5.4 [deque.modifiers]	Container effects use "the assignment operator or move assignment operator"	No	3
3308⁽ⁱ⁾	New	23.3.5.4 [deque.modifiers]	`vector` and `deque` iterator `erase` invalidates elements even when no change occurs	Yes	3
3758⁽ⁱ⁾	New	23.3.11.3 [vector.capacity]	Element-relocating operations of `std::vector` and `std::deque` should conditionally require Cpp17CopyInsertable in their preconditions	No	3
2158⁽ⁱ⁾	Open	23.3.11.3 [vector.capacity]	Conditional copy/move in `std::vector`	Yes	3
1102⁽ⁱ⁾	Open	23.3.11.3 [vector.capacity]	`std::vector`'s reallocation policy still unclear	Yes	3
3638⁽ⁱ⁾	New	23.3.12 [vector.bool]	`vector<bool>::swap(reference, reference)` is useless	Yes	3
1422⁽ⁱ⁾	Open	23.3.12 [vector.bool]	`vector<bool>` iterators are not random access	No	3
4122⁽ⁱ⁾	New	23.3.14.1 [inplace.vector.overview]	Ill-formed `operator<=>` can cause hard error when instantiating `std::inplace_vector`	Yes	2
4151⁽ⁱ⁾	New	23.3.14.5 [inplace.vector.modifiers]	Precondition of `inplace_vector::swap`	Yes	2
3531⁽ⁱ⁾	New	23.4.3.1 [map.overview]	LWG 3025 broke previous valid code	Yes	3
2713⁽ⁱ⁾	New	23.5 [unord]	More missing allocator-extended constructors for unordered containers	Yes	3
3189⁽ⁱ⁾	New	23.6.4 [priority.queue]	Missing requirement for `std::priority_queue`	No	3
3161⁽ⁱ⁾	Open	23.6.6 [stack]	Container adapters mandate use of `emplace_back` but don't require it	Yes	3
3959⁽ⁱ⁾	New	23.6.8 [flat.map]	Should the comparator of `std::flat_map`/`std::flat_multimap` be copied twice in some operations?	No
3802⁽ⁱ⁾	New	23.6.8 [flat.map]	`flat_foo` allocator-extended constructors lack move semantics	No	2
3804⁽ⁱ⁾	New	23.6.8 [flat.map]	`flat_foo` missing some allocator-extended deduction guides	No	2
3966⁽ⁱ⁾	New	23.6.8.1 [flat.map.overview]	The `value_type` and `reference` members of `std::flat_(multi)map::(const_)iterator` are unclear	No	3
3963⁽ⁱ⁾	New	23.6.8.2 [flat.map.defn]	Different `std::flat_map`/`std::flat_multimap` specializations should be able to share same nested classes	Yes	3
4000⁽ⁱ⁾	New	23.6.8.7 [flat.map.modifiers]	`flat_map::insert_range`'s Effects is not quite right	Yes	3
4048⁽ⁱ⁾	New	23.6.11 [flat.set]	Inconsistent preconditions for transparent insertion of `std::flat_map/std::flat_set`	Yes	2
3813⁽ⁱ⁾	New	23.7.2.2.1 [span.overview]	`std::span<volatile T, E>` is made ill-formed by P2278R4 when `T` is a normal class type	No	2
3995⁽ⁱ⁾	New	23.7.3 [views.multidim]	Issue with custom index conversion in `<mdspan>`	No	3
4020⁽ⁱ⁾	New	23.7.3.3.2 [mdspan.extents.expo]	`extents::index-cast` weirdness	Yes
4021⁽ⁱ⁾	New	23.7.3.6.1 [mdspan.mdspan.overview]	`mdspan::is_always_meow()` should be `noexcept`	Yes

Section 24 (39 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3952⁽ⁱ⁾	New	24.2 [iterator.synopsis]	`iter_common_reference_t` does not conform to the definition of `indirectly_readable`	Yes	3
1213⁽ⁱ⁾	Open	24.3 [iterator.requirements]	Meaning of valid and singular iterator underspecified	No	4
4080⁽ⁱ⁾	New	24.3.2 [iterator.assoc.types]	Presumed value and difference types of an iterator type in ranges and non-ranges algorithms	No	3
3838⁽ⁱ⁾	New	24.3.2.1 [incrementable.traits]	The last specialization of `incrementable_traits` is under-constrained	Yes	3
3615⁽ⁱ⁾	New	24.3.2.1 [incrementable.traits]	The last specialization of `incrementable_traits` has wrong operand types	Yes	3
3287⁽ⁱ⁾	New	24.3.2.3 [iterator.traits]	Exposition-only `cpp17-input-iterator` concept is needlessly complex	Yes	3
3890⁽ⁱ⁾	New	24.3.4.4 [iterator.concept.winc]	ABI issue for integer-class types	Yes	3
3716⁽ⁱ⁾	New	24.3.4.11 [iterator.concept.forward]	§[iterator.concept.forward][forward.iterators] Two different definitions of multi-pass guarantee	No	3
484⁽ⁱ⁾	Open	24.3.5.3 [input.iterators]	Convertible to `T`	No	3
2962⁽ⁱ⁾	Open	24.3.5.3 [input.iterators]	Iterators of Containers of move-only types do not model `InputIterator`	Yes	2
2035⁽ⁱ⁾	Open	24.3.5.4 [output.iterators]	Output iterator requirements are broken	Yes	3
2038⁽ⁱ⁾	Open	24.3.5.4 [output.iterators]	Missing definition for `incrementable` iterator	No	3
4171⁽ⁱ⁾	New	24.3.6.3 [indirectcallable.indirectinvocable]	P2609R3 breaks code that uses `views::zip` and `get<T>`	No
3197⁽ⁱ⁾	New	24.4.3 [iterator.operations]	`std::prev` should not require `BidirectionalIterator`	Yes	3
4055⁽ⁱ⁾	New	24.4.3 [iterator.operations]	§[iterator.operations] `std::distance` is missing a precondition	Yes	4
3439⁽ⁱ⁾	New	24.4.3 [iterator.operations]	"`Distance`" template parameter is underspecified	No	3
3344⁽ⁱ⁾	New	24.4.3 [iterator.operations]	`advance(i, most-negative)` and `prev(i, most-negative)`	Yes	3
2931⁽ⁱ⁾	Open	24.4.3 [iterator.operations]	Missed optimization opportunity with single-argument `std::next`	No	3
2858⁽ⁱ⁾	New	24.5.1 [reverse.iterators]	LWG 2472: actually an incompatibility with C++03	Yes	4
3623⁽ⁱ⁾	New	24.5.1.1 [reverse.iterators.general]	Uses of `std::reverse_iterator` with containers should not require manually including `<iterator>`	Yes	3
2595⁽ⁱ⁾	New	24.5.1.2 [reverse.iterator]	`reverse_iterator::operator[]`'s return type revisited	Yes	3
3602⁽ⁱ⁾	New	24.5.1.4 [reverse.iter.cons]	`reverse_iterator`'s converting assignment is overconstrained	Yes	3
3725⁽ⁱ⁾	New	24.5.1.6 [reverse.iter.elem]	`reverse_iterator::operator->` should not use `prev` for non-pointer iterators	Yes	3
4104⁽ⁱ⁾	New	24.5.3 [const.iterators]	`basic_const_iterator<volatile int*>` is not a `contiguous_iterator`	No	4
3986⁽ⁱ⁾	New	24.5.3 [const.iterators]	`basic_const_iterator` doesn't work with `optional`	No	3
3988⁽ⁱ⁾	Open	24.5.3 [const.iterators]	Should `as_const_view` and `basic_const_iterator` provide `base()`?	Yes	3
3863⁽ⁱ⁾	New	24.5.3.2 [const.iterators.alias]	Is `input_iterator` guaranteed to have `iter_const_reference_t`?	No	2
4120⁽ⁱ⁾	New	24.5.4.2 [move.iterator]	`move_iterator` should provide `iterator_category` only when it models `forward_iterator`	Yes	3
4125⁽ⁱ⁾	New	24.5.4.2 [move.iterator]	`move_iterator`'s default constructor should be constrained	Yes	3
4115⁽ⁱ⁾	New	24.5.4.6 [move.iter.elem]	`move_iterator::operator*` should have conditional `noexcept` specification	Yes	4
4092⁽ⁱ⁾	New	24.5.5.1 [common.iterator]	The monotonic version of `common_iterator::operator==` is underconstrained	Yes	3
3783⁽ⁱ⁾	New	24.5.5.1 [common.iterator]	`views::common` may not be a range adaptor object	Yes	3
3748⁽ⁱ⁾	New	24.5.5.6 [common.iter.cmp]	`common_iterator` and `counted_iterator`' `operator-` are missing cast to return type	Yes	3
2366⁽ⁱ⁾	New	24.6.4 [istreambuf.iterator]	`istreambuf_iterator` end-of-stream equality	Yes	3
3107⁽ⁱ⁾	New	24.6.4 [istreambuf.iterator]	`istreambuf_iterator` has public exposition-only member	Yes	4
3188⁽ⁱ⁾	New	24.6.4 [istreambuf.iterator]	`istreambuf_iterator::pointer` should not be unspecified	Yes	3
3108⁽ⁱ⁾	New	24.6.4.2 [istreambuf.iterator.proxy]	`istreambuf_iterator::proxy::operator*` should be `const`	Yes	3
4131⁽ⁱ⁾	New	24.7 [iterator.range]	Including `<optional>` doesn't provide `std::begin/end`	Yes	3
3537⁽ⁱ⁾	New	24.7 [iterator.range]	§[iterator.range] Missing `noexcept` for `std::rbegin`/`rend` for arrays and `initializer_list`	No	3

Section 25 (55 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3729⁽ⁱ⁾	New	25.2 [ranges.syn]	`std::tuple_element_t<std::ranges::subrange<I, S, K>>` should remove top-level cv-qualifiers	Yes	4
4062⁽ⁱ⁾	New	25.3.12 [range.prim.empty]	`ranges::empty` has no semantic requirements for `forward_range`s	No
3896⁽ⁱ⁾	New	25.4.5 [range.refinements]	The definition of `viewable_range` is not quite right	Yes	4
4010⁽ⁱ⁾	New	25.5.4.3 [range.subrange.access]	`subrange::advance` should be improved	Yes	3
4121⁽ⁱ⁾	New	25.5.7.1 [range.utility.conv.general]	`ranges::to` constructs associative containers via `c.emplace(c.end(), *it)`	Yes	2
4066⁽ⁱ⁾	New	25.5.7.2 [range.utility.conv.to]	`ranges::to` should reserve when `sized_sentinel_for` is satisfied	Yes
4008⁽ⁱ⁾	New	25.5.7.2 [range.utility.conv.to]	§[range.utility.conv.to] `ranges::to` may cause infinite recursion if `range_value_t<C>` is a non-move-constructible range	Yes	3
4018⁽ⁱ⁾	New	25.5.7.2 [range.utility.conv.to]	`ranges::to`'s copy branch is underconstrained	Yes	3
3722⁽ⁱ⁾	New	25.5.7.2 [range.utility.conv.to]	`ranges::to` `reserve`s the wrong size	Yes	4
3845⁽ⁱ⁾	New	25.5.7.2 [range.utility.conv.to]	`ranges::to`'s `from_range_t` tag branch has the wrong constraint	Yes	4
3985⁽ⁱ⁾	New	25.5.7.2 [range.utility.conv.to]	`ranges::to` should Mandates `C` not to be view	Yes	3
3983⁽ⁱ⁾	New	25.5.7.3 [range.utility.conv.adaptors]	`ranges::to` adaptors are underconstrained	Yes	3
3907⁽ⁱ⁾	New	25.6 [range.factories]	Can iterator types of range adaptors and range factories be SCARY?	No	3
3614⁽ⁱ⁾	New	25.6.4.2 [range.iota.view]	`iota_view::size` and the most negative signed integer values	Yes	3
4002⁽ⁱ⁾	New	25.6.4.3 [range.iota.iterator]	The definition of `iota_view::iterator::iterator_concept` should be improved	Yes	3
3846⁽ⁱ⁾	New	25.6.4.3 [range.iota.iterator]	`iota_view::iterator::operator-` is overconstrained	Yes	3
3609⁽ⁱ⁾	New	25.6.4.4 [range.iota.sentinel]	`std::ranges::iota_view<int, long>` has non-subtractable `iterator` and `sentinel` types	Yes	3
3955⁽ⁱ⁾	New	25.6.5.2 [range.repeat.view]	Add `noexcept` to several `repeat_view[::iterator]` member functions	Yes	3
3763⁽ⁱ⁾	New	25.6.5.3 [range.repeat.iterator]	Should range adaptor iterators only provide `iterator_category` when its `difference_type` is not an integer-class type?	Yes	3
3679⁽ⁱ⁾	LEWG	25.6.6 [range.istream]	Is `<ranges>` sufficient for `istream_view`?	No	3
3489⁽ⁱ⁾	New	25.6.6.3 [range.istream.iterator]	Improve `istream_view` wording	Yes	3
3994⁽ⁱ⁾	New	25.7.2 [range.adaptor.object]	`adaptor(args...)(r)` is not equivalent to `std::bind_back(adaptor, args...)(r)`	No	4
4099⁽ⁱ⁾	New	25.7.7.1 [range.as.rvalue.overview]	The simple case of `views::as_rvalue` and `views::common` are not strictly correct	Yes	4
3829⁽ⁱ⁾	New	25.7.7.2 [range.as.rvalue.view]	`as_rvalue_view::end` should improve non-common case	Yes	3
4050⁽ⁱ⁾	New	25.7.10.1 [range.take.overview]	Should `views::iota(0) \| views::take(5)` be `views::iota(0, 5)`?	Yes
4009⁽ⁱ⁾	New	25.7.12.2 [range.drop.view]	`drop_view::begin const` may have 𝒪(n) complexity	Yes
3730⁽ⁱ⁾	New	25.7.12.2 [range.drop.view]	`std::ranges::drop_view` may have different size type from its underlying view	Yes	3
3666⁽ⁱ⁾	New	25.7.14 [range.join]	`join_view`'s difference type is too small	No	2
3873⁽ⁱ⁾	New	25.7.15.2 [range.join.with.view]	`join_with_view`'s `const begin` is underconstrained	No	3
4059⁽ⁱ⁾	New	25.7.15.3 [range.join.with.iterator]	Leaky abstraction in `join_with_view`'s iterator	Yes	3
3852⁽ⁱ⁾	New	25.7.15.3 [range.join.with.iterator]	`join_with_view::iterator`'s `iter_move` and `iter_swap` should be conditionally `noexcept`	Yes	3
3972⁽ⁱ⁾	New	25.7.15.3 [range.join.with.iterator]	Issues with `join_with_view::iterator`'s `iter_swap`	No	2
3855⁽ⁱ⁾	New	25.7.16.2 [range.lazy.split.view]	`tiny-range` is not quite right	Yes	4
3685⁽ⁱ⁾	New	25.7.16.2 [range.lazy.split.view]	In `lazy_split_view`, CTAD doesn't work when given an `input_range` input and a `tiny-range` pattern	Yes	3
3599⁽ⁱ⁾	New	25.7.16.2 [range.lazy.split.view]	The `const` overload of `lazy_split_view::begin` should be constrained by `const Pattern`	Yes	3
4108⁽ⁱ⁾	SG9	25.7.16.2 [range.lazy.split.view]	`lazy_split_view` should be `sized_range` when pattern is empty `tiny-range`	Yes	4
3686⁽ⁱ⁾	New	25.7.16.3 [range.lazy.split.outer]	In `lazy_split_view`, comparing a default-constructed `outer-iterator` or `inner-iterator` with `std::default_sentinel` results in null pointer dereference	Yes	3
4017⁽ⁱ⁾	New	25.7.17.3 [range.split.iterator]	Behavior of `std::views::split` on an empty range	Yes	3
4166⁽ⁱ⁾	New	25.7.18.2 [range.concat.view]	`concat_view::end()` should be more constrained in order to support noncopyable iterators	Yes
4073⁽ⁱ⁾	New	25.7.18.2 [range.concat.view]	`concat_view::size` may overflow	No	4
4091⁽ⁱ⁾	New	25.7.18.2 [range.concat.view]	`concat_view` rejects non-movable references	Yes	4
4081⁽ⁱ⁾	New	25.7.18.3 [range.concat.iterator]	`concat_view::iterator::operator-` is overconstrained	Yes	3
4089⁽ⁱ⁾	New	25.7.18.3 [range.concat.iterator]	`concat_view::iterator`'s `iter_swap` is overconstrained	Yes	3
4019⁽ⁱ⁾	SG9	25.7.21 [range.reverse]	Reversing an infinite range leads to an infinite loop	No	3
4097⁽ⁱ⁾	LEWG	25.7.21.1 [range.reverse.overview]	`views::reverse` should be specialized for some view types	Yes	3
3830⁽ⁱ⁾	New	25.7.21.2 [range.reverse.view]	`reverse_view` should not cache when `ranges::next` has constant time complexity	Yes	3
3797⁽ⁱ⁾	New	25.7.23.2 [range.elements.view]	`elements_view` insufficiently constrained	Yes	2
4114⁽ⁱ⁾	New	25.7.23.3 [range.elements.iterator]	`elements_view::iterator::operator*` missing conditional `noexcept` specification	Yes	3
3832⁽ⁱ⁾	New	25.7.23.3 [range.elements.iterator]	Missing change for `element_view::iterator` in LWG 3798	Yes	3
4116⁽ⁱ⁾	New	25.7.24.3 [range.enumerate.iterator]	`enumerate_view::iterator` and `cartesian_product_view::iterator` should not always provide `iterator_category`	Yes
3864⁽ⁱ⁾	New	25.7.25 [range.zip]	`zip` over range of reference to an abstract type	No	4
3731⁽ⁱ⁾	New	25.7.25.2 [range.zip.view]	`zip_view` and `adjacent_view` are underconstrained	Yes	3
3777⁽ⁱ⁾	Open	25.7.33.2 [range.cartesian.view]	Common `cartesian_product_view` produces an invalid range if the first range is input and one of the ranges is empty	Yes	2
4057⁽ⁱ⁾	New	25.8.6 [coro.generator.iterator]	`generator::iterator`'s `operator*` is not `noexcept` when it can be	Yes	3
4117⁽ⁱ⁾	New	25.8.6 [coro.generator.iterator]	`generator::iterator` should provide `iterator_concept`	Yes	4

Section 26 (31 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
2963⁽ⁱ⁾	New	26 [algorithms]	Algorithms with underspecified iterator requirements	No	3
1238⁽ⁱ⁾	Open	26 [algorithms]	Defining algorithms taking iterator for range	No	3
2173⁽ⁱ⁾	Open	26 [algorithms]	The meaning of `operator +` in the description of the algorithms	Yes	4
3049⁽ⁱ⁾	Open	26.2 [algorithms.requirements]	Missing wording allowing algorithms to use copies of function objects as substitutes for their parameters	Yes	3
3793⁽ⁱ⁾	New	26.6.5 [alg.foreach]	Requirements for some algorithms' `Size` template parameters are unclear	No	3
4093⁽ⁱ⁾	New	26.6.18 [alg.fold]	`ranges::fold_left_first_with_iter` incorrectly constructs `optional<U>`	Yes	3
4094⁽ⁱ⁾	New	26.6.18 [alg.fold]	`ranges::fold_meow` is overconstrained	Yes	3
3969⁽ⁱ⁾	New	26.6.18 [alg.fold]	`std::ranges::fold_left_first_with_iter` should be more ADL-proof	Yes	3
3089⁽ⁱ⁾	New	26.7.1 [alg.copy]	`copy_n` should require non-overlapping ranges	Yes	3
2471⁽ⁱ⁾	Open	26.7.1 [alg.copy]	`copy_n`'s number of `InputIterator` increments unspecified	No	3
3868⁽ⁱ⁾	LEWG	26.7.5 [alg.replace]	Constrained algorithms should not require `output_iterator`	Yes	4
4103⁽ⁱ⁾	New	26.7.9 [alg.unique]	`ranges::unique_copy`'s constraints for the case where `result` is an `input_iterator` are not quite right	Yes	3
2985⁽ⁱ⁾	LEWG	26.7.10 [alg.reverse]	`std::reverse` should be permitted to be vectorized	Yes
2267⁽ⁱ⁾	New	26.8.2.4 [partial.sort.copy]	`partial_sort_copy` underspecified for ranges of two different types	No	3
4162⁽ⁱ⁾	New	26.8.3 [alg.nth.element]	Worst time complexity of non-parallel versions of `nth_element` is underspecified	Yes	3
4111⁽ⁱ⁾	New	26.8.4 [alg.binary.search]	LWG 270 and ranges version of binary search algorithms	No	3
2973⁽ⁱ⁾	LEWG	26.8.6 [alg.merge]	`inplace_merge` exact comparison count complexity prohibits useful real-world optimizations	Yes
3534⁽ⁱ⁾	LEWG	26.8.7.4 [set.intersection]	`ranges::set_intersection` and `ranges::set_difference` algorithm requirements are too strict	Yes	3
3029⁽ⁱ⁾	Open	26.8.8.3 [pop.heap]	`pop_heap` over-constrains input	Yes	3
4167⁽ⁱ⁾	New	26.8.9 [alg.min.max]	Use of "smaller" and "larger" in `min`, `max`, and `minmax` is unclear	Yes
4034⁽ⁱ⁾	New	26.8.9 [alg.min.max]	Clarify specification of `std::min` and `std::max`	Yes	4
3487⁽ⁱ⁾	New	26.10 [numeric.ops]	Missing precondition on input and output aliasing of [numeric.ops]	No	3
3060⁽ⁱ⁾	New	26.10.8 [exclusive.scan]	`XXX_scan` algorithms are specified to work with move-only `T`, but are specified to make `N` copies of `T` into the destination range	No	2
3463⁽ⁱ⁾	New	26.10.11 [transform.inclusive.scan]	Incorrect requirements for `transform_inclusive_scan` without initial value	Yes	3
3628⁽ⁱ⁾	New	26.11 [specialized.algorithms]	"Effects: Equivalent to:" and uninitialized memory algorithms	No	3
3063⁽ⁱ⁾	New	26.11 [specialized.algorithms]	Parallel algorithms in `<memory>` are underspecified	No	3
3064⁽ⁱ⁾	New	26.11 [specialized.algorithms]	How do uninitialized memory algorithms obtain pointer without undefined behavior?	No	3
3647⁽ⁱ⁾	New	26.11.2 [special.mem.concepts]	`nothrow-input-iterator` constraints should not mention copying	Yes	3
3888⁽ⁱ⁾	New	26.11.8 [specialized.construct]	Most ranges uninitialized memory algorithms are underconstrained	Yes	3
3889⁽ⁱ⁾	New	26.11.9 [specialized.destroy]	`std::(ranges::)destroy_at` should destroy array elements in the decreasing index order	Yes	3
4077⁽ⁱ⁾	New	26.12.2 [alg.rand.generate]	Unclear preconditions of `std::ranges::generate_random`	No	2

Section 27 (18 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
2513⁽ⁱ⁾	New	27.1 [strings.general]	Missing requirements for `basic_string::value_type`	No	4
4152⁽ⁱ⁾	New	27.2.2 [char.traits.require]	The primary template of `std::char_traits` is totally underspecified	Yes
3694⁽ⁱ⁾	New	27.2.2 [char.traits.require]	Should `traits_type::length` be customizable?	No	4
3942⁽ⁱ⁾	New	27.2.4 [char.traits.specializations]	Inconsistent use of `const char_type&` in standard specializations of `std::char_traits`	Yes	3
4063⁽ⁱ⁾	New	27.2.4.2 [char.traits.specializations.char]	Freestanding `std::char_traits<char>::eof` depends on non-freestanding `EOF`	No	2
2959⁽ⁱ⁾	New	27.2.4.4 [char.traits.specializations.char16.t]	`char_traits<char16_t>::eof` is a valid UTF-16 code unit	No	3
3989⁽ⁱ⁾	New	27.3 [string.view]	The whole range for an iterator obtained from a `std::span` or `std::basic_string_view` is not clear	No	3
2883⁽ⁱ⁾	LEWG	27.3 [string.view]	The standard library should provide `string_view` parameters instead or in addition for functions defined with `char const *` or `string const &` as parameter types.	No
3457⁽ⁱ⁾	New	27.3.3 [string.view.template]	`*this` is not invalidated	Yes	3
4102⁽ⁱ⁾	New	27.3.3.2 [string.view.cons]	`string_view(Iter, Iter)` constructor breaks existing code	No	2
3339⁽ⁱ⁾	New	27.4.3 [basic.string]	Move-constructed empty-container capacity	No	3
3451⁽ⁱ⁾	New	27.4.3 [basic.string]	Inconsistently explicit deduction guides	Yes	3
4029⁽ⁱ⁾	New	27.4.3.1 [basic.string.general]	`basic_string` accidentally fails to meet the reversible container requirements	Yes	3
3663⁽ⁱ⁾	New	27.4.3.3 [string.cons]	`basic_string(const T&, const Alloc&)` turns moves into copies	Yes	3
3662⁽ⁱ⁾	New	27.4.3.7.2 [string.append]	`basic_string::append/assign(NTBS, pos, n)` suboptimal	Yes	3
3837⁽ⁱ⁾	New	27.4.4.5 [string.erasure]	`std::erase_if` overloads for non-associative containers should move (and not copy) their predicate object	Yes	3
2237⁽ⁱ⁾	New	27.5 [c.strings]	`<cuchar>` macros	No	4
2238⁽ⁱ⁾	Open	27.5 [c.strings]	Problematic iterator-pair constructor of containers	No	3

Section 28 (50 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3456⁽ⁱ⁾	New	28.2.3 [charconv.from.chars]	Pattern used by `std::from_chars` is underspecified	Yes	3
3081⁽ⁱ⁾	Open	28.2.3 [charconv.from.chars]	Floating point `from_chars` API does not distinguish between overflow and underflow	Yes	2
3082⁽ⁱ⁾	Open	28.2.3 [charconv.from.chars]	`from_chars` specification regarding floating point rounding is inconsistent	Yes	2
3353⁽ⁱ⁾	New	28.3.3.1 [locale]	`locale`'s copy assignment operator should return `locale&`	Yes	3
3674⁽ⁱ⁾	New	28.3.3.1.4 [locale.members]	Removal of requirement for locale names for construction of locales not explained	Yes	2
3337⁽ⁱ⁾	New	28.3.4.2.5.3 [locale.codecvt.virtuals]	What is "is initialized" supposed to mean?	No	3
4163⁽ⁱ⁾	New	28.3.4.3.2.3 [facet.num.get.virtuals]	Can the overload of `std::num_get::do_get` for `bool` call the overload for `long`?	No
3689⁽ⁱ⁾	New	28.3.4.3.2.3 [facet.num.get.virtuals]	`num_get` overflow determination unclear and incorrect	No	3
3214⁽ⁱ⁾	New	28.3.4.3.2.3 [facet.num.get.virtuals]	§[facet.num.get.virtuals] doesn't say what it means for digit grouping to be consistent	No	4
2703⁽ⁱ⁾	New	28.3.4.3.3.3 [facet.num.put.virtuals]	No provision for fill-padding when `boolalpha` is set	No	3
2702⁽ⁱ⁾	New	28.3.4.3.3.3 [facet.num.put.virtuals]	`num_put::do_put(..., bool)` performs ill-formed `do_put` call	No	3
2117⁽ⁱ⁾	Open	28.3.4.3.3.3 [facet.num.put.virtuals]	`ios_base` manipulators should have `showgrouping/noshowgrouping`	No	3
3275⁽ⁱ⁾	New	28.3.4.6.2.3 [locale.time.get.virtuals]	Why does `time_get::do_get` require a valid pointer when none of the others do?	Yes	3
2512⁽ⁱ⁾	Open	28.3.4.6.2.3 [locale.time.get.virtuals]	Y2K bites; what is an "unambiguous year identifier"?	No	4
2983⁽ⁱ⁾	New	28.3.4.7.3.3 [locale.money.put.virtuals]	`money_put::do_put` underspecified	Yes	3
2691⁽ⁱ⁾	New	28.3.4.7.4 [locale.moneypunct]	`money_base::space` and `do_put`: U+0020 versus `fill`	Yes	3
3651⁽ⁱ⁾	New	28.5 [format]	Unspecified lifetime guarantees for the format string	No	3
3997⁽ⁱ⁾	New	28.5.1 [format.syn]	`std::formatter` specializations should be consistently restricted to supported character types	No	4
3641⁽ⁱ⁾	New	28.5.1 [format.syn]	Add `operator==` to `format_to_n_result`	Yes	3
3939⁽ⁱ⁾	New	28.5.2.2 [format.string.std]	§[format.string.std] `char` is not formatted as a character when `charT` is `wchar_t`	No	3
3644⁽ⁱ⁾	New	28.5.2.2 [format.string.std]	`std::format` does not define "integer presentation type"	Yes	2
3586⁽ⁱ⁾	New	28.5.2.2 [format.string.std]	Formatting character alignment inconsistencies	Yes	2
4090⁽ⁱ⁾	SG16	28.5.2.2 [format.string.std]	Underspecified use of locale facets for locale-dependent `std::format`	No	3
4078⁽ⁱ⁾	New	28.5.5 [format.functions]	What if arguments alias the output buffer in `std::format_to`?	No
3993⁽ⁱ⁾	New	28.5.6.1 [formatter.requirements]	The `parse` function of a BasicFormatter type needs to be `constexpr`	Yes	3
3943⁽ⁱ⁾	New	28.5.6.3 [format.formattable]	Clarify lifetime requirements of BasicFormatter and Formatter	Yes	3
4146⁽ⁱ⁾	New	28.5.6.4 [format.formatter.spec]	§[format.formatter.spec]/3 unconditionally enables nonlocking for container adaptors	Yes
3706⁽ⁱ⁾	New	28.5.6.4 [format.formatter.spec]	How does `std::format` work with character arrays of unknown bound?	No	3
4107⁽ⁱ⁾	New	28.5.7.4 [format.range.fmtmap]	Map formatter may conflict with user-defined specializations of `pair`/`tuple` formatters	Yes
2490⁽ⁱ⁾	New	28.6 [re]	`<regex>` needs lots of `noexcept`	No	3
523⁽ⁱ⁾	Open	28.6 [re]	regex case-insensitive character ranges are unimplementable as specified	No	4
3835⁽ⁱ⁾	New	28.6.1 [re.general]	Requirements for `CharT` in the regex library	No	4
3606⁽ⁱ⁾	New	28.6.2 [re.req]	Missing `regex_traits::locale_type` requirements	No	3
2431⁽ⁱ⁾	New	28.6.2 [re.req]	Missing regular expression traits requirements	No	3
3998⁽ⁱ⁾	New	28.6.4 [re.const]	Constants in `std::regex_constants` should be allowed to be enumerators	No	3
2331⁽ⁱ⁾	Open	28.6.4.2 [re.synopt]	`regex_constants::collate`'s effects are inaccurately summarized	Yes	3
3605⁽ⁱ⁾	New	28.6.4.3 [re.matchflag]	`regex_constants::match_prev_avail` is underspecified	No	3
2338⁽ⁱ⁾	Open	28.6.6 [re.traits]	§[re.traits]/7 expects of locale facets something not guaranteed by [locale.facet]/4	Yes	3
3261⁽ⁱ⁾	New	28.6.7 [re.regex]	`regex` components' `noexcept` annotations appear broken for POCMA or throwing `BidirectionalIterator`	No	3
3341⁽ⁱ⁾	New	28.6.7.2 [re.regex.construct]	`basic_regex` range constructor: Missing requirements for iterator types	No	3
3630⁽ⁱ⁾	New	28.6.7.2 [re.regex.construct]	Inconsistent `basic_regex` construction and assignment from iterator range	No	4
3603⁽ⁱ⁾	New	28.6.7.2 [re.regex.construct]	Matching of null characters by regular expressions is underspecified	No	3
3604⁽ⁱ⁾	New	28.6.7.2 [re.regex.construct]	What is the effect of an invalid value of type `syntax_option_type`?	No	3
2137⁽ⁱ⁾	Open	28.6.7.3 [re.regex.assign]	Misleadingly constrained post-condition in the presence of exceptions	Yes	3
3126⁽ⁱ⁾	New	28.6.8 [re.submatch]	There's no `std::sub_match::compare(string_view)` overload	Yes	3
2216⁽ⁱ⁾	New	28.6.10.4 [re.alg.replace]	`regex_replace(basic_string)` allocator handling	No	3
2220⁽ⁱ⁾	Open	28.6.11.2.3 [re.tokiter.comp]	Under-specification of `operator==` for `regex_token_iterator`	Yes	3
2546⁽ⁱ⁾	New	28.6.12 [re.grammar]	Implementability of locale-sensitive UnicodeEscapeSequence matching	No	4
2986⁽ⁱ⁾	New	28.6.12 [re.grammar]	Handling of multi-character collating elements by the `regex` FSM is underspecified	No	4
2987⁽ⁱ⁾	New	28.6.12 [re.grammar]	Relationship between `traits_inst.lookup_collatename` and the `regex` FSM is underspecified with regards to `ClassAtomCollatingElement`	No	3

Section 29 (19 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
4161⁽ⁱ⁾	New	29.4 [complex.numbers]	Some free functions don't automatically work for program-defined `std::complex<NonFloatingPoint>`	No
3933⁽ⁱ⁾	New	29.4.3 [complex]	P1467R9 accidentally changed the signatures of certain constructors of `std::complex`	Yes	4
3934⁽ⁱ⁾	New	29.4.3 [complex]	`std::complex<T>::operator=(const T&)` has no specification	Yes	3
2714⁽ⁱ⁾	New	29.4.6 [complex.ops]	`complex` stream extraction underspecified	Yes	3
2846⁽ⁱ⁾	New	29.4.10 [cmplx.over]	Undefined phrase "effectively cast"	Yes	3
4109⁽ⁱ⁾	New	29.5.3.1 [rand.req.genl]	Instantiating templates in §[rand] with `int8_t`/`uint8_t` is undefined behavior	Yes
3402⁽ⁱ⁾	New	29.5.9.3.4 [rand.dist.bern.negbin]	Wording for `negative_binomial_distribution` is unclear as a consequence of LWG 2406 resolution	No	3
4052⁽ⁱ⁾	New	29.5.9.6.2 [rand.dist.samp.pconst]	Bogus requirements for `piecewise_linear_distribution`	No	4
3964⁽ⁱ⁾	New	29.6.3.3 [valarray.transcend]	`std::atan2` and `std::pow` overloads that take two `std::valarray` parameters should require the arguments to have the same length	Yes	4
2423⁽ⁱ⁾	New	29.6.5 [template.slice.array]	Missing specification `slice_array`, `gslice_array`, `mask_array`, `indirect_array` copy constructor	Yes	4
2115⁽ⁱ⁾	Open	29.6.8 [template.mask.array]	Undefined behaviour for `valarray` assignments with `mask_array` index?	No	4
3693⁽ⁱ⁾	New	29.7 [c.math]	§[c.math] Can any of `float/double/long double` overloads be fused into template overloads?	No	2
2847⁽ⁱ⁾	New	29.7.1 [cmath.syn]	`sin(float)` should call `sinf(float)`	No	3
2923⁽ⁱ⁾	New	29.7.1 [cmath.syn]	`noexcept` is inconsistently applied across headers which import components of the C standard library	No	4
3093⁽ⁱ⁾	New	29.7.2 [c.math.abs]	LWG 2294/2192 missed a `std::abs` overload	No	3
3172⁽ⁱ⁾	New	29.7.3 [c.math.hypot3]	3-arg `std::hypot` is underspecified compared to the 2-arg overload	Yes	3
3066⁽ⁱ⁾	New	29.7.6 [sf.cmath]	"report a domain error" in [sf.cmath]/1 is underspecified	No	3
4136⁽ⁱ⁾	New	29.9.3 [linalg.general]	Specify behavior of [linalg] Hermitian algorithms on diagonal with nonzero imaginary part	Yes
4137⁽ⁱ⁾	New	29.9.14 [linalg.algs.blas2]	Fix Mandates, Preconditions, and Complexity elements of [linalg] algorithms	Yes

Section 30 (17 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
2592⁽ⁱ⁾	New	30.2 [time.syn]	Require that `chrono::duration_cast`s from smaller durations to larger durations do not overflow	Yes	4
3090⁽ⁱ⁾	New	30.5.2 [time.duration.cons]	What is §[time.duration.cons]p4's "no overflow is induced in the conversion" intended to mean?	Yes	3
3503⁽ⁱ⁾	New	30.5.8 [time.duration.cast]	`chrono::ceil` has surprising requirement	Yes	3
2383⁽ⁱ⁾	Open	30.5.9 [time.duration.literals]	Overflow cannot be ill-formed for chrono::duration integer literals	No	3
3678⁽ⁱ⁾	New	30.11.5.1 [time.zone.overview]	Constructors of `std::chrono::time_zone` might be overly unspecified	No	4
4067⁽ⁱ⁾	New	30.11.7.2 [time.zone.zonedtime.ctor]	Inconsistency and potential infinity meta-recursion in `std::chrono::zoned_time`'s constructors	Yes	3
4139⁽ⁱ⁾	New	30.11.8 [time.zone.leap]	§[time.zone.leap] recursive constraint in `<=>`	No	3
4118⁽ⁱ⁾	New	30.12 [time.format]	How should `duration` formatters format custom `rep` types?	Yes	3
4022⁽ⁱ⁾	New	30.12 [time.format]	Ambiguity in the formatting of negative years with format specifier `%C`	Yes
3856⁽ⁱ⁾	New	30.12 [time.format]	Unclear which conversion specifiers are valid for each chrono type	Yes	3
3921⁽ⁱ⁾	New	30.12 [time.format]	Is `std::chrono::duration<std::int64_t, std::ratio<INT64_MAX - 1, INT64_MAX>>{40}` required to be correctly formatted?	No	3
3831⁽ⁱ⁾	New	30.12 [time.format]	Two-digit formatting of negative `year` is ambiguous	Yes	3
3844⁽ⁱ⁾	Open	30.12 [time.format]	Non-numeric formats for negative durations	Yes	3
3962⁽ⁱ⁾	New	30.13 [time.parse]	What is the "decimal precision of the input"?	Yes	3
3960⁽ⁱ⁾	New	30.13 [time.parse]	How does `chrono::parse` handle duplicated data?	Yes	3
3961⁽ⁱ⁾	New	30.13 [time.parse]	Does `chrono::parse` check format strings?	Yes	3
3956⁽ⁱ⁾	New	30.13 [time.parse]	`chrono::parse` uses `from_stream` as a customization point	No	3

Section 31 (33 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
423⁽ⁱ⁾	Open	31 [input.output]	Effects of negative `streamsize` in iostreams	Yes	3
3696⁽ⁱ⁾	New	31.2.2 [stream.types]	"Basic integral types" should not be used	No	3
3910⁽ⁱ⁾	New	31.4.2 [iostream.objects.overview]	The effects of including `<iostream>` on initialization are not yet precisely specified	Yes	4
3675⁽ⁱ⁾	New	31.5.2.6 [ios.base.storage]	`std::ios_base::iword/pword` might be misspecified	Yes	4
2675⁽ⁱ⁾	New	31.5.2.7 [ios.base.callback]	`register_callback` can fail	No	3
2214⁽ⁱ⁾	Open	31.5.4.2 [basic.ios.cons]	Clarify `basic_ios::init` call restrictions	Yes	4
2504⁽ⁱ⁾	New	31.6.3 [streambuf]	`basic_streambuf` is not an abstract class	No	3
3658⁽ⁱ⁾	New	31.6.3.3.5 [streambuf.pub.put]	`basic_streambuf::sputn` is both overspecified and underspecified	Yes	3
2342⁽ⁱ⁾	New	31.7.6.2 [ostream]	User conversion to `wchar_t const*` or to `wchar_t` not invoked for `operator<<`	Yes	4
2497⁽ⁱ⁾	New	31.7.6.2.4 [ostream.sentry]	Use of `uncaught_exception()`	Yes	3
4101⁽ⁱ⁾	New	31.7.6.3.2 [ostream.inserters.arithmetic]	LWG 117 loses the sign for negative NaN on some architectures	Yes	3
4039⁽ⁱ⁾	New	31.7.6.3.5 [ostream.formatted.print]	§[ostream.formatted.print]: Inappropriate usage of `badbit` in definition of `vprint_unicode`/`vprint_nonunicode`	Yes
3501⁽ⁱ⁾	New	31.7.6.5 [ostream.manip]	`basic_syncbuf`-related manipulators refer to some `Allocator` without defining it	Yes	3
3937⁽ⁱ⁾	New	31.7.7 [std.manip]	I/O manipulators should be specified in terms of base classes	No	3
2984⁽ⁱ⁾	New	31.7.8 [ext.manip]	`put_money(99)` is unnecessarily undefined	Yes	3
4042⁽ⁱ⁾	LEWG	31.7.10 [print.fun]	`std::print` should permit an efficient implementation	Yes	3
3309⁽ⁱ⁾	New	31.8 [string.streams]	Is `<ios>` implicitly `#include`d by `<sstream>`, `<fstream>` etc.?	No	3
3992⁽ⁱ⁾	New	31.8.2.4 [stringbuf.members]	`basic_stringbuf::str()&&` should enforce 𝒪(1)	Yes
3097⁽ⁱ⁾	New	31.8.2.5 [stringbuf.virtuals]	`basic_stringbuf seekoff` effects trigger undefined behavior and have contradictory returns	No	3
2286⁽ⁱ⁾	Open	31.8.2.5 [stringbuf.virtuals]	`stringbuf::underflow()` underspecified	Yes	4
3496⁽ⁱ⁾	New	31.11.2.4 [syncstream.syncbuf.members]	What does "uniquely associated" mean for `basic_syncbuf::emit()`?	No	3
3497⁽ⁱ⁾	New	31.11.2.4 [syncstream.syncbuf.members]	Postconditions for `basic_syncbuf::emit()`	No	3
3098⁽ⁱ⁾	New	31.12.6.5.9 [fs.path.decompose]	Misleading example for `filesystem::path::filename()`	Yes	3
3699⁽ⁱ⁾	New	31.12.6.5.11 [fs.path.gen]	`lexically_relative` on UNC drive paths (`\\?\C:\...`) results in a default-constructed value	No	3
3794⁽ⁱ⁾	New	31.12.6.6 [fs.path.itr]	`std::filesystem::path::iterator::reference` should be allowed to be `std::filesystem::path`	Yes	3
4070⁽ⁱ⁾	SG16	31.12.6.9.2 [fs.path.fmtr.funcs]	Transcoding by `std::formatter<std::filesystem::path>`	Yes	2
2947⁽ⁱ⁾	New	31.12.8.1 [fs.enum.path.format]	Clarify several filesystem terms	No	3
3078⁽ⁱ⁾	New	31.12.10 [fs.class.directory.entry]	`directory_entry`, `directory_iterator` and `recursive_directory_iterator` perform needless path copies	No	3
3668⁽ⁱ⁾	New	31.12.11.2 [fs.dir.itr.members]	`[recursive_]directory_iterator` constructors refer to undefined `options`	Yes	3
2708⁽ⁱ⁾	Open	31.12.12.2 [fs.rec.dir.itr.members]	`recursive_directory_iterator::recursion_pending()` is incorrectly specified	Yes	2
3057⁽ⁱ⁾	Open	31.12.13.4 [fs.op.copy]	Correct `copy_options` handling	Yes	2
3056⁽ⁱ⁾	New	31.12.13.5 [fs.op.copy.file]	`copy_file()` copies which attributes?	Yes	3
3744⁽ⁱ⁾	New	31.12.13.6 [fs.op.copy.symlink]	`copy_symlink(junction, new_symlink)`'s behavior is unclear	No	3

Section 32 (40 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
2819⁽ⁱ⁾	New	32.2.5 [thread.req.lockable]	Unspecified Return type: elements	Yes	3
3499⁽ⁱ⁾	New	32.2.5.4 [thread.req.lockable.timed]	Timed lockable and mutex requirements are imprecise about `duration` and `time_point`	No	3
3924⁽ⁱ⁾	New	32.3.1 [thread.stoptoken.intro]	Stop token data race avoidance requirements unclear	Yes	3
1484⁽ⁱ⁾	LEWG	32.4.3 [thread.thread.class]	Need a way to join a thread with a timeout	No
3516⁽ⁱ⁾	New	32.4.3.2 [thread.thread.id]	`thread::id` spaceship may be inconsistent with equality	Yes	3
3475⁽ⁱ⁾	New	32.4.3.3 [thread.thread.constr]	`std::thread`'s constructor needs to be able to report general memory allocation failures	Yes	3
3633⁽ⁱ⁾	New	32.5 [atomics]	Atomics are copy constructible and copy assignable from `volatile` atomics	Yes	3
3220⁽ⁱ⁾	New	32.5.2 [atomics.syn]	P0558 broke conforming C++14 uses of atomic `shared_ptr`	Yes	3
2236⁽ⁱ⁾	SG1	32.5.2 [atomics.syn]	`kill_dependency` unconditionally noexcept	No
3999⁽ⁱ⁾	New	32.5.4 [atomics.order]	P0439R0 changed the value category of memory order constants	Yes	4
3268⁽ⁱ⁾	New	32.5.4 [atomics.order]	`memory_order::memory_order_foo` broken in C++20	Yes	4
2265⁽ⁱ⁾	Open	32.5.4 [atomics.order]	29.3p9 appears to rule out some acceptable executions	No	4
1459⁽ⁱ⁾	LEWG	32.5.4 [atomics.order]	Overlapping evaluations are allowed	No		1458
4004⁽ⁱ⁾	SG1	32.5.4 [atomics.order]	The load and store operation in §[atomics.order] p1 is ambiguous	No	3
3941⁽ⁱ⁾	SG1	32.5.4 [atomics.order]	§[atomics.order] inadvertently prohibits widespread implementation techniques	No	3
3263⁽ⁱ⁾	New	32.5.6 [atomics.wait]	Atomic waiting function calls should only be unblocked once	Yes	3
3288⁽ⁱ⁾	New	32.5.6 [atomics.wait]	`atomic<T>::notify_one` is unimplementable	Yes	2
3508⁽ⁱ⁾	Open	32.5.7.1 [atomics.ref.generic.general]	`atomic_ref<cv T>` is not well-specified	No	2
3409⁽ⁱ⁾	New	32.5.7.2 [atomics.ref.ops]	Too lax description of `atomic_ref<T>::required_alignment`	Yes	3
4069⁽ⁱ⁾	Open	32.5.8 [atomics.types.generic]	`std::atomic<volatile T>` should be ill-formed	No	2
3417⁽ⁱ⁾	SG1	32.5.8.2 [atomics.types.operations]	Missing `volatile` atomic deprecations	Yes	3
3047⁽ⁱ⁾	New	32.5.8.3 [atomics.types.int]	`atomic` compound assignment operators can cause undefined behavior when corresponding `fetch_meow` members don't	Yes	3
3906⁽ⁱ⁾	New	32.5.8.5 [atomics.types.pointer]	"Undefined address" is undefined	No	3
3418⁽ⁱ⁾	New	32.5.9 [atomics.nonmembers]	Deprecated free functions in `<atomic>`	Yes	3
1488⁽ⁱ⁾	LEWG	32.6 [thread.mutex]	Improve interoperability between the C++0x and C1x threads APIs	No
936⁽ⁱ⁾	LEWG	32.6.4 [thread.mutex.requirements]	Mutex type overspecified	No		961
961⁽ⁱ⁾	LEWG	32.6.4 [thread.mutex.requirements]	Various threading bugs #11	No		936
1493⁽ⁱ⁾	LEWG	32.6.4 [thread.mutex.requirements]	Add `mutex`, `recursive_mutex`, `is_locked` function	No
4172⁽ⁱ⁾	New	32.6.5.4.2 [thread.lock.unique.cons]	unique_lock self-move-assignment is broken	Yes
3343⁽ⁱ⁾	Open	32.7.3 [thread.condition.nonmember]	Ordering of calls to `unlock()` and `notify_all()` in Effects element of `notify_all_at_thread_exit()` should be reversed	Yes	3
3504⁽ⁱ⁾	New	32.7.4 [thread.condition.condvar]	`condition_variable::wait_for` is overspecified	Yes	3
3898⁽ⁱ⁾	New	32.9.3.3 [thread.barrier.class]	Possibly unintended preconditions for completion functions of `std::barrier`	Yes	3
2530⁽ⁱ⁾	Open	32.10.5 [futures.state]	Clarify observable side effects of releasing a shared state	No	3
2532⁽ⁱ⁾	Open	32.10.6 [futures.promise]	Satisfying a `promise` at thread exit	Yes	3
3003⁽ⁱ⁾	LEWG	32.10.6 [futures.promise]	`<future>` still has type-erased allocators in `promise`	Yes	2
2095⁽ⁱ⁾	LEWG	32.10.6 [futures.promise]	`promise` and `packaged_task` missing constructors needed for uses-allocator construction	Yes	4
3582⁽ⁱ⁾	New	32.10.9 [futures.async]	Unclear where `std::async` exceptions are handled	Yes	3
2202⁽ⁱ⁾	Deferred	32.10.9 [futures.async]	Missing allocator support by `async`	No	4
4160⁽ⁱ⁾	New	32.10.10.1 [futures.task.general]	`packaged_task` should reject rvalue reference return types	Yes
4158⁽ⁱ⁾	New	32.10.10.2 [futures.task.members]	`packaged_task::operator=` should abandon its shared state	Yes	3

Section 33 (3 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
4143⁽ⁱ⁾	New	33.7.2 [exec.set.value]	`execution::set_value/set_error/set_stopped/start` should always return `void`	Yes	2
4150⁽ⁱ⁾	New	33.11.1.4 [exec.run.loop.members]	The preconditions on `run_loop::run()` are too strict	Yes
4133⁽ⁱ⁾	New	33.12.1 [exec.as.awaitable]	`awaitable-receiver`'s members are potentially throwing	No	1

Section 99 (7 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
2479⁽ⁱ⁾	New	99 [depr.conversions.buffer]	Unclear how `wbuffer_convert` uses `cvtstate`	No	4
2480⁽ⁱ⁾	New	99 [depr.conversions.buffer]	Error handling of `wbuffer_convert` unclear	No	4
2478⁽ⁱ⁾	New	99 [depr.conversions.string]	Unclear how `wstring_convert` uses `cvtstate`	No	4
2481⁽ⁱ⁾	New	99 [depr.conversions.string]	`wstring_convert` should be more precise regarding "byte-error string" etc.	No	4
2507⁽ⁱ⁾	New	99 [depr.locale.stdcvt]	`codecvt_mode` should be a bitmask type	No	3
3109⁽ⁱ⁾	New	99 [depr.strstreambuf]	`strstreambuf` is copyable	No	4
3095⁽ⁱ⁾	New	99 [depr.strstreambuf.virtuals]	`strstreambuf` refers to nonexistent member of `fpos`, `fpos::offset`	Yes	4

Section D (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3840⁽ⁱ⁾	Open	D.21 [depr.fs.path.factory]	`filesystem::u8path` should be undeprecated	Yes	3

Section concurr.ts 99 (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
2533⁽ⁱ⁾	SG1	99 [concurr.ts::futures.unique.future]	[concurr.ts] Constrain threads where `future::then` can run a continuation	No

Section fund.ts.v3 6 (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3812⁽ⁱ⁾	New	6.1.2.6 [fund.ts.v3::propagate_const.const_observers]	[fund.ts.v3] Incorrect constraint on `propagate_const` conversion function	Yes	3

Section fund.ts.v3 8 (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3167⁽ⁱ⁾	Open	8.2 [fund.ts.v3::memory.observer.ptr]	[fund.ts.v3] Does `observer_ptr` support function types?	No	3

Section fund.ts.v3 99 (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3357⁽ⁱ⁾	Open	99 [fund.ts.v3::rand.util.randint]	[fund.ts.v3] `default_random_engine` is overspecified for per-thread engine	Yes	3

Section networking.ts 13 (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3124⁽ⁱ⁾	New	13.7.5 [networking.ts::async.exec.ctx.globals]	[networking.ts] Unclear how `execution_context` is intended to store services	Yes	3

Section networking.ts 16 (4 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority
3114⁽ⁱ⁾	LEWG	16 [networking.ts::buffer]	[networking.ts] Permit efficient composition when using `DynamicBuffer`	Yes
3021⁽ⁱ⁾	New	16.2.2 [networking.ts::buffer.reqmts.constbuffersequence]	[networking.ts] Relax pointer equivalence requirement for `ConstBufferSequence`	Yes	3
3027⁽ⁱ⁾	New	16.2.4 [networking.ts::buffer.reqmts.dynamicbuffer]	[networking.ts] `DynamicBuffer` `prepare` exception specification	Yes	3
3072⁽ⁱ⁾	New	16.2.4 [networking.ts::buffer.reqmts.dynamicbuffer]	[networking.ts] `DynamicBuffer` object lifetimes underspecified	Yes	3

Section networking.ts 17 (1 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3073⁽ⁱ⁾	New	17 [networking.ts::buffer.stream]	[networking.ts] (`async_`)`read` and (`async_`)`write` don't support `DynamicBuffer` lvalues	Yes	3

Section networking.ts 19 (2 issues)

(view only non-Ready open issues)

Issue	Status	Section	Title	Proposed Resolution	Priority	Duplicates
3444⁽ⁱ⁾	New	19.1.2 [networking.ts::socket.streambuf.members]	[networking.ts] `net::basic_socket_streambuf::connect(Args&&...)` effects are wrong	No	2
3445⁽ⁱ⁾	LEWG	19.2.1 [networking.ts::socket.iostream.cons]	[networking.ts] `net::basic_socket_istream::connect` should be constrained	Yes	3