# C++ Standard Library Issues List (Revision R122)

# Index by Section

Reference ISO/IEC IS 14882:2011(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 2022-03-04 at 14:55:46 UTC

## Section 2 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
571(i) | NAD Editorial | 2 [intro.refs] | Update C90 references to C99? | Yes |  |
653(i) | NAD | 2 [intro.refs] | Library reserved names | Yes |  |

## Section 3 (5 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2872(i) | C++17 | 3 [intro.defs] | Add definition for direct-non-list-initialization | Yes |  |
1354(i) | C++11 | 3.15 [defns.deadlock] | The definition of deadlock excludes cases involving a single thread | Yes |  |
2392(i) | New | 3.36 [defns.ntcts] | "character type" is used but not defined | No | 3 |
3119(i) | C++20 | 3.42 [defns.prog.def.spec] | Program-definedness of closure types | Yes | 2 |
3513(i) | New | 3.43 [defns.prog.def.type] | Fix definition of program-defined based on its uses | Yes | 3 |

## Section 4 (1 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3669(i) | New | 4.1.2 [intro.abstract] | `std::filesystem` operations should be observable behaviour | No | 3 |

## Section 6 (4 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
873(i) | NAD Editorial | 6.8.2 [basic.fundamental] | signed integral type and unsigned integral type are not clearly defined | Yes |  |
2506(i) | SG1 | 6.9.2 [intro.multithread] | Underspecification of atomics | No | 3 |
2075(i) | Resolved | 6.9.2 [intro.multithread] | Progress guarantees, lock-free property, and scheduling assumptions | Yes |  |
462(i) | NAD | 6.9.3.4 [basic.start.term] | Destroying objects with static storage duration | Yes |  |

## Section 16 (199 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3105(i) | New | 16 [library] | `T1` is convertible to `T2` | No | 3 |
2949(i) | New | 16 [library] | Unclear complexity requirements: space vs. time | No | 4 |
1195(i) | C++11 | 16 [library] | "Diagnostic required" wording is insufficient to prevent UB | Yes |  |
1349(i) | C++11 | 16 [library] | `swap` should not throw | Yes |  |
182(i) | CD1 | 16 [library] | Ambiguous references to size_t | Yes |  |
230(i) | CD1 | 16 [library] | Assignable specified without also specifying CopyConstructible | Yes |  |
336(i) | CD1 | 16 [library] | Clause 17 lack of references to deprecated headers | Yes |  |
2925(i) | Resolved | 16 [library] | Template argument deduction is not used in the standard library | Yes |  |
343(i) | Resolved | 16 [library] | Unspecified library header dependencies | Yes |  |
625(i) | Resolved | 16 [library] | Mixed up Effects and Returns clauses | Yes |  | 895
1151(i) | Resolved | 16 [library] | Behavior of the library in the presence of threads is incompletely specified | Yes |  |
1344(i) | Resolved | 16 [library] | Replace `throw()` with `noexcept` | Yes |  | 1351
1345(i) | Resolved | 16 [library] | Library classes should have `noexcept` move operations | Yes |  |
1346(i) | Resolved | 16 [library] | Apply `noexcept` where library specification does not permit exceptions | Yes |  | 1352
1347(i) | Resolved | 16 [library] | Apply `noexcept` judiciously throughout the library | Yes |  |
1353(i) | Resolved | 16 [library] | Clarify the state of a moved-from object | Yes |  |
972(i) | NAD Editorial | 16 [library] | The term "Assignable" undefined but still in use | Yes |  |
1232(i) | NAD Editorial | 16 [library] | Still `swap`'s with rvalue-references | Yes |  |
877(i) | NAD | 16 [library] | to `throw()` or to Throw: Nothing. | Yes |  |
2898(i) | NAD | 16 [library] | Prefer not to use member typedefs as constructor parameters | Yes |  |
2865(i) | NAD | 16 [library] | Resolve all open Library issues for C++17 | Yes |  |
1173(i) | NAD | 16 [library] | "Equivalence" wishy-washiness | Yes | 3 |
385(i) | NAD | 16 [library] | Does call by value imply the CopyConstructible requirement? | Yes |  |
941(i) | NAD | 16 [library] | Ref-qualifiers for assignment operators | Yes |  |
996(i) | NAD | 16 [library] | Move operation not well specified | Yes |  |
1099(i) | NAD | 16 [library] | Various issues | Yes |  |
1153(i) | NAD | 16 [library] | Standard library needs review for constructors to be explicit to avoid treatment as initializer-list constructor | Yes |  |
1236(i) | NAD | 16 [library] | reserved identifiers in programs not using the library | Yes |  |
1331(i) | NAD | 16 [library] | incorporate move special member functions into library | Yes |  |
1348(i) | NAD | 16 [library] | Exception safety of unspecified types | Yes |  |
1350(i) | Dup | 16 [library] | Implicit contructors accidentally made some library types move-only | Yes |  | 1421
1351(i) | Dup | 16 [library] | Replace dynamic exception specifications with `noexcept` | Yes |  | 1344
1352(i) | Dup | 16 [library] | Apply `noexcept` where library specification says "Throws: Nothing" | Yes |  | 1346
989(i) | NAD Concepts | 16 [library] | late_check and library | Yes |  |
1001(i) | NAD Concepts | 16 [library] | Pointers, concepts and headers | Yes |  |
1096(i) | NAD Concepts | 16 [library] | unconstrained rvalue ref parameters | Yes |  |
3538(i) | New | 16.2 [library.c] | §[library.c] C library functions are not addressable | No | 2 |
2136(i) | Open | 16.3.2 [structure] | Postconditions vs. exceptions | No | 3 |
424(i) | NAD Editorial | 16.3.2.2 [structure.summary] | normative notes | Yes |  |
3556(i) | New | 16.3.2.3 [structure.requirements] | Specification of when semantic constraints are imposed by use of concepts is unclear | No | 3 |
995(i) | NAD | 16.3.2.3 [structure.requirements] | Operational Semantics Unclear | Yes |  |
3193(i) | New | 16.3.2.4 [structure.specifications] | Mandates: and Expects: elements are not defined for types | Yes | 3 |
3401(i) | New | 16.3.2.4 [structure.specifications] | Is "as if by" equivalent to "equivalent to"? | No | 3 |
2679(i) | C++17 | 16.3.2.4 [structure.specifications] | Inconsistent Use of Effects and Equivalent To | Yes | 3 |
2710(i) | C++17 | 16.3.2.4 [structure.specifications] | "Effects: Equivalent to ..." doesn't count "Synchronization:" as determined semantics | Yes | 0 |
997(i) | C++11 | 16.3.2.4 [structure.specifications] | "Effects: Equivalent to" is underspecified | Yes |  |
222(i) | TC1 | 16.3.2.4 [structure.specifications] | Are throw clauses necessary if a throw is already implied by the effects clause? | Yes |  |
3168(i) | Resolved | 16.3.2.4 [structure.specifications] | Expects: element should be specified in one place | Yes | 2 |
2292(i) | Resolved | 16.3.2.4 [structure.specifications] | Find a better phrasing for "shall not participate in overload resolution" | Yes | 3 |
626(i) | NAD Editorial | 16.3.2.4 [structure.specifications] | new Remark clauses not documented | Yes |  |
1179(i) | NAD Editorial | 16.3.2.4 [structure.specifications] | Probably editorial in [structure.specifications] | Yes |  |
492(i) | NAD | 16.3.2.4 [structure.specifications] | Invalid iterator arithmetic expressions | Yes |  |
663(i) | NAD | 16.3.2.4 [structure.specifications] | Complexity Requirements | Yes |  |
895(i) | Dup | 16.3.2.4 [structure.specifications] | "Requires:" on std::string::at et al | Yes |  | 625
2999(i) | Resolved | 16.3.3.2 [expos.only.func] | §[thread.decaycopy] issue | Yes | 3 |
1156(i) | NAD | 16.3.3.3.3 [enumerated.types] | Constraints on bitmask and enumeration types to be tightened | Yes |  |
3092(i) | Open | 16.3.3.3.4 [bitmask.types] | Unclear semantics of `enum class` bitmask types | Yes | 3 |
262(i) | CD1 | 16.3.3.3.4 [bitmask.types] | Bitmask operator ~ specified incorrectly | Yes |  |
1357(i) | Resolved | 16.3.3.3.4 [bitmask.types] | Library bitmask types to not satisfy the bimask type requirements | Yes |  |
2692(i) | NAD | 16.3.3.3.4 [bitmask.types] | Overspecification of lvalueness of bitmask elements | Yes | 3 |
3620(i) | New | 16.3.3.3.5.1 [character.seq.general] | What are execution character sets and execution wide-character sets (after P2314R4)? | No | 3 |
1060(i) | NAD Editorial | 16.3.3.3.5.2 [byte.strings] | Embedded nulls in NTBS | Yes |  |
3285(i) | C++20 | 16.3.3.3.6 [customization.point.object] | The type of a customization point object shall satisfy `semiregular` | Yes | 0 |
3510(i) | Resolved | 16.3.3.3.6 [customization.point.object] | Customization point objects should be invocable as non-`const` too | Yes | 3 |
2818(i) | WP | 16.4.2.2 [contents] | `"::std::"` everywhere rule needs tweaking | Yes | 2 |
1065(i) | C++11 | 16.4.2.2 [contents] | Allow inline namespaces within namespace `std` for implementations | Yes |  |
229(i) | CD1 | 16.4.2.2 [contents] | Unqualified references of other library entities | Yes |  |
992(i) | NAD | 16.4.2.2 [contents] | Allow implementations to implement C library in the global namespace | Yes |  |
2380(i) | C++17 | 16.4.2.3 [headers] | May `<cstdlib>` provide `long ::abs(long)` and `long long ::abs(long long)`? | Yes | 2 |
310(i) | CD1 | 16.4.2.3 [headers] | Is errno a macro? | Yes |  |
456(i) | CD1 | 16.4.2.3 [headers] | Traditional C header files are overspecified | Yes |  |
465(i) | CD1 | 16.4.2.3 [headers] | Contents of <ciso646> | Yes |  |
1002(i) | NAD | 16.4.2.3 [headers] | Provide bulk include headers | Yes |  |
3148(i) | C++20 | 16.4.2.4 [compliance] | `<concepts>` should be freestanding | Yes | 0 |
1264(i) | C++11 | 16.4.2.4 [compliance] | `quick_exit` support for freestanding implementations | Yes |  |
1360(i) | C++11 | 16.4.2.4 [compliance] | Add `<atomic>` to free-standing implementations | Yes |  |
833(i) | NAD | 16.4.2.4 [compliance] | Freestanding implementations header list needs review for C++0x | Yes |  |
1003(i) | NAD | 16.4.2.4 [compliance] | Require more useful headers for freestanding implementations | Yes |  |
1358(i) | NAD | 16.4.2.4 [compliance] | Add `<chrono>` and `<ratio>` to freestanding implementations | Yes |  |
1359(i) | NAD | 16.4.2.4 [compliance] | Add `<tuple>` and `<utility>` to freestanding implementations | Yes |  |
1361(i) | NAD | 16.4.3 [using] | Does use of `std::size_t` in a header imply that typedef name is available to users? | Yes |  |
3240(i) | New | 16.4.3.2 [using.headers] | Headers declare more than entities | No | 3 |
2428(i) | C++17 | 16.4.3.2 [using.headers] | "External declaration" used without being defined | Yes | 0 |
2225(i) | C++14 | 16.4.3.2 [using.headers] | Unrealistic header inclusion checks required | Yes |  |
657(i) | NAD | 16.4.3.2 [using.headers] | unclear requirement about header inclusion | Yes |  |
1(i) | TC1 | 16.4.3.3 [using.linkage] | C library linkage editing oversight | Yes |  |
2281(i) | NAD Editorial | 16.4.3.3 [using.linkage] | C99 cross-reference typo in [using.linkage] | Yes |  |
3640(i) | New | 16.4.4 [utility.requirements] | Clarify which exceptions are propagated | Yes | 3 |
2146(i) | Open | 16.4.4.2 [utility.arg.requirements] | Are reference types `Copy`/`Move-Constructible`/`Assignable` or `Destructible`? | No | 3 |
2170(i) | C++17 | 16.4.4.2 [utility.arg.requirements] | Aggregates cannot be `DefaultConstructible` | Yes | 2 |
724(i) | C++11 | 16.4.4.2 [utility.arg.requirements] | `DefaultConstructible` is not defined | Yes |  |
753(i) | C++11 | 16.4.4.2 [utility.arg.requirements] | Move constructor in draft | Yes |  |
1309(i) | C++11 | 16.4.4.2 [utility.arg.requirements] | Missing expressions for `Move/CopyConstructible` | Yes |  |
672(i) | CD1 | 16.4.4.2 [utility.arg.requirements] | Swappable requirements need updating | Yes |  |
594(i) | Resolved | 16.4.4.2 [utility.arg.requirements] | Disadvantages of defining `Swappable` in terms of `CopyConstructible` and `Assignable` | Yes |  |
742(i) | Resolved | 16.4.4.2 [utility.arg.requirements] | Enabling `swap` for proxy iterators | Yes |  |
1283(i) | Resolved | 16.4.4.2 [utility.arg.requirements] | `MoveConstructible` and `MoveAssignable` need clarification of moved-from state | Yes |  |
1322(i) | Resolved | 16.4.4.2 [utility.arg.requirements] | Explicit `CopyConstructible` requirements are insufficient | Yes |  |
390(i) | NAD Editorial | 16.4.4.2 [utility.arg.requirements] | CopyConstructible requirements too strict | Yes |  |
822(i) | NAD | 16.4.4.2 [utility.arg.requirements] | Object with explicit copy constructor no longer `CopyConstructible` | Yes |  |
1374(i) | NAD | 16.4.4.2 [utility.arg.requirements] | Clarify moved-from objects are "toxic" | Yes |  |
910(i) | NAD Concepts | 16.4.4.2 [utility.arg.requirements] | Effects of MoveAssignable | Yes |  |
2152(i) | LEWG | 16.4.4.3 [swappable.requirements] | Instances of standard container types are not swappable | Yes | 3 |
2171(i) | NAD | 16.4.4.3 [swappable.requirements] | "swappable" undefined for swapping lvalue and rvalue | Yes |  |
2114(i) | Open | 16.4.4.4 [nullablepointer.requirements] | Incorrect "contextually convertible to `bool`" requirements | Yes | 3 |
2291(i) | C++14 | 16.4.4.5 [hash.requirements] | `std::hash` is vulnerable to collision DoS attack | Yes |  |
1332(i) | C++11 | 16.4.4.5 [hash.requirements] | Let Hash objects throw! | Yes |  |
3267(i) | New | 16.4.4.6 [allocator.requirements] | Rebound allocators and `is_always_equal` | Yes | 4 |
3157(i) | New | 16.4.4.6 [allocator.requirements] | Allocator `destroy` and fancy pointer operations must be non-throwing | Yes | 3 |
3044(i) | New | 16.4.4.6 [allocator.requirements] | Strange specification of `max_size()` for an allocator | Yes | 3 |
2461(i) | New | 16.4.4.6 [allocator.requirements] | Interaction between allocators and container exception safety guarantees | No | 3 |
2178(i) | Pending NAD Editorial | 16.4.4.6 [allocator.requirements] | `Allocator` requirement changes not mentioned Annex C | Yes | 3 |
2593(i) | C++20 | 16.4.4.6 [allocator.requirements] | Moved-from state of Allocators | Yes | 4 |
3315(i) | C++20 | 16.4.4.6 [allocator.requirements] | Correct Allocator Default Behavior | Yes | 0 |
2016(i) | C++17 | 16.4.4.6 [allocator.requirements] | `Allocators` must be no-throw swappable | Yes | 2 |
2260(i) | C++17 | 16.4.4.6 [allocator.requirements] | Missing requirement for `Allocator::pointer` | Yes | 3 |
2384(i) | C++17 | 16.4.4.6 [allocator.requirements] | Allocator's `deallocate` function needs better specification | Yes | 3 |
2447(i) | C++17 | 16.4.4.6 [allocator.requirements] | Allocators and `volatile`-qualified value types | Yes | 4 |
2455(i) | C++17 | 16.4.4.6 [allocator.requirements] | Allocator default construction should be allowed to throw | Yes |  |
2466(i) | C++17 | 16.4.4.6 [allocator.requirements] | `allocator_traits::max_size()` default behavior is incorrect | Yes | 3 |
2467(i) | C++17 | 16.4.4.6 [allocator.requirements] | `is_always_equal` has slightly inconsistent default | Yes | 0 |
2470(i) | C++17 | 16.4.4.6 [allocator.requirements] | Allocator's `destroy` function should be allowed to fail to instantiate | Yes |  |
2065(i) | C++14 | 16.4.4.6 [allocator.requirements] | Minimal allocator interface | Yes |  |
2081(i) | C++14 | 16.4.4.6 [allocator.requirements] | `Allocator` requirements should include `CopyConstructible` | Yes |  |
2147(i) | C++14 | 16.4.4.6 [allocator.requirements] | Unclear hint type in `Allocator`'s `allocate` function | Yes |  |
2162(i) | C++14 | 16.4.4.6 [allocator.requirements] | `allocator_traits::max_size` missing `noexcept` | Yes |  |
2263(i) | C++14 | 16.4.4.6 [allocator.requirements] | Comparing iterators and allocator pointers with different const-character | Yes | 1 |
752(i) | C++11 | 16.4.4.6 [allocator.requirements] | Allocator complexity requirement | Yes |  |
258(i) | CD1 | 16.4.4.6 [allocator.requirements] | Missing allocator requirement | Yes |  |
274(i) | CD1 | 16.4.4.6 [allocator.requirements] | a missing/impossible allocator requirement | Yes |  |
401(i) | CD1 | 16.4.4.6 [allocator.requirements] | incorrect type casts in table 32 in lib.allocator.requirements | Yes |  |
402(i) | CD1 | 16.4.4.6 [allocator.requirements] | wrong new expression in [some_]allocator::construct | Yes |  |
199(i) | TC1 | 16.4.4.6 [allocator.requirements] | What does `allocate(0)` return? | Yes |  |
2108(i) | Resolved | 16.4.4.6 [allocator.requirements] | No way to identify allocator types that always compare equal | Yes | 3 |
431(i) | Resolved | 16.4.4.6 [allocator.requirements] | Swapping containers with unequal allocators | Yes |  |
635(i) | Resolved | 16.4.4.6 [allocator.requirements] | domain of `allocator::address` | Yes |  |
12(i) | NAD | 16.4.4.6 [allocator.requirements] | Way objects hold allocators unclear | Yes |  |
197(i) | NAD | 16.4.4.6 [allocator.requirements] | max_size() underspecified | Yes |  |
277(i) | NAD | 16.4.4.6 [allocator.requirements] | Normative encouragement in allocator requirements unclear | Yes |  |
487(i) | NAD | 16.4.4.6 [allocator.requirements] | Allocator::construct is too limiting | Yes |  |
560(i) | NAD | 16.4.4.6 [allocator.requirements] | User-defined allocators without default constructor | Yes |  |
1376(i) | NAD | 16.4.4.6 [allocator.requirements] | Allocator interface is not backward compatible | Yes |  |
2311(i) | NAD | 16.4.4.6 [allocator.requirements] | Allocator requirements should be further minimized | Yes | 2 |
1375(i) | Dup | 16.4.4.6 [allocator.requirements] | `reference_type` should not have been removed from the allocator requirements | Yes |  | 1318
2954(i) | C++20 | 16.4.5 [constraints] | Specialization of the convenience variable templates should be prohibited | Yes |  |
3177(i) | New | 16.4.5.2.1 [namespace.std] | Limit permission to specialize variable templates to program-defined types | Yes | 3 |
3441(i) | Open | 16.4.5.2.1 [namespace.std] | Misleading note about calls to customization points | Yes | 1 |
3442(i) | Open | 16.4.5.2.1 [namespace.std] | Unsatisfiable suggested implementation of customization points | Yes | 1 |
2139(i) | C++20 | 16.4.5.2.1 [namespace.std] | What is a user-defined type? | Yes | 4 |
2129(i) | C++17 | 16.4.5.2.1 [namespace.std] | User specializations of `std::initializer_list` | Yes | 3 |
1157(i) | C++11 | 16.4.5.2.1 [namespace.std] | Local types can now instantiate templates | Yes |  |
3550(i) | New | 16.4.5.3 [reserved.names] | Names reserved by C for standard library not reserved by C++ | No | 3 |
120(i) | CD1 | 16.4.5.3 [reserved.names] | Can an implementor add specializations? | Yes |  |
226(i) | CD1 | 16.4.5.3 [reserved.names] | User supplied specializations or overloads of namespace std function templates | Yes |  |
232(i) | CD1 | 16.4.5.3 [reserved.names] | "depends" poorly defined in 17.4.3.1 | Yes |  |
422(i) | CD1 | 16.4.5.3 [reserved.names] | explicit specializations of member functions of class templates | Yes |  |
3132(i) | C++20 | 16.4.5.3.3 [macro.names] | Library needs to ban macros named `expects` or `ensures` | Yes | 0 |
3147(i) | C++20 | 16.4.5.3.3 [macro.names] | Definitions of "likely" and "unlikely" are likely to cause problems | Yes | 0 |
2014(i) | C++11 | 16.4.5.3.3 [macro.names] | More restrictions on macro names | Yes |  |
294(i) | CD1 | 16.4.5.3.3 [macro.names] | User defined macros and standard headers | Yes |  |
2340(i) | C++17 | 16.4.5.6 [replacement.functions] | Replacement allocation functions declared as inline | Yes | 2 |
404(i) | CD1 | 16.4.5.6 [replacement.functions] | May a replacement allocation function be declared inline? | Yes |  |
3142(i) | New | 16.4.5.8 [res.on.functions] | `std::foo<incomplete>` should be ill-formed NDR | Yes | 3 |
1004(i) | C++11 | 16.4.5.8 [res.on.functions] | Clarify "throws an exception" | Yes |  |
611(i) | CD1 | 16.4.5.8 [res.on.functions] | Standard library templates and incomplete types | Yes |  |
3511(i) | New | 16.4.5.9 [res.on.arguments] | Clarify global permission to move | Yes | 3 |
2468(i) | C++17 | 16.4.5.9 [res.on.arguments] | Self-move-assignment of library types | Yes | 2 |
1362(i) | C++11 | 16.4.5.9 [res.on.arguments] | Description of binding to rvalue-references should use the new 'xvalue' vocabulary | Yes |  |
1204(i) | C++11 | 16.4.5.9 [res.on.arguments] | Global permission to move | Yes |  |
2224(i) | C++17 | 16.4.5.10 [res.on.objects] | Ambiguous status of access to non-live objects | Yes | 2 |
1095(i) | C++11 | 16.4.5.10 [res.on.objects] | Shared objects and the library wording unclear | Yes |  |
3429(i) | New | 16.4.5.11 [res.on.requirements] | "models" should subsume like "satisfies" | Yes | 3 |
2112(i) | C++14 | 16.4.6 [conforming] | User-defined classes that cannot be derived from | Yes | 1 |
2891(i) | NAD | 16.4.6 [conforming] | Relax library requirements on `volatile` types | Yes |  |
94(i) | NAD | 16.4.6 [conforming] | May library implementors add template parameters to Standard Library classes? | Yes |  |
2113(i) | NAD | 16.4.6 [conforming] | Do library implementers have the freedom to add `final` to non-polymorphic components? | Yes |  |
2373(i) | NAD | 16.4.6 [conforming] | Make new entities and names in namespace `std` conforming extensions | Yes | 3 |
1178(i) | C++11 | 16.4.6.2 [res.on.headers] | Header dependencies | Yes |  |
2133(i) | C++17 | 16.4.6.4 [global.functions] | Attitude to overloaded comma for iterators | Yes | 3 |
2795(i) | C++17 | 16.4.6.4 [global.functions] | §[global.functions] provides incorrect example of ADL use | Yes |  |
225(i) | CD1 | 16.4.6.4 [global.functions] | std:: algorithms use of other unqualified algorithms | Yes |  |
147(i) | TC1 | 16.4.6.4 [global.functions] | Library Intro refers to global functions that aren't global | Yes |  |
2930(i) | NAD | 16.4.6.4 [global.functions] | Are implementations allowed to split non-member functions into several overloads? | Yes |  |
2695(i) | New | 16.4.6.5 [member.functions] | "As if" unclear in [member.functions] | No | 3 |
2259(i) | C++17 | 16.4.6.5 [member.functions] | Issues in 17.6.5.5 rules for member functions | Yes | 3 |
2563(i) | NAD | 16.4.6.5 [member.functions] | LWG 2259 relaxes requirements, perhaps unintentionally | Yes | 2 |
95(i) | NAD | 16.4.6.5 [member.functions] | Members added by the implementation | Yes |  |
2013(i) | C++14 | 16.4.6.7 [constexpr.functions] | Do library implementers have the freedom to add `constexpr`? | Yes |  |
2892(i) | NAD | 16.4.6.7 [constexpr.functions] | Relax the prohibition on libraries adding `constexpr` | Yes | 1 |
2044(i) | C++14 | 16.4.6.8 [algorithm.stable] | No definition of "Stable" for copy algorithms | Yes |  |
2414(i) | Open | 16.4.6.9 [reentrancy] | Member function reentrancy should be implementation-defined | Yes | 3 |
2382(i) | Pending NAD | 16.4.6.9 [reentrancy] | Unclear order of container update versus object destruction on removing an object | Yes | 2 |
1526(i) | Resolved | 16.4.6.10 [res.on.data.races] | C++ should not impose thread safety requirements on C99 library implementations | Yes | 3 |
2866(i) | C++17 | 16.4.6.12 [derivation] | Incorrect derived classes constraints | Yes |  |
3229(i) | New | 16.4.6.13 [res.on.exception.handling] | §[res.on.exception.handling]#3 cannot apply to types with implicitly declared destructors | Yes | 3 |
119(i) | TC1 | 16.4.6.13 [res.on.exception.handling] | Should virtual functions be allowed to strengthen the exception specification? | Yes |  |
2867(i) | Resolved | 16.4.6.13 [res.on.exception.handling] | Bad footnote about explicit exception-specification | Yes |  |
372(i) | NAD | 16.4.6.13 [res.on.exception.handling] | Inconsistent description of stdlib exceptions | Yes |  |
2839(i) | WP | 16.4.6.15 [lib.types.movedfrom] | Self-move-assignment of library types, again | Yes | 2 |

## Section 17 (134 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
1066(i) | C++11 | 17 [support] | Use `[[noreturn]]` attribute in the library | Yes |  |
2709(i) | C++17 | 17.2 [support.types] | `offsetof` is unnecessarily imprecise | Yes | 2 |
1097(i) | C++11 | 17.2 [support.types] | #define __STDCPP_THREADS | Yes |  |
1363(i) | C++11 | 17.2 [support.types] | `offsetof` should be marked `noexcept` | Yes |  |
306(i) | CD1 | 17.2 [support.types] | offsetof macro and non-POD types | Yes |  |
449(i) | CD1 | 17.2 [support.types] | Library Issue 306 Goes Too Far | Yes |  |
1314(i) | NAD | 17.2 [support.types] | `NULL` and `nullptr` | Yes |  |
2251(i) | NAD | 17.2 [support.types] | C++ library should define `ssize_t` | Yes | 3 |
2950(i) | C++20 | 17.2.5 [support.types.byteops] | `std::byte` operations are misspecified | Yes | 1 |
201(i) | CD1 | 17.3 [support.limits] | Numeric limits terminology wrong | Yes |  |
3217(i) | New | 17.3.1 [support.limits.general] | `<memory>` and `<execution>` should define `__cpp_lib_parallel_algorithm` | Yes | 3 |
3122(i) | C++20 | 17.3.1 [support.limits.general] | `__cpp_lib_chrono_udls` was accidentally dropped | Yes | 0 |
3137(i) | C++20 | 17.3.1 [support.limits.general] | Header for `__cpp_lib_to_chars` | Yes | 0 |
3256(i) | C++20 | 17.3.1 [support.limits.general] | Feature testing macro for `constexpr` algorithms | Yes | 0 |
3257(i) | C++20 | 17.3.1 [support.limits.general] | Missing feature testing macro update from P0858 | Yes | 0 |
3274(i) | C++20 | 17.3.1 [support.limits.general] | Missing feature test macro for `<span>` | Yes | 0 |
3635(i) | New | 17.3.2 [version.syn] | Add `__cpp_lib_deduction_guides` to feature test macros | Yes | 3 |
3621(i) | WP | 17.3.2 [version.syn] | Remove feature-test macro `__cpp_lib_monadic_optional` | Yes |  |
3437(i) | WP | 17.3.2 [version.syn] | `__cpp_lib_polymorphic_allocator` is in the wrong header | Yes | 0 |
3348(i) | C++20 | 17.3.2 [version.syn] | `__cpp_lib_unwrap_ref` in wrong header | Yes | 2 |
3349(i) | C++20 | 17.3.2 [version.syn] | Missing `__cpp_lib_constexpr_complex` for P0415R1 | Yes | 0 |
3356(i) | C++20 | 17.3.2 [version.syn] | `__cpp_lib_nothrow_convertible` should be `__cpp_lib_is_nothrow_convertible` | Yes | 0 |
3393(i) | C++20 | 17.3.2 [version.syn] | Missing/incorrect feature test macro for coroutines | Yes | 0 |
2248(i) | New | 17.3.5 [numeric.limits] | `numeric_limits::is_iec559` misnamed | No | 4 |
2730(i) | Open | 17.3.5 [numeric.limits] | `numeric_limits` primary template definition | No | 3 |
559(i) | CD1 | 17.3.5 [numeric.limits] | numeric_limits<const T> | Yes |  |
902(i) | NAD Concepts | 17.3.5 [numeric.limits] | Regular is the wrong concept to constrain numeric_limits | Yes |  |
1005(i) | NAD Concepts | 17.3.5 [numeric.limits] | `numeric_limits` partial specializations not concept enabled | Yes |  |
2422(i) | C++17 | 17.3.5.2 [numeric.limits.members] | `std::numeric_limits<T>::is_modulo` description: "most machines" errata | Yes | 2 |
497(i) | CD1 | 17.3.5.2 [numeric.limits.members] | meaning of numeric_limits::traps for floating point types | Yes |  |
612(i) | CD1 | 17.3.5.2 [numeric.limits.members] | numeric_limits::is_modulo insufficiently defined | Yes |  |
591(i) | NAD Editorial | 17.3.5.2 [numeric.limits.members] | Misleading "built-in | Yes |  |
205(i) | NAD | 17.3.5.2 [numeric.limits.members] | numeric_limits unclear on how to determine floating point types | Yes |  |
184(i) | CD1 | 17.3.5.3 [numeric.special] | numeric_limits<bool> wording problems | Yes |  |
613(i) | CD1 | 17.3.5.3 [numeric.special] | max_digits10 missing from numeric_limits | Yes |  |
554(i) | NAD | 17.3.5.3 [numeric.special] | Problem with lwg DR 184 numeric_limits<bool> | Yes |  |
416(i) | CD1 | 17.3.6 [climits.syn] | definitions of XXX_MIN and XXX_MAX macros in climits | Yes |  |
2820(i) | WP | 17.4 [cstdint] | Clarify `<cstdint>` macros | Yes | 3 |
593(i) | CD1 | 17.4 [cstdint] | __STDC_CONSTANT_MACROS | Yes |  |
557(i) | NAD Editorial | 17.4 [cstdint] | TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t) | Yes |  |
3370(i) | New | 17.4.2 [cstdint.syn] | §[cstdint.syn]p2 and §[headers]p5 are not sufficiently clear | No | 3 |
553(i) | NAD Editorial | 17.4.2 [cstdint.syn] | very minor editorial change `intptr_t` / `uintptr_t` | Yes |  |
841(i) | NAD Editorial | 17.4.2 [cstdint.syn] | cstdint.syn inconsistent with C99 | Yes |  |
2764(i) | Dup | 17.4.2 [cstdint.syn] | Are `<cstddint>` macros optional? | Yes | 3 |
2815(i) | New | 17.5 [support.start.term] | `quick_exit` can deadlock | Yes | 3 |
3084(i) | New | 17.5 [support.start.term] | Termination in C++ is unclear | No | 3 |
993(i) | C++11 | 17.5 [support.start.term] | `_Exit` needs better specification | Yes |  |
1144(i) | C++11 | 17.5 [support.start.term] | "thread safe" is undefined | Yes |  |
3(i) | TC1 | 17.5 [support.start.term] | Atexit registration during atexit() call is not described | Yes |  |
2458(i) | C++17 | 17.6 [support.dynamic] | N3778 and new library deallocation signatures | Yes | 2 |
2510(i) | C++17 | 17.6 [support.dynamic] | Tag types should not be `DefaultConstructible` | Yes | 2 |
3106(i) | NAD | 17.6.2 [new.syn] | `nothrow` should be `inline constexpr` rather that `extern const` | Yes | 2 |
2425(i) | C++17 | 17.6.3 [new.delete] | `operator delete(void*, size_t)` doesn't invalidate pointers sufficiently | Yes | 0 |
1006(i) | C++11 | 17.6.3 [new.delete] | `operator delete` in garbage collected implementation | Yes |  |
9(i) | TC1 | 17.6.3 [new.delete] | Operator new(0) calls should not yield the same pointer | Yes |  |
2368(i) | Resolved | 17.6.3 [new.delete] | Replacing global `operator new` | Yes | 2 |
3086(i) | New | 17.6.3.2 [new.delete.single] | Possible problem in §[new.delete.single] | Yes | 3 |
2737(i) | New | 17.6.3.2 [new.delete.single] | Consider relaxing object size restrictions for single-object allocation functions | No | 3 |
206(i) | CD1 | 17.6.3.2 [new.delete.single] | operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced | Yes |  |
319(i) | CD1 | 17.6.3.2 [new.delete.single] | Storage allocation wording confuses "Required behavior", "Requires" | Yes |  |
627(i) | NAD | 17.6.3.2 [new.delete.single] | Low memory and exceptions | Yes |  |
298(i) | CD1 | 17.6.3.3 [new.delete.array] | ::operator delete[] requirement incorrect/insufficient | Yes |  |
2303(i) | New | 17.6.3.4 [new.delete.placement] | Explicit instantiation of `std::vector<UserType>` broken? | No | 3 |
2302(i) | Pending NAD | 17.6.3.4 [new.delete.placement] | Passing null pointer to placement new | Yes | 2 |
114(i) | TC1 | 17.6.3.4 [new.delete.placement] | Placement forms example in error twice | Yes |  | 196
196(i) | Dup | 17.6.3.4 [new.delete.placement] | Placement new example has alignment problems | Yes |  | 114
2508(i) | New | 17.6.3.5 [new.delete.dataraces] | §[new.delete.dataraces] wording needs to be updated | No | 3 |
1524(i) | C++11 | 17.6.3.5 [new.delete.dataraces] | Allocation functions are missing happens-before requirements and guarantees | Yes |  |
1366(i) | Resolved | 17.6.3.5 [new.delete.dataraces] | New-handler and data races | Yes |  |
1365(i) | Resolved | 17.6.4 [alloc.errors] | Thread-safety of handler functions | Yes |  |
2378(i) | C++17 | 17.6.4.1 [bad.alloc] | Behaviour of standard exception types | Yes | 0 |
994(i) | C++11 | 17.6.4.3 [new.handler] | `quick_exit` should terminate well-defined | Yes |  |
3495(i) | WP | 17.6.5 [ptr.launder] | `constexpr launder` makes pointers to inactive members of unions usable | Yes | 3 |
2859(i) | C++20 | 17.6.5 [ptr.launder] | Definition of reachable in [ptr.launder] misses pointer arithmetic from pointer-interconvertible object | Yes | 2 |
2821(i) | Resolved | 17.6.5 [ptr.launder] | `std::launder()` should be marked as `[[nodiscard]]` | Yes | 3 |
2860(i) | NAD | 17.6.5 [ptr.launder] | `launder` and base class subobjects | Yes | 2 |
3624(i) | New | 17.7 [support.rtti] | Inconsistency of `<typeinfo>`, `<initializer_list>`, and `<compare>` in the standard library | Yes | 3 |
2398(i) | Open | 17.7.3 [type.info] | `type_info`'s destructor shouldn't be required to be virtual | Yes | 3 |
108(i) | TC1 | 17.7.3 [type.info] | Lifetime of exception::what() return unspecified | Yes |  |
3396(i) | C++20 | 17.8.2.2 [support.srcloc.cons] | Clarify point of reference for `source_location::current()` (DE 169) | Yes | 2 |
70(i) | TC1 | 17.9 [support.exception] | Uncaught_exception() missing throw() specification | Yes |  |
269(i) | NAD | 17.9 [support.exception] | cstdarg and unnamed parameters | Yes |  |
471(i) | C++11 | 17.9.3 [exception] | result of `what()` implementation-defined | Yes |  |
266(i) | CD1 | 17.9.4 [bad.exception] | bad_exception::~bad_exception() missing Effects clause | Yes |  |
2088(i) | Open | 17.9.5 [exception.terminate] | `std::terminate` problem | No | 3 |
2111(i) | C++17 | 17.9.5.4 [terminate] | Which `unexpected`/`terminate` handler is called from the exception handling runtime? | Yes | 3 |
313(i) | NAD | 17.9.5.4 [terminate] | set_terminate and set_unexpected question | Yes |  |
314(i) | NAD | 17.9.5.4 [terminate] | Is the stack unwound when terminate() is called? | Yes |  |
1130(i) | C++11 | 17.9.7 [propagation] | `copy_exception` name misleading | Yes |  |
744(i) | CD1 | 17.9.7 [propagation] | What is the lifetime of an exception pointed to by an `exception_ptr`? | Yes |  |
746(i) | CD1 | 17.9.7 [propagation] | `current_exception` may fail with `bad_alloc` | Yes |  |
820(i) | CD1 | 17.9.7 [propagation] | `current_exception()`'s interaction with throwing copy ctors | Yes |  |
829(i) | CD1 | 17.9.7 [propagation] | current_exception wording unclear about exception type | Yes |  |
1135(i) | Resolved | 17.9.7 [propagation] | `exception_ptr` should support contextual conversion to `bool` | Yes |  |
1307(i) | Resolved | 17.9.7 [propagation] | `exception_ptr` and `allocator` pointers don't understand != | Yes |  |
1364(i) | Resolved | 17.9.7 [propagation] | It is not clear how `exception_ptr` is synchronized | Yes |  |
707(i) | NAD | 17.9.7 [propagation] | null pointer constant for `exception_ptr` | Yes |  |
745(i) | NAD | 17.9.7 [propagation] | copy_exception API slices. | Yes |  |
1369(i) | NAD | 17.9.7 [propagation] | `rethrow_exception` may introduce data races | Yes |  |
2855(i) | C++17 | 17.9.8 [except.nested] | `std::throw_with_nested("string_literal")` | Yes | 0 |
2483(i) | C++17 | 17.9.8 [except.nested] | `throw_with_nested()` should use `is_final` | Yes | 2 |
2484(i) | C++17 | 17.9.8 [except.nested] | `rethrow_if_nested()` is doubly unimplementable | Yes | 2 |
2784(i) | C++17 | 17.9.8 [except.nested] | Resolution to LWG 2484 is missing "otherwise, no effects" and is hard to parse | Yes | 0 |
819(i) | C++11 | 17.9.8 [except.nested] | rethrow_if_nested | Yes |  |
1136(i) | C++11 | 17.9.8 [except.nested] | Incomplete specification of `nested_exception::rethrow_nested()` | Yes |  |
1216(i) | C++11 | 17.9.8 [except.nested] | LWG 1066 Incomplete? | Yes |  |
1370(i) | C++11 | 17.9.8 [except.nested] | `throw_with_nested` should not use perfect forwarding | Yes |  |
1008(i) | NAD | 17.9.8 [except.nested] | `nested_exception` wording unclear | Yes |  |
1132(i) | NAD | 17.9.8 [except.nested] | JP-30: nested exceptions | Yes |  |
1007(i) | NAD Concepts | 17.9.8 [except.nested] | `throw_with_nested` not concept enabled | Yes |  |
2453(i) | New | 17.10 [support.initlist] | §[iterator.range] and now [iterator.container] aren't available via `<initializer_list>` | No | 3 |
2493(i) | New | 17.10 [support.initlist] | `initializer_list` supports incomplete classes | No | 4 |
2432(i) | EWG | 17.10 [support.initlist] | `initializer_list` assignability | Yes | 2 |
906(i) | NAD Concepts | 17.10 [support.initlist] | `ObjectType` is the wrong concept to constrain `initializer_list` | Yes |  |
3295(i) | Resolved | 17.11.2 [cmp.categories] | Comparison category `operator==` are mis-specified | Yes | 1 |
3239(i) | Resolved | 17.11.2.2 [cmp.partialord] | Hidden friends should be specified more narrowly | Yes |  |
3584(i) | New | 17.11.3 [cmp.common] | Clarify common comparison category conversions | Yes | 3 |
3587(i) | New | 17.11.4 [cmp.concept] | `std::three_way_comparable_with<T, U, void>` can be satisfied but can't be modeled | No | 3 |
3360(i) | C++20 | 17.11.4 [cmp.concept] | `three_way_comparable_with` is inconsistent with similar concepts | Yes | 0 |
3491(i) | New | 17.11.6 [cmp.alg] | What is a "decayed type"? | No | 3 |
3465(i) | WP | 17.11.6 [cmp.alg] | `compare_partial_order_fallback` requires `F < E` | Yes | 0 |
3324(i) | C++20 | 17.11.6 [cmp.alg] | Special-case `std::strong/weak/partial_order` for pointers | Yes | 0 |
3653(i) | New | 17.12.2 [coroutine.syn] | `<coroutine>` is freestanding, but uses `std::hash` which is not | No | 3 |
3330(i) | C++20 | 17.12.2 [coroutine.syn] | Include `<compare>` from most library headers | Yes | 0 |
3469(i) | Resolved | 17.12.4.7 [coroutine.handle.promise] | Precondition of `coroutine_handle::promise` may be insufficient | Yes | 2 |
3460(i) | WP | 17.12.5.2.3 [coroutine.handle.noop.resumption] | Unimplementable `noop_coroutine_handle` guarantees | Yes | 2 |
2099(i) | C++14 | 17.13 [support.runtime] | Unnecessary constraints of `va_start()` usage | Yes |  |
894(i) | C++11 | 17.13 [support.runtime] | longjmp and destructors | Yes |  |
619(i) | CD1 | 17.13 [support.runtime] | Longjmp wording problem | Yes |  |
2155(i) | Resolved | 17.13 [support.runtime] | Macro `__bool_true_false_are_defined` should be removed | Yes | 4 |
2241(i) | Resolved | 17.13 [support.runtime] | `<cstdalign>` and `#define` of `alignof` | Yes | 2 |
1265(i) | NAD | 17.13 [support.runtime] | `longjmp` and destructors | Yes |  |
3652(i) | NAD | 17.13.3 [csetjmp.syn] | Can we relax the preconditions of `longjmp`? | Yes |  |
2879(i) | Resolved | 17.13.4 [csignal.syn] | Removing C dependencies from signal handler wording | Yes |  |

## Section 18 (17 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3182(i) | C++20 | 18.4.2 [concept.same] | Specification of `Same` could be clearer | Yes | 0 |
3608(i) | New | 18.4.4 [concept.convertible] | `convertible_to` and temporary-bound references | No | 3 |
3459(i) | New | 18.4.4 [concept.convertible] | Why doesn't `std::convertible_to` have semantic requirement when `To` is reference-to-function type? | No | 3 |
3557(i) | WP | 18.4.4 [concept.convertible] | The `static_cast` expression in `convertible_to` has the wrong operand | Yes |  |
3461(i) | WP | 18.4.4 [concept.convertible] | `convertible_to`'s description mishandles cv-qualified `void` | Yes | 0 |
3194(i) | C++20 | 18.4.4 [concept.convertible] | `ConvertibleTo` prose does not match code | Yes | 1 |
3151(i) | Resolved | 18.4.4 [concept.convertible] | `ConvertibleTo` rejects conversions from array and function types | Yes | 3 |
3153(i) | C++20 | 18.4.6 [concept.common] | `Common` and `common_type` have too little in common | Yes | 0 |
3154(i) | C++20 | 18.4.6 [concept.common] | `Common` and `CommonReference` have a common defect | Yes | 0 |
3175(i) | C++20 | 18.4.9 [concept.swappable] | The `CommonReference` requirement of concept `SwappableWith` is not satisfied in the example | Yes | 1 |
3345(i) | Resolved | 18.4.9 [concept.swappable] | Incorrect usages of "models" versus "satisfies" | Yes | 2 |
3149(i) | C++20 | 18.4.12 [concept.default.init] | `DefaultConstructible` should require default initialization | Yes | 2 |
3338(i) | C++20 | 18.4.12 [concept.default.init] | Rename `default_constructible` to `default_initializable` | Yes | 0 |
3421(i) | WP | 18.5.2 [concept.booleantestable] | Imperfect ADL emulation for `boolean-testable` | Yes | 0 |
3329(i) | C++20 | 18.5.4 [concept.totallyordered] | `totally_ordered_with` both directly and indirectly requires `common_reference_with` | Yes | 0 |
3331(i) | C++20 | 18.5.4 [concept.totallyordered] | Define `totally_ordered/_with` in terms of `partially-ordered-with` | Yes | 0 |
3141(i) | C++20 | 18.6 [concepts.object] | `CopyConstructible` doesn't preserve source values | Yes | 2 |

## Section 19 (30 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
1371(i) | NAD | 19 [diagnostics] | Standard exceptions require stronger no-throw guarantees | Yes |  |
254(i) | CD1 | 19.2 [std.exceptions] | Exception types in clause 19 are constructed from `std::string` | Yes |  |
2073(i) | NAD | 19.2 [std.exceptions] | Library exceptions that take string arguments | Yes |  |
2413(i) | New | 19.3 [assertions] | `assert` macro is overconstrained | No | 4 |
3011(i) | Open | 19.3 [assertions] | Requirements for `assert(E)` inconsistent with C | No | 2 |
2234(i) | C++17 | 19.3 [assertions] | `assert()` should allow usage in constant expressions | Yes | 2 |
2559(i) | C++17 | 19.3 [assertions] | Error in LWG 2234's resolution | Yes | 0 |
288(i) | CD1 | 19.4 [errno] | <cerrno> requirements missing macro EILSEQ | Yes |  |
3629(i) | New | 19.5 [syserr] | `make_error_code` and `make_error_condition` are customization points | Yes | 2 |
1237(i) | C++11 | 19.5 [syserr] | Constrained `error_code`/`error_condition members` | Yes |  |
804(i) | CD1 | 19.5 [syserr] | Some problems with classes `error_code`/`error_condition` | Yes |  |
805(i) | CD1 | 19.5 [syserr] | `posix_error::posix_errno` concerns | Yes |  |
697(i) | Resolved | 19.5 [syserr] | New `<system_error>` header leads to name clashes | Yes |  |
832(i) | NAD | 19.5 [syserr] | Applying constexpr to System error support | Yes |  |
2686(i) | C++17 | 19.5.2 [system.error.syn] | Why is `std::hash` specialized for `error_code`, but not `error_condition`? | Yes | 3 |
2145(i) | C++14 | 19.5.3 [syserr.errcat] | `error_category` default constructor | Yes |  |
890(i) | C++11 | 19.5.3 [syserr.errcat] | Improving `<system_error>` initialization | Yes |  |
3019(i) | 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 |
3598(i) | WP | 19.5.3.5 [syserr.errcat.objects] | `system_category().default_error_condition(0)` is underspecified | Yes |  |
1372(i) | C++11 | 19.5.3.5 [syserr.errcat.objects] | Adopt recommended practice for standard error categories | Yes |  |
2992(i) | NAD | 19.5.3.5 [syserr.errcat.objects] | `system_category()` and `error_code::error_code()` should be `constexpr` | Yes |  |
3053(i) | New | 19.5.4.1 [syserr.errcode.overview] | Prohibit `error_code` construction from rvalues of `error_category` | Yes | 3 |
825(i) | Resolved | 19.5.4.1 [syserr.errcode.overview] | Missing rvalues reference stream insert/extract operators? | Yes |  |
1229(i) | Resolved | 19.5.4.3 [syserr.errcode.modifiers] | `error_code operator=` typo | Yes |  |
971(i) | NAD | 19.5.4.5 [syserr.errcode.nonmembers] | Spurious diagnostic conversion function | Yes |  |
2109(i) | C++14 | 19.5.7 [syserr.hash] | Incorrect requirements for `hash` specializations | Yes |  |
698(i) | CD1 | 19.5.8.1 [syserr.syserr.overview] | `system_error` needs `const char*` constructors | Yes |  |
3162(i) | New | 19.5.8.2 [syserr.syserr.members] | `system_error::system_error(error_code ec)` not explicit | Yes | 3 |
3112(i) | C++20 | 19.5.8.2 [syserr.syserr.members] | `system_error` and `filesystem_error` constructors taking a `string` may not be able to meet their postconditions | Yes | 0 |
1103(i) | C++11 | 19.5.8.2 [syserr.syserr.members] | `system_error` constructor postcondition overly strict | Yes |  |

## Section 20 (617 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
312(i) | CD1 | 20 [utilities] | Table 27 is missing headers | Yes |  |
2888(i) | Resolved | 20 [utilities] | Variables of library tag types need to be inline variables | Yes |  |
2889(i) | Resolved | 20 [utilities] | Mark `constexpr` global variables as `inline` | Yes |  |
1075(i) | Resolved | 20 [utilities] | Scoped allocators are too complex | Yes |  |
2893(i) | NAD | 20 [utilities] | Parsing Hexadecimally in P0067R4 | Yes |  |
2212(i) | C++17 | 20.2 [utility] | `tuple_size` for `const pair` request `<tuple>` header | Yes | 3 |
1255(i) | C++11 | 20.2 [utility] | `declval` should be added to the library | Yes |  |
2955(i) | Resolved | 20.2 [utility] | `to_chars` / `from_chars` depend on `std::string` | Yes |  |
2456(i) | Resolved | 20.2 [utility] | Incorrect exception specifications for '`swap`' throughout library | Yes | 1 |
1377(i) | Resolved | 20.2 [utility] | The revised `forward` is not compatible with access-control | Yes |  |
1289(i) | NAD | 20.2 [utility] | Generic casting requirements for smart pointers | Yes |  |
1373(i) | NAD | 20.2 [utility] | Customizable traits should have their own headers | Yes |  |
2153(i) | LEWG | 20.2.2 [utility.swap] | Narrowing of the non-member `swap` contract | No | 2 |
2554(i) | Resolved | 20.2.2 [utility.swap] | Swapping multidimensional arrays is never `noexcept` | Yes | 2 |
2800(i) | Resolved | 20.2.2 [utility.swap] | `constexpr swap` | Yes | 3 |
2297(i) | NAD | 20.2.3 [utility.exchange] | [CD] Missing type requirements for `std::exchange` | Yes |  |
2388(i) | NAD | 20.2.3 [utility.exchange] | Handling self-assignment in the proposed library function `std::exchange` | Yes | 2 |
939(i) | C++11 | 20.2.4 [forward] | Problem with `std::identity` and reference-to-temporaries | Yes |  |
808(i) | CD1 | 20.2.4 [forward] | §[forward] incorrect redundant specification | Yes |  |
700(i) | CD1 | 20.2.4 [forward] | N1856 defines struct `identity` | Yes |  |
823(i) | Resolved | 20.2.4 [forward] | `identity<void>` seems broken | Yes |  |
1054(i) | Resolved | 20.2.4 [forward] | `forward` broken | Yes |  |
2599(i) | New | 20.2.6 [declval] | Library incomplete type permission phrase is unclear | No | 3 |
2314(i) | C++14 | 20.3.1 [intseq.general] | `apply()` should return `decltype(auto)` and use `decay_t` before `tuple_size` | Yes | 0 |
2345(i) | NAD | 20.3.2 [intseq.intseq] | `integer_sequence` should have a self-typedef `::type` | Yes | 2 |
296(i) | C++11 | 20.4 [pairs] | Missing descriptions and requirements of pair operators | Yes |  |
811(i) | C++11 | 20.4 [pairs] | `pair` of pointers no longer works with literal 0 | Yes |  |
885(i) | C++11 | 20.4 [pairs] | `pair` assignment | Yes |  |
265(i) | CD1 | 20.4 [pairs] | std::pair::pair() effects overly restrictive | Yes |  |
706(i) | CD1 | 20.4 [pairs] | `make_pair()` should behave as `make_tuple()` wrt. `reference_wrapper()` | Yes |  |
181(i) | TC1 | 20.4 [pairs] | make_pair() unintended behavior | Yes |  |
353(i) | Resolved | 20.4 [pairs] | `std::pair` missing template assignment | Yes |  |
482(i) | Resolved | 20.4 [pairs] | Swapping pairs | Yes |  |
1378(i) | Resolved | 20.4 [pairs] | `pair` and `tuple` have too many conversions | Yes |  |
1380(i) | Resolved | 20.4 [pairs] | `pair` and `tuple` of references need to better specify move-semantics | Yes |  |
1382(i) | Resolved | 20.4 [pairs] | `pair` and `tuple` constructors should `forward` arguments | Yes |  |
1383(i) | Resolved | 20.4 [pairs] | Inconsistent defaulted move/copy members in `pair` and `tuple` | Yes |  |
840(i) | NAD | 20.4 [pairs] | `pair` default template argument | Yes |  |
916(i) | NAD | 20.4 [pairs] | Redundant move-assignment operator of `pair` should be removed | Yes |  |
348(i) | Dup | 20.4 [pairs] | Minor issue with std::pair operator< | Yes |  | 532
1167(i) | NAD Concepts | 20.4 [pairs] | `pair<T,U>` doesn't model `LessThanComparable` in unconstrained code even if `T` and `U` do. | Yes |  |
3342(i) | New | 20.4.2 [pairs.pair] | Library wording uses "initializes `x` with `y`", which is underspecified | No | 3 |
2289(i) | Open | 20.4.2 [pairs.pair] | `constexpr` guarantees of defaulted functions still insufficient | No | 3 |
2958(i) | C++20 | 20.4.2 [pairs.pair] | Moves improperly defined as deleted | Yes | 2 |
3346(i) | C++20 | 20.4.2 [pairs.pair] | `pair` and `tuple` copy and move constructor have backwards specification | Yes | 0 |
3382(i) | C++20 | 20.4.2 [pairs.pair] | NTTP for `pair` and `array` | Yes | 2 |
2729(i) | C++17 | 20.4.2 [pairs.pair] | Missing SFINAE on `std::pair::operator=` | Yes | 2 |
1324(i) | Resolved | 20.4.2 [pairs.pair] | Still too many implicit conversions for `pair` and `tuple` | Yes |  |
1326(i) | Resolved | 20.4.2 [pairs.pair] | Missing/wrong preconditions for `pair` and `tuple` functions | Yes |  |
1379(i) | Resolved | 20.4.2 [pairs.pair] | `pair` copy-assignment not consistent for references | Yes |  |
2068(i) | NAD | 20.4.2 [pairs.pair] | `std::pair` not C++03-compatible with defaulted copy c'tor | Yes |  |
2766(i) | New | 20.4.3 [pairs.spec] | Swapping non-swappable types | Yes | 3 |
3347(i) | C++20 | 20.4.3 [pairs.spec] | `std::pair<T, U>` now requires `T` and `U` to be less-than-comparable | Yes | 1 |
3166(i) | New | 20.4.4 [pair.astuple] | No such descriptive element as Value: | No | 3 |
2974(i) | C++20 | 20.4.4 [pair.astuple] | Diagnose out of bounds `tuple_element`/`variant_alternative` | Yes |  |
1061(i) | NAD Editorial | 20.4.4 [pair.astuple] | Bad indexing for tuple access to pair (Editorial?) | Yes |  |
2899(i) | C++20 | 20.5 [tuple] | `is_(nothrow_)move_constructible` and `tuple`, `optional` and `unique_ptr` | Yes | 2 |
522(i) | CD1 | 20.5 [tuple] | Tuple doesn't define swap | Yes |  |
801(i) | Resolved | 20.5 [tuple] | `tuple` and `pair` trivial members | Yes |  |
2773(i) | C++17 | 20.5.1 [tuple.general] | Making `std::ignore constexpr` | Yes | 0 |
2796(i) | C++17 | 20.5.1 [tuple.general] | `tuple` should be a literal type | Yes | 2 |
2446(i) | NAD | 20.5.1 [tuple.general] | Unspecialized `std::tuple_size` should be defined | Yes |  |
3378(i) | New | 20.5.2 [tuple.syn] | `tuple_size_v/tuple_element_t` should be available when `tuple_size/tuple_element` are | Yes | 3 |
1116(i) | Resolved | 20.5.3 [tuple.tuple] | Literal constructors for tuple | Yes |  |
2051(i) | Resolved | 20.5.3 [tuple.tuple] | Explicit `tuple` constructors for more than one parameter | Yes | 2 |
1077(i) | NAD Editorial | 20.5.3 [tuple.tuple] | Nonesense `tuple` declarations | Yes |  |
3583(i) | New | 20.5.3.1 [tuple.cnstr] | Clarify if/when short circuiting applies to conditions in Constraints: elements | No | 3 |
2528(i) | New | 20.5.3.1 [tuple.cnstr] | Order of `std::tuple` construction unspecified | No | 3 |
3121(i) | WP | 20.5.3.1 [tuple.cnstr] | `tuple` constructor constraints for `UTypes&&...` overloads | Yes | 2 |
3211(i) | WP | 20.5.3.1 [tuple.cnstr] | `std::tuple<>` should be trivially constructible | Yes | 3 |
3158(i) | C++20 | 20.5.3.1 [tuple.cnstr] | `tuple(allocator_arg_t, const Alloc&)` should be conditionally explicit | Yes | 3 |
2312(i) | C++17 | 20.5.3.1 [tuple.cnstr] | `tuple`'s constructor constraints need to be phrased more precisely | Yes | 2 |
2549(i) | C++17 | 20.5.3.1 [tuple.cnstr] | Tuple EXPLICIT constructor templates that take `tuple` parameters end up taking references to temporaries and will create dangling references | Yes | 2 |
886(i) | C++11 | 20.5.3.1 [tuple.cnstr] | `tuple` construction | Yes |  |
807(i) | CD1 | 20.5.3.1 [tuple.cnstr] | `tuple` construction should not fail unless its element's construction fails | Yes |  |
3155(i) | Resolved | 20.5.3.1 [tuple.cnstr] | `tuple<any, any>{allocator_arg_t, an_allocator}` | Yes | 3 |
2419(i) | Resolved | 20.5.3.1 [tuple.cnstr] | Clang's libc++ extension to `std::tuple` | Yes |  |
1117(i) | Resolved | 20.5.3.1 [tuple.cnstr] | `tuple` copy constructor | Yes |  |
3440(i) | NAD | 20.5.3.1 [tuple.cnstr] | Aggregate-paren-init breaks direct-initializing a `tuple` or `optional` from `{aggregate-member-value}` | Yes | 2 |
917(i) | NAD | 20.5.3.1 [tuple.cnstr] | Redundant move-assignment operator of `tuple` should be removed | Yes |  |
918(i) | NAD Concepts | 20.5.3.3 [tuple.swap] | Swap for tuple needs to be conceptualized | Yes |  |
2933(i) | New | 20.5.4 [tuple.creation] | PR for LWG 2773 could be clearer | Yes | 3 |
2275(i) | C++14 | 20.5.4 [tuple.creation] | [CD] Why is `forward_as_tuple` not `constexpr`? | Yes |  |
2301(i) | C++14 | 20.5.4 [tuple.creation] | Why is `std::tie` not `constexpr`? | Yes | 2 |
1384(i) | C++11 | 20.5.4 [tuple.creation] | Function `pack_arguments` is poorly named | Yes |  |
1385(i) | C++11 | 20.5.4 [tuple.creation] | `tuple_cat` should be a single variadic signature | Yes |  |
1386(i) | C++11 | 20.5.4 [tuple.creation] | `pack_arguments` overly complex | Yes |  |
1201(i) | Resolved | 20.5.4 [tuple.creation] | Do we always want to unwrap `ref`-wrappers in `make_tuple` | Yes |  |
3528(i) | WP | 20.5.5 [tuple.apply] | `make_from_tuple` can perform (the equivalent of) a C-style cast | Yes | 3 |
2770(i) | C++17 | 20.5.6 [tuple.helper] | `tuple_size<const T>` specialization is not SFINAE compatible and breaks decomposition declarations | Yes | 1 |
2313(i) | C++14 | 20.5.6 [tuple.helper] | `tuple_size` should always derive from `integral_constant<size_t, N>` | Yes | 2 |
1118(i) | C++11 | 20.5.6 [tuple.helper] | `tuple` query APIs do not support cv-qualification | Yes |  |
775(i) | CD1 | 20.5.6 [tuple.helper] | Tuple indexing should be unsigned? | Yes |  |
1119(i) | NAD | 20.5.6 [tuple.helper] | tuple query APIs do not support references | Yes |  |
2485(i) | C++17 | 20.5.7 [tuple.elem] | `get()` should be overloaded for `const tuple&&` | Yes | 1 |
1191(i) | C++11 | 20.5.7 [tuple.elem] | `tuple get` API should respect rvalues | Yes |  |
2472(i) | New | 20.5.8 [tuple.rel] | Heterogeneous comparisons in the standard library can result in ambiguities | No | 3 |
532(i) | LEWG | 20.5.8 [tuple.rel] | Tuple comparison | Yes |  | 348
1335(i) | C++11 | 20.5.8 [tuple.rel] | Insufficient requirements for `tuple::operator<()` | Yes |  |
928(i) | NAD Concepts | 20.5.8 [tuple.rel] | Wrong concepts used for `tuple`'s comparison operators | Yes |  |
2857(i) | C++17 | 20.6 [optional] | `{variant,optional,any}::emplace` should return the constructed value | Yes | 1 |
2862(i) | Resolved | 20.6 [optional] | LWG 2756 should be accepted | Yes |  |
2990(i) | Open | 20.6.3 [optional.optional] | `optional::value_type` is not always a value type | Yes | 3 |
3196(i) | C++20 | 20.6.3 [optional.optional] | `std::optional<T>` is ill-formed is `T` is an array | Yes | 0 |
2900(i) | C++17 | 20.6.3 [optional.optional] | The copy and move constructors of `optional` are not `constexpr` | Yes |  |
2756(i) | C++17 | 20.6.3 [optional.optional] | C++ WP `optional<T>` should 'forward' `T`'s implicit conversions | Yes | 1 |
2825(i) | Resolved | 20.6.3 [optional.optional] | LWG 2756 breaks class template argument deduction for `optional` | Yes | 2 |
3016(i) | NAD | 20.6.3 [optional.optional] | `optional` and over-aligned types | Yes | 3 |
2811(i) | New | 20.6.3.2 [optional.ctor] | "Selected constructor" wording is incorrect for `optional`/`variant`/`any` | Yes | 3 |
2842(i) | C++17 | 20.6.3.2 [optional.ctor] | `in_place_t` check for `optional::optional(U&&)` should decay `U` | Yes | 0 |
2753(i) | Resolved | 20.6.3.2 [optional.ctor] | Optional's constructors and assignments need constraints | Yes | 0 |
2746(i) | New | 20.6.3.4 [optional.assign] | Inconsistency between requirements for `emplace` between `optional` and `variant` | Yes | 3 |
2748(i) | C++17 | 20.6.3.5 [optional.swap] | `swappable` traits for `optional`s | Yes | 0 |
3424(i) | New | 20.6.3.6 [optional.observe] | `optional::value_or` should never return a cv-qualified type | Yes | 3 |
2829(i) | Open | 20.6.3.6 [optional.observe] | LWG 2740 leaves behind vacuous words | No | 2 |
2740(i) | C++17 | 20.6.3.6 [optional.observe] | `constexpr optional<T>::operator->` | Yes | 0 |
3613(i) | New | 20.6.4 [optional.nullopt] | Specify that `nullopt_t` is copyable | Yes | 3 |
2736(i) | C++17 | 20.6.4 [optional.nullopt] | `nullopt_t` insufficiently constrained | Yes | 2 |
3562(i) | NAD | 20.6.4 [optional.nullopt] | Superseding `nullopt_t`'s requirement to not be DefaultConstructible | Yes |  |
2806(i) | C++17 | 20.6.5 [optional.bad.access] | Base class of `bad_optional_access` | Yes | 1 |
3566(i) | WP | 20.6.8 [optional.comp.with.t] | Constraint recursion for `operator<=>(optional<T>, U)` | Yes |  |
2945(i) | C++20 | 20.6.8 [optional.comp.with.t] | Order of template parameters in `optional` comparisons | Yes | 2 |
2934(i) | C++17 | 20.6.8 [optional.comp.with.t] | `optional<const T>` doesn't compare with `T` | Yes |  |
3627(i) | New | 20.6.9 [optional.specalg] | Inconsistent specifications for `std::make_optional` overloads | Yes | 3 |
2805(i) | Resolved | 20.7 [variant] | `void` and reference type alternatives in `variant`, `variant<>` and `index()` | Yes |  |
2881(i) | New | 20.7.3 [variant.variant] | Adopt section III of P0308R0 | No | 3 |
2901(i) | C++17 | 20.7.3 [variant.variant] | Variants cannot properly support allocators | Yes | 0 |
2902(i) | NAD | 20.7.3 [variant.variant] | `variant` should only support complete types | Yes | 0 |
2971(i) | NAD | 20.7.3 [variant.variant] | `variant` should require `Destructible` types | Yes |  |
3215(i) | New | 20.7.3.2 [variant.ctor] | `variant` default constructor has vague `constexpr` requirements | No | 2 |
2833(i) | Open | 20.7.3.2 [variant.ctor] | Library needs to specify what it means when it declares a function `constexpr` | Yes | 2 |
2991(i) | LEWG | 20.7.3.2 [variant.ctor] | `variant` copy constructor missing `noexcept(see below)` | Yes |  |
3024(i) | C++20 | 20.7.3.2 [variant.ctor] | `variant`'s copies must be deleted instead of disabled via SFINAE | Yes |  |
2903(i) | C++17 | 20.7.3.2 [variant.ctor] | The form of initialization for the emplace-constructors is not specified | Yes |  |
3228(i) | Resolved | 20.7.3.2 [variant.ctor] | Surprising `variant` construction | Yes | 2 |
2882(i) | Resolved | 20.7.3.2 [variant.ctor] | Clarify `variant` construction | Yes |  |
3069(i) | New | 20.7.3.4 [variant.assign] | Move assigning `variant`'s subobject corrupts data | Yes | 3 |
3585(i) | WP | 20.7.3.4 [variant.assign] | Variant converting assignment with immovable alternative | Yes |  |
2904(i) | C++17 | 20.7.3.4 [variant.assign] | Make `variant` move-assignment more exception safe | Yes |  |
2749(i) | C++17 | 20.7.3.7 [variant.swap] | `swappable` traits for `variant`s | Yes | 1 |
2970(i) | C++20 | 20.7.7 [variant.visit] | Return type of `std::visit` misspecified | Yes | 2 |
3052(i) | Resolved | 20.7.7 [variant.visit] | `visit` is underconstrained | Yes | 2 |
2809(i) | Resolved | 20.7.12 [variant.hash] | `variant` hash requirements | Yes |  |
2868(i) | C++17 | 20.8.3 [any.bad.any.cast] | Missing specification of `bad_any_cast::what()` | Yes |  |
3416(i) | New | 20.8.4 [any.class] | The Throws: specification of `std::any` does not mention allocation | No | 3 |
2789(i) | C++17 | 20.8.4 [any.class] | Equivalence of contained objects | Yes | 0 |
2744(i) | C++17 | 20.8.4.2 [any.cons] | `any`'s `in_place` constructors | Yes | 0 |
2754(i) | Resolved | 20.8.4.2 [any.cons] | The `in_place` constructors and `emplace` functions added by P0032R3 don't require `CopyConstructible` | Yes | 1 |
2886(i) | NAD | 20.8.4.5 [any.observers] | Keep the `empty()` functions in `any` | Yes |  |
3423(i) | New | 20.8.5 [any.nonmembers] | `std::any_cast` should never return a cv-qualified type | Yes | 3 |
3305(i) | Open | 20.8.5 [any.nonmembers] | `any_cast<void>` | Yes | 2 |
2768(i) | C++17 | 20.8.5 [any.nonmembers] | `any_cast` and move semantics | Yes | 0 |
2769(i) | C++17 | 20.8.5 [any.nonmembers] | Redundant `const` in the return type of `any_cast(const any&)` | Yes | 0 |
2348(i) | Open | 20.9.2 [template.bitset] | `charT('1')` is not the wide equivalent of `'1'` | Yes | 3 |
853(i) | C++11 | 20.9.2 [template.bitset] | `to_string` needs updating with `zero` and `one` | Yes |  |
1113(i) | C++11 | 20.9.2 [template.bitset] | `bitset::to_string` could be simplified | Yes |  |
1227(i) | C++11 | 20.9.2 [template.bitset] | `<bitset>` synopsis overspecified | Yes |  |
1250(i) | C++11 | 20.9.2 [template.bitset] | `<bitset>` still overspecified | Yes |  |
693(i) | CD1 | 20.9.2 [template.bitset] | `std::bitset::all()` missing | Yes |  |
694(i) | CD1 | 20.9.2 [template.bitset] | `std::bitset` and `long long` | Yes |  |
11(i) | TC1 | 20.9.2 [template.bitset] | Bitset minor problems | Yes |  |
1112(i) | NAD | 20.9.2 [template.bitset] | bitsets and new style for loop | Yes |  |
116(i) | Dup | 20.9.2 [template.bitset] | bitset cannot be constructed with a const char* | Yes |  | 778
2250(i) | C++17 | 20.9.2.2 [bitset.cons] | Follow-up On Library Issue 2207 | Yes | 3 |
1325(i) | C++11 | 20.9.2.2 [bitset.cons] | `bitset` | Yes |  |
396(i) | CD1 | 20.9.2.2 [bitset.cons] | what are characters zero and one | Yes |  |
457(i) | CD1 | 20.9.2.2 [bitset.cons] | bitset constructor: incorrect number of initialized bits | Yes |  |
778(i) | CD1 | 20.9.2.2 [bitset.cons] | std::bitset does not have any constructor taking a string literal | Yes |  | 116
907(i) | C++11 | 20.9.2.3 [bitset.members] | Bitset's immutable element retrieval is inconsistently defined | Yes |  |
186(i) | CD1 | 20.9.2.3 [bitset.members] | bitset::set() second parameter should be bool | Yes |  |
434(i) | CD1 | 20.9.2.3 [bitset.members] | bitset::to_string() hard to use | Yes |  |
1168(i) | NAD Editorial | 20.9.2.3 [bitset.members] | Odd wording for bitset equality operators | Yes |  |
3199(i) | C++20 | 20.9.4 [bitset.operators] | `istream >> bitset<0>` fails | Yes |  |
303(i) | CD1 | 20.9.4 [bitset.operators] | Bitset input operator underspecified | Yes |  |
1073(i) | C++11 | 20.10 [memory] | Declaration of `allocator_arg` should be `constexpr` | Yes |  |
1401(i) | C++11 | 20.10 [memory] | Provide support for `unique_ptr<T> == nullptr` | Yes |  |
1402(i) | C++11 | 20.10 [memory] | `nullptr` constructors for smart pointers should be `constexpr` | Yes |  |
1233(i) | NAD Editorial | 20.10 [memory] | Missing `unique_ptr` signatures in synopsis | Yes |  |
1026(i) | NAD Concepts | 20.10 [memory] | Smart pointers need to be concept-constrained templates | Yes |  |
3552(i) | WP | 20.10.2 [memory.syn] | Parallel specialized memory algorithms should require forward iterators | Yes |  |
3303(i) | C++20 | 20.10.2 [memory.syn] | Bad "`constexpr`" marker for `destroy/destroy_n` | Yes | 0 |
3545(i) | Open | 20.10.3 [pointer.traits] | `std::pointer_traits` should be SFINAE-friendly | Yes | 2 |
3454(i) | LEWG | 20.10.3 [pointer.traits] | `pointer_traits::pointer_to` should be `constexpr` | Yes |  |
1404(i) | C++11 | 20.10.3 [pointer.traits] | `pointer_traits` should have a `size_type` member | Yes |  |
3374(i) | C++20 | 20.10.4 [pointer.conversion] | P0653 + P1006 should have made the other `std::to_address` overload `constexpr` | Yes | 0 |
2421(i) | New | 20.10.5 [ptr.align] | Non-specification of handling zero size in `std::align` [ptr.align] | No | 3 |
2377(i) | C++17 | 20.10.5 [ptr.align] | `std::align` requirements overly strict | Yes | 0 |
1403(i) | C++11 | 20.10.6 [allocator.tag] | Inconsistent definitions for `allocator_arg` | Yes |  |
3677(i) | New | 20.10.7.2 [allocator.uses.construction] | Is a cv-qualified `pair` specially handled in uses-allocator construction? | No | 2 |
3192(i) | New | 20.10.7.2 [allocator.uses.construction] | §[allocator.uses.construction] functions misbehave for `const` types | Yes | 3 |
3525(i) | WP | 20.10.7.2 [allocator.uses.construction] | `uses_allocator_construction_args` fails to handle types convertible to `pair` | Yes | 3 |
3526(i) | WP | 20.10.7.2 [allocator.uses.construction] | Return types of `uses_allocator_construction_args` unspecified | Yes | 3 |
3527(i) | WP | 20.10.7.2 [allocator.uses.construction] | `uses_allocator_construction_args` handles rvalue pairs of rvalue references incorrectly | Yes |  |
3185(i) | C++20 | 20.10.7.2 [allocator.uses.construction] | Uses-allocator construction functions missing `constexpr` and `noexcept` | Yes | 0 |
3187(i) | C++20 | 20.10.7.2 [allocator.uses.construction] | P0591R4 reverted DR 2586 fixes to `scoped_allocator_adaptor::construct()` | Yes |  |
3321(i) | C++20 | 20.10.7.2 [allocator.uses.construction] | `uninitialized_construct_using_allocator` should use `construct_at` | Yes | 0 |
2284(i) | C++14 | 20.10.8 [allocator.traits] | Inconsistency in `allocator_traits::max_size` | Yes |  |
3665(i) | New | 20.10.8.2 [allocator.traits.types] | Is `std::allocator_traits<Alloc>::rebind_alloc` SFINAE-friendly? | No | 3 |
1318(i) | NAD | 20.10.8.2 [allocator.traits.types] | N2982 removes previous allocator capabilities | Yes |  | 1375
1285(i) | C++11 | 20.10.8.3 [allocator.traits.members] | `allocator_traits` call to `new` | Yes |  |
1286(i) | C++11 | 20.10.8.3 [allocator.traits.members] | `allocator_traits::select_on_container_copy_construction` type-o | Yes |  |
3170(i) | WP | 20.10.9 [default.allocator] | `is_always_equal` added to `std::allocator` makes the standard library treat derived types as always equal | Yes | 2 |
3035(i) | C++20 | 20.10.9 [default.allocator] | `std::allocator`'s constructors should be `constexpr` | Yes | 0 |
3307(i) | C++20 | 20.10.9 [default.allocator] | `std::allocator<void>().allocate(n)` | Yes | 0 |
2103(i) | C++14 | 20.10.9 [default.allocator] | `std::allocator_traits<std::allocator<T>>::propagate_on_container_move_assignment` | Yes |  |
1027(i) | NAD Concepts | 20.10.9 [default.allocator] | `std::allocator` needs to be a concept-constrained template | Yes |  |
3190(i) | C++20 | 20.10.9.2 [allocator.members] | `std::allocator::allocate` sometimes returns too little storage | Yes | 3 |
234(i) | CD1 | 20.10.9.2 [allocator.members] | Typos in allocator definition | Yes |  |
400(i) | CD1 | 20.10.9.2 [allocator.members] | redundant type cast in lib.allocator.members | Yes |  |
578(i) | CD1 | 20.10.9.2 [allocator.members] | purpose of hint to allocator::allocate() | Yes |  |
634(i) | CD1 | 20.10.9.2 [allocator.members] | `allocator.address()` doesn't work for types overloading `operator&` | Yes |  | 350
2089(i) | Resolved | 20.10.9.2 [allocator.members] | `std::allocator::construct` should use uniform initialization | Yes | 2 |
350(i) | Dup | 20.10.9.2 [allocator.members] | allocator<>::address | Yes |  | 634
2296(i) | C++17 | 20.10.10 [specialized.addressof] | `std::addressof` should be `constexpr` | Yes | 3 |
2598(i) | C++17 | 20.10.10 [specialized.addressof] | `addressof` works on temporaries | Yes | 3 |
970(i) | C++11 | 20.10.10 [specialized.addressof] | `addressof` overload unneeded | Yes |  |
2948(i) | C++20 | 20.11.1 [unique.ptr] | `unique_ptr` does not define `operator<<` for stream output | Yes | 0 |
673(i) | CD1 | 20.11.1 [unique.ptr] | `unique_ptr` update | Yes |  |
740(i) | CD1 | 20.11.1 [unique.ptr] | Please remove `*_ptr<T[N]>` | Yes |  |
762(i) | CD1 | 20.11.1 [unique.ptr] | `std::unique_ptr` requires complete type? | Yes |  |
1193(i) | C++11 | 20.11.1.2 [unique.ptr.dltr] | `default_delete` cannot be instantiated with incomplete types | Yes |  |
854(i) | C++11 | 20.11.1.2.2 [unique.ptr.dltr.dflt] | `default_delete` converting constructor underspecified | Yes |  |
1517(i) | C++11 | 20.11.1.2.2 [unique.ptr.dltr.dflt] | default_delete's default constructor should be trivial | Yes |  |
938(i) | C++11 | 20.11.1.2.3 [unique.ptr.dltr.dflt1] | `default_delete<T[]>::operator()` should only accept `T*` | Yes |  |
3159(i) | New | 20.11.1.3 [unique.ptr.single] | §[unique.ptr.single] requirements on deleter may be too strict | No | 3 |
2262(i) | Open | 20.11.1.3 [unique.ptr.single] | Requirement for `unique_ptr<T>::get_deleter()(p)` to be able to destroy the `unique_ptr` | Yes | 3 |
2361(i) | C++17 | 20.11.1.3 [unique.ptr.single] | Apply 2299 resolution throughout library | Yes |  |
1303(i) | C++11 | 20.11.1.3 [unique.ptr.single] | `shared_ptr`, `unique_ptr`, and rvalue references v2 | Yes |  |
834(i) | Resolved | 20.11.1.3 [unique.ptr.single] | `unique_ptr::pointer` requirements underspecified | Yes |  |
983(i) | Resolved | 20.11.1.3 [unique.ptr.single] | `unique_ptr` reference deleters should not be moved from | Yes |  |
3588(i) | NAD | 20.11.1.3.1 [unique.ptr.single.general] | Strike out purposeless UB involving the deleter in members functions of `unique_ptr` | Yes |  |
3632(i) | WP | 20.11.1.3.2 [unique.ptr.single.ctor] | `unique_ptr` "Mandates: This constructor is not selected by class template argument deduction" | Yes |  |
2944(i) | C++20 | 20.11.1.3.2 [unique.ptr.single.ctor] | LWG 2905 accidentally removed requirement that construction of the deleter doesn't throw an exception | Yes | 0 |
2801(i) | C++17 | 20.11.1.3.2 [unique.ptr.single.ctor] | Default-constructibility of `unique_ptr` | Yes | 2 |
2905(i) | C++17 | 20.11.1.3.2 [unique.ptr.single.ctor] | `is_constructible_v<unique_ptr<P, D>, P, D const &>` should be false when `D` is not copy constructible | Yes |  |
932(i) | Resolved | 20.11.1.3.2 [unique.ptr.single.ctor] | `unique_ptr(pointer p)` for pointer deleter types | Yes |  |
950(i) | Resolved | 20.11.1.3.2 [unique.ptr.single.ctor] | `unique_ptr` converting ctor shouldn't accept array form | Yes |  |
1100(i) | Resolved | 20.11.1.3.2 [unique.ptr.single.ctor] | `auto_ptr` to `unique_ptr` conversion | Yes |  |
3164(i) | NAD | 20.11.1.3.2 [unique.ptr.single.ctor] | Unhelpful "shall not participate" constraints for `unique_ptr` with reference deleter | Yes |  |
3455(i) | WP | 20.11.1.3.4 [unique.ptr.single.asgn] | Incorrect Postconditions on `unique_ptr` move assignment | Yes | 0 |
2047(i) | C++14 | 20.11.1.3.4 [unique.ptr.single.asgn] | Incorrect "mixed" move-assignment semantics of `unique_ptr` | Yes |  |
2246(i) | C++14 | 20.11.1.3.4 [unique.ptr.single.asgn] | `unique_ptr` assignment effects w.r.t. deleter | Yes |  |
1021(i) | C++11 | 20.11.1.3.4 [unique.ptr.single.asgn] | Allow `nullptr_t` assignments to `unique_ptr` | Yes |  |
2228(i) | Resolved | 20.11.1.3.4 [unique.ptr.single.asgn] | Missing SFINAE rule in `unique_ptr` templated assignment | Yes | 3 |
2762(i) | WP | 20.11.1.3.5 [unique.ptr.single.observers] | `unique_ptr operator*()` should be `noexcept` | Yes | 3 |
686(i) | NAD | 20.11.1.3.5 [unique.ptr.single.observers] | `unique_ptr` and `shared_ptr` fail to specify non-convertibility to int for unspecified-bool-type | Yes |  |
998(i) | C++11 | 20.11.1.3.6 [unique.ptr.single.modifiers] | Smart pointer referencing its owner | Yes |  |
806(i) | CD1 | 20.11.1.3.6 [unique.ptr.single.modifiers] | `unique_ptr::reset` effects incorrect, too permissive | Yes |  |
933(i) | NAD | 20.11.1.3.6 [unique.ptr.single.modifiers] | Unique_ptr defect | Yes |  |
2118(i) | Resolved | 20.11.1.4 [unique.ptr.runtime] | [CD] `unique_ptr` for array does not support cv qualification conversion of actual argument | Yes | 1 |
1293(i) | Resolved | 20.11.1.4 [unique.ptr.runtime] | `unique_ptr<T[], D>` needs to get rid of unspecified-pointer-type | Yes |  |
2060(i) | NAD Editorial | 20.11.1.4 [unique.ptr.runtime] | `unique_ptr<T[]>(nullptr_t)` missing `noexcept` | Yes |  |
2520(i) | C++17 | 20.11.1.4.2 [unique.ptr.runtime.ctor] | N4089 broke initializing `unique_ptr<T[]>` from a `nullptr` | Yes | 2 |
2169(i) | C++14 | 20.11.1.4.5 [unique.ptr.runtime.modifiers] | Missing `reset()` requirements in `unique_ptr` specialization | Yes |  |
821(i) | C++11 | 20.11.1.4.5 [unique.ptr.runtime.modifiers] | Minor cleanup : `unique_ptr` | Yes |  |
3426(i) | WP | 20.11.1.6 [unique.ptr.special] | `operator<=>(const unique_ptr<T, D>&, nullptr_t)` can't get no satisfaction | Yes | 0 |
1297(i) | Resolved | 20.11.1.6 [unique.ptr.special] | `unique_ptr`'s relational operator functions should induce a total order | Yes |  |
2376(i) | C++17 | 20.11.2 [util.smartptr.weak.bad] | `bad_weak_ptr::what()` overspecified | Yes |  |
2594(i) | New | 20.11.3 [util.smartptr.shared] | Contradicting definition of empty `shared_ptr` on `shared_ptr(nullptr, d)` | Yes | 3 |
2996(i) | C++20 | 20.11.3 [util.smartptr.shared] | Missing rvalue overloads for `shared_ptr` operations | Yes |  |
3018(i) | C++20 | 20.11.3 [util.smartptr.shared] | `shared_ptr` of function type | Yes | 3 |
2873(i) | C++17 | 20.11.3 [util.smartptr.shared] | Add `noexcept` to several `shared_ptr` related functions | Yes |  |
2365(i) | C++17 | 20.11.3 [util.smartptr.shared] | Missing `noexcept` in `shared_ptr::shared_ptr(nullptr_t)` | Yes |  |
2411(i) | C++17 | 20.11.3 [util.smartptr.shared] | `shared_ptr` is only contextually convertible to `bool` | Yes | 0 |
758(i) | C++11 | 20.11.3 [util.smartptr.shared] | `shared_ptr` and `nullptr` | Yes |  |
896(i) | C++11 | 20.11.3 [util.smartptr.shared] | Library thread safety issue | Yes |  |
541(i) | CD1 | 20.11.3 [util.smartptr.shared] | shared_ptr template assignment and void | Yes |  |
674(i) | CD1 | 20.11.3 [util.smartptr.shared] | `shared_ptr` interface changes for consistency with N1856 | Yes |  |
710(i) | CD1 | 20.11.3 [util.smartptr.shared] | Missing postconditions | Yes |  |
813(i) | CD1 | 20.11.3 [util.smartptr.shared] | "empty" undefined for `shared_ptr` | Yes |  |
2810(i) | Resolved | 20.11.3 [util.smartptr.shared] | `use_count` and `unique` in `shared_ptr` | Yes |  |
2864(i) | Resolved | 20.11.3 [util.smartptr.shared] | Merge `shared_ptr` changes from Library Fundamentals to C++17 | Yes |  |
1406(i) | NAD | 20.11.3 [util.smartptr.shared] | Support hashing smart-pointers based on owner | Yes |  |
1031(i) | NAD | 20.11.3 [util.smartptr.shared] | Need `shared_ptr` conversion to a `unique_ptr` | Yes |  |
2906(i) | New | 20.11.3.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 |
3548(i) | WP | 20.11.3.2 [util.smartptr.shared.const] | `shared_ptr` construction from `unique_ptr` should move (not copy) the deleter | Yes |  |
3233(i) | C++20 | 20.11.3.2 [util.smartptr.shared.const] | Broken requirements for `shared_ptr` converting constructors | Yes | 0 |
2802(i) | C++17 | 20.11.3.2 [util.smartptr.shared.const] | `shared_ptr` constructor requirements for a deleter | Yes | 2 |
2874(i) | C++17 | 20.11.3.2 [util.smartptr.shared.const] | Constructor `shared_ptr::shared_ptr(Y*)` should be constrained | Yes |  |
2875(i) | C++17 | 20.11.3.2 [util.smartptr.shared.const] | `shared_ptr::shared_ptr(Y*, D, […])` constructors should be constrained | Yes |  |
2876(i) | C++17 | 20.11.3.2 [util.smartptr.shared.const] | `shared_ptr::shared_ptr(const weak_ptr<Y>&)` constructor should be constrained | Yes |  |
2399(i) | C++17 | 20.11.3.2 [util.smartptr.shared.const] | `shared_ptr`'s constructor from `unique_ptr` should be constrained | Yes | 0 |
2415(i) | C++17 | 20.11.3.2 [util.smartptr.shared.const] | Inconsistency between `unique_ptr` and `shared_ptr` | Yes | 2 |
2495(i) | C++17 | 20.11.3.2 [util.smartptr.shared.const] | There is no such thing as an Exception Safety element | Yes | 0 |
2685(i) | C++17 | 20.11.3.2 [util.smartptr.shared.const] | `shared_ptr` deleters must not not throw on move construction | Yes | 0 |
881(i) | C++11 | 20.11.3.2 [util.smartptr.shared.const] | `shared_ptr` conversion issue | Yes |  |
925(i) | C++11 | 20.11.3.2 [util.smartptr.shared.const] | `shared_ptr`'s explicit conversion from `unique_ptr` | Yes |  |
687(i) | CD1 | 20.11.3.2 [util.smartptr.shared.const] | shared_ptr conversion constructor not constrained | Yes |  |
827(i) | Resolved | 20.11.3.2 [util.smartptr.shared.const] | `constexpr shared_ptr::shared_ptr()?` | Yes |  |
1407(i) | Resolved | 20.11.3.2 [util.smartptr.shared.const] | Synch `shared_ptr` constructors taking movable types | Yes |  |
2751(i) | New | 20.11.3.3 [util.smartptr.shared.dest] | `shared_ptr` deleter not specified to observe expired `weak_ptr` instances | No | 4 |
899(i) | C++11 | 20.11.3.3 [util.smartptr.shared.dest] | Adjusting `shared_ptr` for `nullptr_t` | Yes |  |
575(i) | CD1 | 20.11.3.3 [util.smartptr.shared.dest] | the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions | Yes |  |
2907(i) | NAD | 20.11.3.3 [util.smartptr.shared.dest] | Semantics for destroying the deleter and the control-block of a `shared_ptr` are unclear | Yes |  |
884(i) | Resolved | 20.11.3.5 [util.smartptr.shared.mod] | `shared_ptr` swap | Yes |  |
2434(i) | C++17 | 20.11.3.6 [util.smartptr.shared.obs] | `shared_ptr::use_count()` is efficient | Yes | 0 |
2572(i) | C++17 | 20.11.3.6 [util.smartptr.shared.obs] | The remarks for `shared_ptr::operator*` should apply to cv-qualified `void` as well | Yes | 0 |
711(i) | C++11 | 20.11.3.6 [util.smartptr.shared.obs] | Contradiction in empty `shared_ptr` | Yes |  |
540(i) | CD1 | 20.11.3.6 [util.smartptr.shared.obs] | shared_ptr<void>::operator*() | Yes |  |
542(i) | CD1 | 20.11.3.6 [util.smartptr.shared.obs] | shared_ptr observers | Yes |  |
2776(i) | Resolved | 20.11.3.6 [util.smartptr.shared.obs] | `shared_ptr unique()` and `use_count()` | Yes | 2 |
2337(i) | NAD | 20.11.3.6 [util.smartptr.shared.obs] | `shared_ptr operator*()` should not be `noexcept` | Yes | 2 |
3210(i) | New | 20.11.3.7 [util.smartptr.shared.create] | `allocate_shared` is inconsistent about removing `const` from the pointer passed to allocator `construct` and `destroy` | Yes | 3 |
3216(i) | New | 20.11.3.7 [util.smartptr.shared.create] | Rebinding the allocator before calling `construct`/`destroy` in `allocate_shared` | Yes | 3 |
3005(i) | C++20 | 20.11.3.7 [util.smartptr.shared.create] | Destruction order of arrays by `make_shared/allocate_shared` only recommended? | Yes | 0 |
3007(i) | C++20 | 20.11.3.7 [util.smartptr.shared.create] | `allocate_shared` should rebind allocator to cv-unqualified `value_type` for construction | Yes | 0 |
3008(i) | C++20 | 20.11.3.7 [util.smartptr.shared.create] | `make_shared` (sub)object destruction semantics are not specified | Yes | 2 |
2696(i) | C++17 | 20.11.3.7 [util.smartptr.shared.create] | Interaction between `make_shared` and `enable_shared_from_this` is underspecified | Yes | 2 |
2070(i) | Resolved | 20.11.3.7 [util.smartptr.shared.create] | `allocate_shared` should use `allocator_traits<A>::construct` | Yes | 2 |
3427(i) | WP | 20.11.3.8 [util.smartptr.shared.cmp] | `operator<=>(const shared_ptr<T>&, nullptr_t)` definition ill-formed | Yes | 0 |
2908(i) | C++17 | 20.11.3.8 [util.smartptr.shared.cmp] | The less-than operator for shared pointers could do more | Yes |  |
1262(i) | C++11 | 20.11.3.8 [util.smartptr.shared.cmp] | `std::less<std::shared_ptr<T>>` is underspecified | Yes |  |
743(i) | CD1 | 20.11.3.9 [util.smartptr.shared.spec] | rvalue `swap` for `shared_ptr` | Yes |  |
2964(i) | C++20 | 20.11.3.10 [util.smartptr.shared.cast] | Apparently redundant requirement for `dynamic_pointer_cast` | Yes | 0 |
2877(i) | Resolved | 20.11.3.10 [util.smartptr.shared.cast] | Strengthen meaning of "empty `shared_ptr<T>`" in `dynamic_pointer_cast` | Yes |  |
2400(i) | C++17 | 20.11.3.11 [util.smartptr.getdeleter] | `shared_ptr`'s `get_deleter()` should use `addressof()` | Yes | 0 |
533(i) | CD1 | 20.11.3.11 [util.smartptr.getdeleter] | typo in 2.2.3.10/1 | Yes |  |
545(i) | CD1 | 20.11.3.11 [util.smartptr.getdeleter] | When is a deleter deleted? | Yes |  |
741(i) | NAD | 20.11.3.11 [util.smartptr.getdeleter] | Const-incorrect `get_deleter` function for `shared_ptr` | Yes |  |
3001(i) | C++20 | 20.11.4 [util.smartptr.weak] | `weak_ptr::element_type` needs `remove_extent_t` | Yes | 0 |
2083(i) | C++14 | 20.11.4 [util.smartptr.weak] | const-qualification on `weak_ptr::owner_before` | Yes |  |
2315(i) | C++14 | 20.11.4 [util.smartptr.weak] | `weak_ptr` should be movable | Yes | 2 |
1256(i) | C++11 | 20.11.4 [util.smartptr.weak] | `weak_ptr` comparison functions should be removed | Yes |  |
3195(i) | WP | 20.11.4.2 [util.smartptr.weak.const] | What is the stored pointer value of an empty `weak_ptr`? | Yes | 2 |
2942(i) | C++20 | 20.11.4.6 [util.smartptr.weak.obs] | LWG 2873's resolution missed `weak_ptr::owner_before` | Yes |  |
2316(i) | C++14 | 20.11.4.6 [util.smartptr.weak.obs] | `weak_ptr::lock()` should be atomic | Yes | 0 |
1231(i) | C++11 | 20.11.4.6 [util.smartptr.weak.obs] | `weak_ptr` comparisons incompletely resolved | Yes |  |
949(i) | C++11 | 20.11.5 [util.smartptr.ownerless] | `owner_less` | Yes |  |
2529(i) | Resolved | 20.11.6 [util.smartptr.enab] | Assigning to `enable_shared_from_this::__weak_this` twice | Yes | 3 |
2179(i) | Resolved | 20.11.6 [util.smartptr.enab] | `enable_shared_from_this` and construction from raw pointers | Yes | 3 |
3594(i) | New | 20.11.10 [inout.ptr.t] | `inout_ptr` — inconsistent `release()` in destructor | Yes | 1 |
3471(i) | WP | 20.12 [mem.res] | `polymorphic_allocator::allocate` does not satisfy Cpp17Allocator requirements | Yes | 3 |
2700(i) | NAD | 20.12 [mem.res] | `resource_adaptor` went missing | Yes | 1 |
3637(i) | New | 20.12.2 [mem.res.class] | `pmr::memory_resource::do_allocate` needs clarification | No | 3 |
2724(i) | C++17 | 20.12.2 [mem.res.class] | The protected virtual member functions of `memory_resource` should be private | Yes | 4 |
2843(i) | C++20 | 20.12.2.3 [mem.res.private] | Unclear behavior of `std::pmr::memory_resource::do_allocate()` | Yes | 3 |
2701(i) | NAD Editorial | 20.12.2.3 [mem.res.private] | Unclear requirement in [memory.resource.private] | Yes | 3 |
3036(i) | WP | 20.12.3 [mem.poly.allocator.class] | `polymorphic_allocator::destroy` is extraneous | Yes | 3 |
3037(i) | C++20 | 20.12.3 [mem.poly.allocator.class] | `polymorphic_allocator` and incomplete types | Yes | 2 |
3304(i) | C++20 | 20.12.3 [mem.poly.allocator.class] | Allocate functions of `std::polymorphic_allocator` should require `[[nodiscard]]` | Yes | 3 |
3312(i) | Dup | 20.12.3 [mem.poly.allocator.class] | `polymorphic_allocator::allocate_object` and `new_object` should be `[[nodiscard]]` | Yes |  |
2969(i) | C++20 | 20.12.3.3 [mem.poly.allocator.mem] | `polymorphic_allocator::construct()` shouldn't pass `resource()` | Yes | 2 |
2975(i) | C++20 | 20.12.3.3 [mem.poly.allocator.mem] | Missing case for `pair` construction in scoped and polymorphic allocators | Yes | 3 |
3038(i) | C++20 | 20.12.3.3 [mem.poly.allocator.mem] | `polymorphic_allocator::allocate` should not allow integer overflow to create vulnerabilities | Yes | 2 |
3237(i) | C++20 | 20.12.3.3 [mem.poly.allocator.mem] | LWG 3038 and 3190 have inconsistent PRs | Yes | 2 |
3310(i) | C++20 | 20.12.3.3 [mem.poly.allocator.mem] | Replace `SIZE_MAX` with `numeric_limits<size_t>::max()` | Yes | 0 |
3113(i) | Resolved | 20.12.3.3 [mem.poly.allocator.mem] | `polymorphic_allocator::construct()` should more closely match `scoped_allocator_adaptor::construct()` | Yes | 3 |
3634(i) | New | 20.12.4 [mem.res.global] | When are static-duration `memory_resource` objects destroyed? | No | 3 |
2961(i) | C++20 | 20.12.4 [mem.res.global] | Bad postcondition for `set_default_resource` | Yes |  |
2848(i) | New | 20.12.5.2 [mem.res.pool.options] | Pass-through threshold for pool allocator | No | 3 |
3143(i) | WP | 20.12.6 [mem.res.monotonic.buffer] | `monotonic_buffer_resource` growth policy is unclear | Yes | 2 |
3120(i) | WP | 20.12.6.3 [mem.res.monotonic.buffer.mem] | Unclear behavior of `monotonic_buffer_resource::release()` | Yes | 2 |
3000(i) | C++20 | 20.12.6.3 [mem.res.monotonic.buffer.mem] | `monotonic_memory_resource::do_is_equal` uses `dynamic_cast` unnecessarily | Yes | 0 |
1316(i) | C++11 | 20.13 [allocator.adaptor] | `scoped_allocator_adaptor operator==` has no definition | Yes |  |
1405(i) | Resolved | 20.13 [allocator.adaptor] | Move `scoped_allocator_adaptor` into separate header | Yes |  |
2476(i) | C++17 | 20.13.1 [allocator.adaptor.syn] | `scoped_allocator_adaptor` is not assignable | Yes | 0 |
2782(i) | C++17 | 20.13.3 [allocator.adaptor.cnstr] | `scoped_allocator_adaptor` constructors must be constrained | Yes | 0 |
3116(i) | C++20 | 20.13.4 [allocator.adaptor.members] | `OUTERMOST_ALLOC_TRAITS` needs `remove_reference_t` | Yes | 0 |
2586(i) | C++17 | 20.13.4 [allocator.adaptor.members] | Wrong value category used in `scoped_allocator_adaptor::construct()` | Yes | 0 |
2203(i) | C++14 | 20.13.4 [allocator.adaptor.members] | `scoped_allocator_adaptor` uses wrong argument types for piecewise construction | Yes |  |
2511(i) | Resolved | 20.13.4 [allocator.adaptor.members] | `scoped_allocator_adaptor` piecewise construction does not require `CopyConstructible` | Yes | 3 |
1321(i) | Resolved | 20.13.4 [allocator.adaptor.members] | `scoped_allocator_adaptor construct` and `destroy` don't use `allocator_traits` | Yes |  |
2717(i) | NAD | 20.13.4 [allocator.adaptor.members] | `scoped_allocator_adaptor` uses `forward` to do `move`'s job | Yes |  |
2048(i) | C++14 | 20.14 [function.objects] | Unnecessary `mem_fn` overloads | Yes |  |
2149(i) | C++14 | 20.14 [function.objects] | Concerns about 20.8/5 | Yes |  |
185(i) | CD1 | 20.14 [function.objects] | Questionable use of term "inline" | Yes |  |
660(i) | CD1 | 20.14 [function.objects] | Missing Bitwise Operations | Yes |  |
1290(i) | Resolved | 20.14 [function.objects] | Don't require `[u|bi]nary_function` inheritance | Yes |  |
658(i) | Resolved | 20.14 [function.objects] | Two unspecified function comparators in [function.objects] | Yes |  |
1397(i) | Resolved | 20.14 [function.objects] | Deprecate '98 binders | Yes |  |
351(i) | NAD Editorial | 20.14 [function.objects] | unary_negate and binary_negate: struct or class? | Yes |  |
1398(i) | NAD | 20.14 [function.objects] | Users should be able to specialize functors without depending on whole `<functional>` header | Yes |  |
3202(i) | C++20 | 20.14.2 [functional.syn] | P0318R1 was supposed to be revised | Yes | 0 |
3655(i) | New | 20.14.4 [func.require] | The `INVOKE` operation and `union` types | No | 3 |
2219(i) | C++17 | 20.14.4 [func.require] | `INVOKE`-ing a pointer to member with a `reference_wrapper` as the object expression | Yes | 2 |
2387(i) | C++17 | 20.14.4 [func.require] | More nested types that must be accessible and unambiguous | Yes |  |
2486(i) | C++17 | 20.14.4 [func.require] | `mem_fn()` should be required to use perfect forwarding | Yes | 0 |
1294(i) | C++11 | 20.14.4 [func.require] | Difference between callable wrapper and forwarding call wrapper unclear | Yes |  |
1295(i) | C++11 | 20.14.4 [func.require] | Contradictory call wrapper requirements | Yes |  |
1520(i) | C++11 | 20.14.4 [func.require] | `INVOKE` on member data pointer with too many arguments | Yes |  |
2926(i) | Resolved | 20.14.4 [func.require] | `INVOKE(f, t1, t2,... tN)` and `INVOKE(f, t1, t2,... tN, R)` are too similar | Yes |  |
2807(i) | C++17 | 20.14.5 [func.invoke] | `std::invoke` should use `std::is_nothrow_callable` | Yes | 3 |
2690(i) | Resolved | 20.14.5 [func.invoke] | `invoke<R>` | Yes |  |
2894(i) | Resolved | 20.14.5 [func.invoke] | The function template `std::apply()` is required to be `constexpr`, but `std::invoke()` isn't | Yes | 3 |
3046(i) | New | 20.14.6 [refwrap] | Do not require `reference_wrapper` to support non-referenceable function types | Yes | 3 |
2981(i) | C++20 | 20.14.6 [refwrap] | Remove redundant deduction guides from standard library | Yes | 0 |
2993(i) | C++20 | 20.14.6 [refwrap] | `reference_wrapper<T>` conversion from `T&&` | Yes | 3 |
987(i) | C++11 | 20.14.6 [refwrap] | `reference_wrapper` and function types | Yes |  |
2017(i) | C++11 | 20.14.6 [refwrap] | `std::reference_wrapper` makes incorrect usage of `std::result_of` | Yes |  |
2022(i) | C++11 | 20.14.6 [refwrap] | `reference_wrapper<T>::result_type` is underspecified | Yes |  |
521(i) | CD1 | 20.14.6 [refwrap] | Garbled requirements for argument_type in reference_wrapper | Yes |  |
3041(i) | C++20 | 20.14.6.2 [refwrap.const] | Unnecessary `decay` in `reference_wrapper` | Yes | 0 |
688(i) | C++11 | 20.14.6.2 [refwrap.const] | reference_wrapper, cref unsafe, allow binding to rvalues | Yes |  |
689(i) | CD1 | 20.14.6.2 [refwrap.const] | reference_wrapper constructor overly constrained | Yes |  |
2435(i) | C++17 | 20.14.6.5 [refwrap.invoke] | `reference_wrapper::operator()`'s Remark should be deleted | Yes | 4 |
3146(i) | WP | 20.14.6.6 [refwrap.helpers] | Excessive unwrapping in `std::ref`/`cref` | Yes | 3 |
2491(i) | New | 20.14.8 [comparisons] | `std::less<T*>` in constant expression | Yes | 3 |
2547(i) | New | 20.14.8 [comparisons] | Container requirements (and other library text) should say "strict total order", not just "total order" | No | 3 |
2450(i) | C++17 | 20.14.8 [comparisons] | `(greater|less|greater_equal|less_equal)<void>` do not yield a total order for pointers | Yes | 2 |
2562(i) | C++17 | 20.14.8 [comparisons] | Consistent total ordering of pointers by comparison functors | Yes | 3 |
284(i) | CD1 | 20.14.8 [comparisons] | unportable example in 20.3.7, p6 | Yes |  |
3530(i) | WP | 20.14.8.8 [comparisons.three.way] | `BUILTIN-PTR-MEOW` should not opt the type out of syntactic checks | Yes |  |
297(i) | CD1 | 20.14.10 [logical.operations] | const_mem_fun_t<>::argument_type should be const T* | Yes |  |
2767(i) | C++17 | 20.14.13 [func.not.fn] | `not_fn call_wrapper` can form invalid types | Yes | 0 |
3184(i) | C++20 | 20.14.14 [func.bind.front] | Inconsistencies in `bind_front` wording | Yes | 0 |
520(i) | CD1 | 20.14.15 [func.bind] | Result_of and pointers to data members | Yes |  |
2010(i) | C++14 | 20.14.15.2 [func.bind.isbind] | `is_* traits` for binding operations can't be meaningfully specialized | Yes |  |
1071(i) | C++11 | 20.14.15.2 [func.bind.isbind] | `is_bind_expression` should derive from `integral_constant<bool>` | Yes |  |
2487(i) | C++17 | 20.14.15.4 [func.bind.bind] | `bind()` should be `const`-overloaded, not cv-overloaded | Yes | 2 |
2545(i) | C++17 | 20.14.15.4 [func.bind.bind] | Simplify wording for `bind` without explicitly specified return type | Yes | 3 |
2021(i) | C++14 | 20.14.15.4 [func.bind.bind] | Further incorrect usages of `result_of` | Yes |  |
817(i) | C++11 | 20.14.15.4 [func.bind.bind] | `bind` needs to be moved | Yes |  |
527(i) | CD1 | 20.14.15.4 [func.bind.bind] | `tr1::bind` has lost its Throws clause | Yes |  |
2957(i) | Resolved | 20.14.15.4 [func.bind.bind] | `bind`'s specification doesn't apply the cv-qualification of the call wrapper to the callable object | Yes | 3 |
816(i) | Resolved | 20.14.15.4 [func.bind.bind] | Should `bind()`'s returned functor have a nofail copy ctor when `bind()` is nofail? | Yes |  |
2488(i) | C++17 | 20.14.15.5 [func.bind.place] | Placeholders should be allowed and encouraged to be `constexpr` | Yes | 2 |
2489(i) | C++17 | 20.14.16 [func.memfn] | `mem_fn()` should be `noexcept` | Yes | 0 |
920(i) | C++11 | 20.14.16 [func.memfn] | Ref-qualification support in the library | Yes |  | 1230
3023(i) | Resolved | 20.14.16 [func.memfn] | Clarify unspecified call wrappers | Yes | 3 |
1230(i) | Dup | 20.14.16 [func.memfn] | `mem_fn` and variadic templates | Yes |  | 920
770(i) | CD1 | 20.14.17 [func.wrap] | std::function should use rvalue swap | Yes |  |
2233(i) | C++17 | 20.14.17.2 [func.wrap.badcall] | `bad_function_call::what()` unhelpful | Yes | 3 |
2062(i) | C++17 | 20.14.17.3 [func.wrap.func] | Effect contradictions w/o no-throw guarantee of `std::function` swaps | Yes | 2 |
2385(i) | C++17 | 20.14.17.3 [func.wrap.func] | `function::assign` allocator argument doesn't make sense | Yes | 2 |
2393(i) | C++17 | 20.14.17.3 [func.wrap.func] | `std::function`'s Callable definition is broken | Yes | 2 |
2401(i) | C++17 | 20.14.17.3 [func.wrap.func] | `std::function` needs more `noexcept` | Yes | 0 |
2420(i) | C++17 | 20.14.17.3 [func.wrap.func] | `function<void(ArgTypes...)>` does not discard the return value of the target object | Yes | 1 |
1070(i) | C++11 | 20.14.17.3 [func.wrap.func] | Ambiguous move overloads in function | Yes |  |
1240(i) | C++11 | 20.14.17.3 [func.wrap.func] | Deleted comparison functions of `std::function` not needed | Yes |  |
1399(i) | C++11 | 20.14.17.3 [func.wrap.func] | `function` does not need an `explicit` default constructor | Yes |  |
769(i) | CD1 | 20.14.17.3 [func.wrap.func] | std::function should use nullptr_t instead of "unspecified-null-pointer-type" | Yes |  |
2370(i) | Resolved | 20.14.17.3 [func.wrap.func] | Operations involving type-erased allocators should not be `noexcept` in `std::function` | Yes | 3 |
2501(i) | Resolved | 20.14.17.3 [func.wrap.func] | `std::function` requires POCMA/POCCA | Yes | 3 |
2502(i) | Resolved | 20.14.17.3 [func.wrap.func] | `std::function` does not use `allocator::construct` | Yes | 3 |
1023(i) | NAD Editorial | 20.14.17.3 [func.wrap.func] | Unclear inheritance relation for `std::function` | Yes |  |
644(i) | NAD | 20.14.17.3 [func.wrap.func] | Possible typos in 'function' description | Yes |  |
1024(i) | NAD Concepts | 20.14.17.3 [func.wrap.func] | `std::function` constructors overly generous | Yes |  |
1059(i) | NAD Concepts | 20.14.17.3 [func.wrap.func] | Usage of no longer existing FunctionType concept | Yes |  |
3617(i) | New | 20.14.17.3.2 [func.wrap.func.con] | `function`/`packaged_task` deduction guides and deducing `this` | Yes | 2 |
3493(i) | New | 20.14.17.3.2 [func.wrap.func.con] | The constructor of `std::function` taking an `F` is missing a constraint | Yes | 3 |
2813(i) | EWG | 20.14.17.3.2 [func.wrap.func.con] | `std::function` should not return dangling references | Yes | 2 |
2774(i) | WP | 20.14.17.3.2 [func.wrap.func.con] | `std::function` construction vs assignment | Yes | 3 |
3238(i) | C++20 | 20.14.17.3.2 [func.wrap.func.con] | Insufficiently-defined behavior of `std::function` deduction guides | Yes |  |
2850(i) | C++17 | 20.14.17.3.2 [func.wrap.func.con] | `std::function` move constructor does unnecessary work | Yes | 0 |
2565(i) | C++17 | 20.14.17.3.2 [func.wrap.func.con] | `std::function`'s move constructor should guarantee nothrow for `reference_wrapper`s and function pointers | Yes | 0 |
2781(i) | C++17 | 20.14.17.3.2 [func.wrap.func.con] | Contradictory requirements for `std::function` and `std::reference_wrapper` | Yes | 0 |
2132(i) | C++14 | 20.14.17.3.2 [func.wrap.func.con] | `std::function` ambiguity | Yes | 2 |
1287(i) | C++11 | 20.14.17.3.2 [func.wrap.func.con] | `std::function` requires `CopyConstructible` target object | Yes |  |
1288(i) | C++11 | 20.14.17.3.2 [func.wrap.func.con] | `std::function` assignment from rvalues | Yes |  |
1292(i) | C++11 | 20.14.17.3.2 [func.wrap.func.con] | `std::function` should support all callable types | Yes |  |
1400(i) | C++11 | 20.14.17.3.2 [func.wrap.func.con] | FCD `function` does not need an `explicit` default constructor | Yes |  |
610(i) | CD1 | 20.14.17.3.2 [func.wrap.func.con] | Suggested non-normative note for C++0x | Yes |  |
2386(i) | NAD | 20.14.17.3.2 [func.wrap.func.con] | `function::operator=` handles allocators incorrectly | Yes | 1 |
1258(i) | Resolved | 20.14.17.3.3 [func.wrap.func.mod] | std::function Effects clause impossible to satisfy | Yes |  |
1333(i) | C++11 | 20.14.17.3.5 [func.wrap.func.inv] | Missing forwarding during `std::function` invocation | Yes |  |
815(i) | Resolved | 20.14.17.3.5 [func.wrap.func.inv] | `std::function` and `reference_closure` do not use perfect forwarding | Yes |  |
2591(i) | C++17 | 20.14.17.3.6 [func.wrap.func.targ] | `std::function`'s member template `target()` should not lead to undefined behaviour | Yes | 3 |
633(i) | NAD Editorial | 20.14.17.3.6 [func.wrap.func.targ] | Return clause mentions undefined "type()" | Yes |  |
3680(i) | New | 20.14.17.4.3 [func.wrap.move.ctor] | Constructor of `move_only_function` with empty `ref`-qualifier is over-constrained | Yes | 2 |
3642(i) | New | 20.14.17.4.3 [func.wrap.move.ctor] | `move_only_function` assignment operators seem to be defined suboptimal | Yes | 3 |
3512(i) | New | 20.14.19 [unord.hash] | Incorrect exception safety guarantee for unordered containers | No | 3 |
1025(i) | NAD Future | 20.14.19 [unord.hash] | The library should provide more specializations for `std::hash` | Yes |  |
2119(i) | C++17 | 20.14.19 [unord.hash] | Missing `hash` specializations for extended integer types | Yes | 3 |
2148(i) | C++14 | 20.14.19 [unord.hash] | Hashing enums should be supported directly by `std::hash` | Yes |  |
978(i) | C++11 | 20.14.19 [unord.hash] | Hashing smart pointers | Yes |  |
1182(i) | C++11 | 20.14.19 [unord.hash] | Unfortunate hash dependencies | Yes |  |
1245(i) | C++11 | 20.14.19 [unord.hash] | `std::hash<string>` & co | Yes |  |
848(i) | CD1 | 20.14.19 [unord.hash] | Missing `std::hash` specializations for `std::bitset/std::vector<bool>` | Yes |  |
2803(i) | Resolved | 20.14.19 [unord.hash] | `hash` for arithmetic, pointer and standard library types should not throw | Yes | 3 |
2817(i) | Resolved | 20.14.19 [unord.hash] | `std::hash` for `nullptr_t` | Yes |  |
2543(i) | Resolved | 20.14.19 [unord.hash] | LWG 2148 (hash support for enum types) seems under-specified | Yes | 2 |
1317(i) | NAD | 20.14.19 [unord.hash] | make_hash | Yes |  |
1072(i) | NAD Concepts | 20.14.19 [unord.hash] | Is `std::hash` a constrained template or not? | Yes |  |
2290(i) | Open | 20.15 [meta] | Top-level "SFINAE"-based constraints should get a separate definition in Clause 17 | Yes | 3 |
2452(i) | Core | 20.15 [meta] | `is_constructible`, etc. and default arguments | No | 3 |
2582(i) | C++17 | 20.15 [meta] | §[res.on.functions]/2's prohibition against incomplete types shouldn't apply to type traits | Yes | 0 |
1114(i) | C++11 | 20.15 [meta] | Type traits underspecified | Yes |  |
2040(i) | Resolved | 20.15 [meta] | Missing type traits related to `is_convertible` | Yes |  |
719(i) | Resolved | 20.15 [meta] | `std::is_literal` type traits should be provided | Yes |  | 750
1390(i) | Resolved | 20.15 [meta] | Limit speculative compilation for constructible/convertible traits | Yes |  |
1391(i) | Resolved | 20.15 [meta] | constructible/convertible traits and access control | Yes |  |
590(i) | NAD Editorial | 20.15 [meta] | Type traits implementation latitude should be removed for C++0x | Yes |  |
1120(i) | NAD | 20.15 [meta] | New type trait - `remove_all` | Yes |  |
1018(i) | NAD Concepts | 20.15 [meta] | Trait specifications should be expressed in terms of concepts | Yes |  |
2845(i) | New | 20.15.2 [meta.rqmts] | `enable_if`, `result_of`, `common_type` and `aligned_storage` do not meet the definition of `TransformationTrait` | No | 3 |
2514(i) | C++17 | 20.15.2 [meta.rqmts] | Type traits must not be `final` | Yes | 3 |
3099(i) | New | 20.15.3 [meta.type.synop] | `is_assignable<Incomplete&, Incomplete&>` | Yes | 2 |
2939(i) | New | 20.15.3 [meta.type.synop] | Some type-completeness constraints of traits are overspecified | No | 2 |
2922(i) | LEWG | 20.15.3 [meta.type.synop] | The `*_constant<>` templates do not make use of `template<auto>` | No |  |
2581(i) | C++17 | 20.15.3 [meta.type.synop] | Specialization of `<type_traits>` variable templates should be prohibited | Yes | 0 |
2928(i) | Resolved | 20.15.3 [meta.type.synop] | `is_callable` is not a good name | Yes |  |
2797(i) | Resolved | 20.15.3 [meta.type.synop] | Trait precondition violations | Yes | 2 |
2927(i) | Resolved | 20.15.3 [meta.type.synop] | Encoding a functor and argument types as a function signature for `is_callable` and `result_of` is fragile | Yes |  |
2871(i) | NAD | 20.15.3 [meta.type.synop] | User specializations of type traits should be ill-formed | Yes |  |
2910(i) | Dup | 20.15.3 [meta.type.synop] | Template deduction and `integral_constant` | Yes |  |
2346(i) | C++14 | 20.15.4 [meta.help] | `integral_constant`'s member functions should be marked `noexcept` | Yes | 0 |
1019(i) | C++11 | 20.15.4 [meta.help] | Make `integral_constant` objects useable in integral-constant-expressions | Yes |  |
1202(i) | NAD | 20.15.4 [meta.help] | `integral_constant` needs a spring clean | Yes |  |
1092(i) | NAD Concepts | 20.15.4 [meta.help] | Class template `integral_constant` should be a constrained template | Yes |  |
2015(i) | C++14 | 20.15.5 [meta.unary] | Incorrect pre-conditions for some type traits | Yes |  |
525(i) | Resolved | 20.15.5 [meta.unary] | type traits definitions not clear | Yes |  |
1392(i) | Resolved | 20.15.5 [meta.unary] | `result_of` should support pointer-to-data-member | Yes |  |
2247(i) | C++14 | 20.15.5.2 [meta.unary.cat] | Type traits and `std::nullptr_t` | Yes |  |
2827(i) | New | 20.15.5.4 [meta.unary.prop] | `is_trivially_constructible` and non-trivial destructors | No | 3 |
2496(i) | New | 20.15.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(i) | Open | 20.15.5.4 [meta.unary.prop] | `is_nothrow_constructible` and destructors | No | 3 |
2358(i) | Open | 20.15.5.4 [meta.unary.prop] | Apparently-bogus definition of `is_empty` type trait | Yes | 3 |
2077(i) | Open | 20.15.5.4 [meta.unary.prop] | Further incomplete constraints for type traits | No | 3 |
3486(i) | LEWG | 20.15.5.4 [meta.unary.prop] | `is_constructible<T[], T...>` may be misleading in C++20 | No |  |
2972(i) | C++20 | 20.15.5.4 [meta.unary.prop] | What is `is_trivially_destructible_v<int>`? | Yes |  |
3354(i) | C++20 | 20.15.5.4 [meta.unary.prop] | `has_strong_structural_equality` has a meaningless definition | Yes | 1 |
2911(i) | C++17 | 20.15.5.4 [meta.unary.prop] | An `is_aggregate` type trait is needed | Yes |  |
2336(i) | C++17 | 20.15.5.4 [meta.unary.prop] | `is_trivially_constructible/is_trivially_assignable` traits are always false | Yes | 3 |
2367(i) | C++17 | 20.15.5.4 [meta.unary.prop] | `pair` and `tuple` are not correctly implemented for `is_constructible` with no args | Yes | 3 |
2560(i) | C++17 | 20.15.5.4 [meta.unary.prop] | `is_constructible` underspecified when applied to a function type | Yes | 0 |
2738(i) | C++17 | 20.15.5.4 [meta.unary.prop] | `is_constructible` with `void` types | Yes |  |
2049(i) | C++14 | 20.15.5.4 [meta.unary.prop] | `is_destructible` is underspecified | Yes |  |
2196(i) | C++14 | 20.15.5.4 [meta.unary.prop] | Specification of `is_*[copy/move]_[constructible/assignable]` unclear for non-referencable types | Yes |  |
2197(i) | C++14 | 20.15.5.4 [meta.unary.prop] | Specification of `is_[un]signed` unclear for non-arithmetic types | Yes |  |
2298(i) | C++14 | 20.15.5.4 [meta.unary.prop] | [CD] `is_nothrow_constructible` is always false because of `create<>` | Yes |  |
931(i) | C++11 | 20.15.5.4 [meta.unary.prop] | type trait `extent<T, I>` | Yes |  |
1131(i) | C++11 | 20.15.5.4 [meta.unary.prop] | C++0x does not need `alignment_of` | Yes |  |
749(i) | CD1 | 20.15.5.4 [meta.unary.prop] | Currently `has_nothrow_copy_constructor<T>::value` is true if `T` has 'a' nothrow copy constructor. | Yes |  |
1174(i) | Resolved | 20.15.5.4 [meta.unary.prop] | Type property predicates | Yes |  |
1260(i) | Resolved | 20.15.5.4 [meta.unary.prop] | `is_constructible<int*,void*>` reports true | Yes |  |
1393(i) | Resolved | 20.15.5.4 [meta.unary.prop] | Trivial traits imply `noexcept` | Yes |  |
1394(i) | Resolved | 20.15.5.4 [meta.unary.prop] | `is_constructible` reports false positives | Yes |  |
2828(i) | NAD Editorial | 20.15.5.4 [meta.unary.prop] | Clarify `<cstdalign>` (following adoption of P0063r3) | Yes |  |
1239(i) | NAD Editorial | 20.15.5.4 [meta.unary.prop] | Defect report | Yes |  |
747(i) | NAD | 20.15.5.4 [meta.unary.prop] | We have 3 separate type traits to identify classes supporting no-throw operations | Yes |  |
748(i) | NAD | 20.15.5.4 [meta.unary.prop] | The is_abstract type trait is defined by reference to 10.4. | Yes |  |
1228(i) | NAD | 20.15.5.4 [meta.unary.prop] | User-specialized nothrow type traits | Yes |  |
2317(i) | C++14 | 20.15.6 [meta.unary.prop.query] | The type property queries should be `UnaryTypeTraits` returning `size_t` | Yes | 0 |
3400(i) | New | 20.15.7 [meta.rel] | Does `is_nothrow_convertible` consider destruction of the destination type? | No | 3 |
3174(i) | New | 20.15.7 [meta.rel] | Precondition on `is_convertible` is too strong | Yes | 3 |
975(i) | C++11 | 20.15.7 [meta.rel] | `is_convertible` cannot be instantiated for non-convertible types | Yes |  |
2895(i) | Resolved | 20.15.7 [meta.rel] | Passing function types to `result_of` and `is_callable` | Yes |  |
3022(i) | Resolved | 20.15.7 [meta.rel] | `is_convertible<derived*, base*>` may lead to ODR | Yes | 2 |
1395(i) | NAD Editorial | 20.15.7 [meta.rel] | Inconsistent reference links should be unified | Yes |  |
750(i) | Dup | 20.15.7 [meta.rel] | The current definition for `is_convertible` requires that the type be implicitly convertible, so explicit constructors are ignored. | Yes |  | 719
2101(i) | C++17 | 20.15.8 [meta.trans] | Some transformation types can produce impossible types | Yes | 3 |
3205(i) | New | 20.15.8.7 [meta.trans.other] | `decay_t` in the new `common_type` fallback should be `remove_cvref_t` | Yes | 3 |
3152(i) | WP | 20.15.8.7 [meta.trans.other] | `common_type` and `common_reference` have flaws in common | Yes | 3 |
2979(i) | C++20 | 20.15.8.7 [meta.trans.other] | `aligned_union` should require complete object types | Yes | 0 |
3034(i) | C++20 | 20.15.8.7 [meta.trans.other] | P0767R1 breaks previously-standard-layout types | Yes | 0 |
3140(i) | C++20 | 20.15.8.7 [meta.trans.other] | `COMMON_REF` is unimplementable as specified | Yes | 0 |
3380(i) | C++20 | 20.15.8.7 [meta.trans.other] | `common_type` and comparison categories | Yes | 0 |
2396(i) | C++17 | 20.15.8.7 [meta.trans.other] | `underlying_type` doesn't say what to do for an incomplete enumeration type | Yes | 0 |
2408(i) | C++17 | 20.15.8.7 [meta.trans.other] | SFINAE-friendly `common_type/iterator_traits` is missing in C++14 | Yes |  |
2460(i) | C++17 | 20.15.8.7 [meta.trans.other] | LWG issue 2408 and value categories | Yes | 2 |
2141(i) | C++14 | 20.15.8.7 [meta.trans.other] | `common_type` trait produces reference types | Yes |  |
1187(i) | C++11 | 20.15.8.7 [meta.trans.other] | `std::decay` | Yes |  |
705(i) | CD1 | 20.15.8.7 [meta.trans.other] | type-trait `decay` incompletely specified | Yes |  |
856(i) | CD1 | 20.15.8.7 [meta.trans.other] | Removal of `aligned_union` | Yes |  |
2465(i) | Resolved | 20.15.8.7 [meta.trans.other] | SFINAE-friendly `common_type` is nearly impossible to specialize correctly and regresses key functionality | Yes | 2 |
2763(i) | Resolved | 20.15.8.7 [meta.trans.other] | `common_type_t<void, void>` is undefined | Yes | 2 |
1055(i) | Resolved | 20.15.8.7 [meta.trans.other] | Provide a trait that returns the underlying type of an enumeration type | Yes |  |
2397(i) | Resolved | 20.15.8.7 [meta.trans.other] | `map<K, V>::emplace` and explicit `V` constructors | Yes | 1 |
849(i) | NAD | 20.15.8.7 [meta.trans.other] | missing type traits to compute root class and derived class of types in a class hierachy | Yes |  |
1020(i) | NAD | 20.15.8.7 [meta.trans.other] | Restore `aligned_union` | Yes |  |
2569(i) | C++17 | 20.15.9 [meta.logical] | `conjunction` and `disjunction` requirements are too strict | Yes | 2 |
2587(i) | C++17 | 20.15.9 [meta.logical] | "Convertible to `bool`" requirement in `conjunction` and `disjunction` | Yes | 3 |
2557(i) | C++17 | 20.15.9 [meta.logical] | Logical operator traits are broken in the zero-argument case | Yes | 0 |
2567(i) | C++17 | 20.15.9 [meta.logical] | Specification of logical operator traits uses `BaseCharacteristic`, which is defined only for `UnaryTypeTraits` and `BinaryTypeTraits` | Yes | 2 |
921(i) | C++11 | 20.16.3 [ratio.ratio] | Rational Arithmetic should use template aliases | Yes |  |
1388(i) | C++11 | 20.16.3 [ratio.ratio] | LWG 1281 incorrectly accepted | Yes |  |
1122(i) | Resolved | 20.16.3 [ratio.ratio] | Ratio values should be `constexpr` | Yes |  |
1281(i) | Resolved | 20.16.3 [ratio.ratio] | CopyConstruction and Assignment between ratios having the same normalized form | Yes |  |
948(i) | C++11 | 20.16.4 [ratio.arithmetic] | `ratio` arithmetic tweak | Yes |  |
1389(i) | Resolved | 20.16.4 [ratio.arithmetic] | Compile-time rational arithmetic and overflow | Yes |  |
1121(i) | NAD | 20.16.4 [ratio.arithmetic] | Support for multiple arguments | Yes |  |
2144(i) | C++14 | 20.17 [type.index] | Missing `noexcept` specification in `type_index` | Yes |  |
1078(i) | NAD Concepts | 20.17 [type.index] | DE-17: Remove class type_index | Yes |  |
2909(i) | NAD | 20.18.3 [execpol.type] | User specializations of `is_execution_policy` should be ill-formed | Yes |  |
3266(i) | C++20 | 20.19.1 [charconv.syn] | `to_chars(bool)` should be deleted | Yes | 0 |
3373(i) | C++20 | 20.19.1 [charconv.syn] | `{to,from}_chars_result` and `format_to_n_result` need the "we really mean what we say" wording | Yes | 0 |
3456(i) | New | 20.19.3 [charconv.from.chars] | Pattern used by `std::from_chars` is underspecified | Yes | 3 |
3081(i) | Open | 20.19.3 [charconv.from.chars] | Floating point `from_chars` API does not distinguish between overflow and underflow | Yes | 2 |
3082(i) | Open | 20.19.3 [charconv.from.chars] | `from_chars` specification regarding floating point rounding is inconsistent | Yes | 2 |
3080(i) | C++20 | 20.19.3 [charconv.from.chars] | Floating point `from_chars` pattern specification breaks round-tripping | Yes | 0 |
3651(i) | New | 20.20 [format] | Unspecified lifetime guarantees for the format string | No | 3 |
3641(i) | New | 20.20.1 [format.syn] | Add `operator==` to `format_to_n_result` | Yes | 3 |
3243(i) | C++20 | 20.20.2 [format.string] | `std::format` and negative zeroes | Yes | 2 |
3251(i) | C++20 | 20.20.2 [format.string] | Are `std::format` alignment specifiers applied to string arguments? | Yes | 2 |
3586(i) | New | 20.20.2.2 [format.string.std] | Formatting character alignment inconsistencies | Yes | 2 |
3644(i) | New | 20.20.2.2 [format.string.std] | `std::format` does not define "integer presentation type" | Yes | 2 |
3412(i) | New | 20.20.2.2 [format.string.std] | §[format.string.std] references to "Unicode encoding" unclear | No | 3 |
3639(i) | SG16 | 20.20.2.2 [format.string.std] | Handling of fill character width is underspecified in `std::format` | No | 3 |
3576(i) | SG16 | 20.20.2.2 [format.string.std] | Clarifying fill character in `std::format` | Yes | 2 |
3612(i) | WP | 20.20.2.2 [format.string.std] | Inconsistent pointer alignment in `std::format` | Yes |  |
3648(i) | WP | 20.20.2.2 [format.string.std] | `format` should not print `bool` with `'c'` | Yes |  |
3242(i) | C++20 | 20.20.2.2 [format.string.std] | `std::format`: missing rules for `arg-id` in `width` and `precision` | Yes | 1 |
3248(i) | C++20 | 20.20.2.2 [format.string.std] | `std::format` `#b`, `#B`, `#o`, `#x`, and `#X` presentation types misformat negative numbers | Yes | 2 |
3250(i) | C++20 | 20.20.2.2 [format.string.std] | `std::format`: `#` (alternate form) for NaN and inf | Yes | 0 |
3290(i) | C++20 | 20.20.2.2 [format.string.std] | Are `std::format` field widths code units, code points, or something else? | Yes |  |
3327(i) | C++20 | 20.20.2.2 [format.string.std] | Format alignment specifiers vs. text direction | Yes | 0 |
3619(i) | WP | 20.20.5 [format.functions] | Specification of `vformat_to` contains ill-formed `formatted_size` calls | Yes |  |
3539(i) | WP | 20.20.5 [format.functions] | `format_to` must not copy models of `output_iterator<const charT&>` | Yes |  |
3340(i) | C++20 | 20.20.5 [format.functions] | Formatting functions should throw on argument/format string mismatch in §[format.functions] | Yes |  |
3372(i) | C++20 | 20.20.5 [format.functions] | `vformat_to` should not try to deduce `Out` twice | Yes | 0 |
3336(i) | Resolved | 20.20.5 [format.functions] | How does `std::vformat` handle exception thrown by formatters? | Yes | 2 |
3636(i) | New | 20.20.6.1 [formatter.requirements] | `formatter<T>::format` should be `const`-qualified | Yes | 1 |
3462(i) | WP | 20.20.6.1 [formatter.requirements] | §[formatter.requirements]: Formatter requirements forbid use of `fc.arg()` | Yes | 3 |
3654(i) | WP | 20.20.6.4 [format.context] | `basic_format_context::arg(size_t)` should be `noexcept` | Yes |  |
3567(i) | WP | 20.20.6.4 [format.context] | Formatting move-only iterators take two | Yes |  |
3631(i) | New | 20.20.7.1 [format.arg] | `basic_format_arg(T&&)` should use `remove_cvref_t<T>` throughout | Yes | 3 |
3540(i) | WP | 20.20.7.1 [format.arg] | §[format.arg] There should be no `const` in `basic_format_arg(const T* p)` | Yes |  |
3542(i) | WP | 20.20.7.1 [format.arg] | `basic_format_arg` mis-handles `basic_string_view` with custom traits | Yes |  |
3246(i) | C++20 | 20.20.7.1 [format.arg] | What are the constraints on the template parameter of `basic_format_arg`? | Yes | 0 |
3371(i) | C++20 | 20.20.7.1 [format.arg] | `visit_format_arg` and `make_format_args` are not hidden friends | Yes | 0 |
3544(i) | WP | 20.20.7.2 [format.arg.store] | `format-arg-store::args` is unintentionally not exposition-only | Yes | 3 |
3473(i) | WP | 20.20.7.3 [format.args] | Normative encouragement in non-normative note | Yes | 0 |
3625(i) | New | 20.21.2 [stacktrace.syn] | Should `<stacktrace>` provide range access function templates? | Yes | 3 |
3515(i) | LEWG | 20.21.2 [stacktrace.syn] | §[stacktrace.basic.nonmem]: `operator<<` should be less templatized | Yes | 2 |
3514(i) | Resolved | 20.21.2 [stacktrace.syn] | `stacktrace` should add type alias `pmr::stacktrace` | Yes | 3 |
3507(i) | New | 20.21.3.4 [stacktrace.entry.query] | P0881R7 ("stacktrace") does not define "actual file name", "actual line number" | No | 2 |
3626(i) | New | 20.21.4.1 [stacktrace.basic.overview] | Is `std::basic_stacktrace` required to use contiguous storage? | Yes | 3 |

## Section 21 (136 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
7(i) | TC1 | 21 [strings] | String clause minor problems | Yes |  |
2841(i) | Resolved | 21 [strings] | Use of "Equivalent to" in [strings] | Yes | 3 |
85(i) | NAD | 21 [strings] | String char types | Yes |  |
1081(i) | NAD Concepts | 21 [strings] | `basic_string` needs to be a concept-constrained template | Yes |  |
2513(i) | New | 21.1 [strings.general] | Missing requirements for `basic_string::value_type` | No | 4 |
1170(i) | C++11 | 21.1 [strings.general] | String char-like types no longer PODs | Yes |  |
2994(i) | Open | 21.2 [char.traits] | Needless UB for `basic_string` and `basic_string_view` | Yes | 3 |
830(i) | NAD Editorial | 21.2 [char.traits] | Incomplete list of char_traits specializations | Yes |  |
570(i) | NAD | 21.2 [char.traits] | Request adding additional explicit specializations of `char_traits` | Yes |  |
3085(i) | Open | 21.2.2 [char.traits.require] | `char_traits::copy` precondition too weak | Yes | 2 |
3518(i) | WP | 21.2.2 [char.traits.require] | Exception requirements on char trait operations unclear | Yes |  |
335(i) | CD1 | 21.2.2 [char.traits.require] | minor issue with char_traits, table 37 | Yes |  |
352(i) | CD1 | 21.2.3 [char.traits.typedefs] | missing fpos requirements | Yes |  |
1200(i) | NAD | 21.2.3 [char.traits.typedefs] | "surprising" `char_traits<T>::int_type` requirements | Yes |  |
709(i) | CD1 | 21.2.4 [char.traits.specializations] | `char_traits::not_eof` has wrong signature | Yes |  |
2232(i) | Resolved | 21.2.4 [char.traits.specializations] | [CD] The `char_traits` specializations should declare their `length()`, `compare()`, and `find()` members constexpr | Yes |  |
831(i) | NAD Editorial | 21.2.4 [char.traits.specializations] | wrong type for not_eof() | Yes |  |
467(i) | CD1 | 21.2.4.2 [char.traits.specializations.char] | char_traits::lt(), compare(), and memcmp() | Yes |  |
2959(i) | New | 21.2.4.4 [char.traits.specializations.char16.t] | `char_traits<char16_t>::eof` is a valid UTF-16 code unit | No | 3 |
1414(i) | C++11 | 21.2.4.4 [char.traits.specializations.char16.t] | Fixing remaining dead links to `POS_T` and `OFF_T` | Yes |  | 1444
57(i) | TC1 | 21.2.4.6 [char.traits.specializations.wchar.t] | Mistake in char_traits | Yes |  |
3339(i) | New | 21.3.3 [basic.string] | Move-constructed empty-container capacity | No | 3 |
3451(i) | New | 21.3.3 [basic.string] | Inconsistently explicit deduction guides | Yes | 3 |
3075(i) | C++20 | 21.3.3 [basic.string] | `basic_string` needs deduction guides from `basic_string_view` | Yes |  |
2063(i) | C++17 | 21.3.3 [basic.string] | Contradictory requirements for string move assignment | Yes | 3 |
2064(i) | C++14 | 21.3.3 [basic.string] | More `noexcept` issues in `basic_string` | Yes |  |
2268(i) | C++14 | 21.3.3 [basic.string] | Setting a default argument in the declaration of a member function `assign` of `std::basic_string` | Yes |  |
876(i) | C++11 | 21.3.3 [basic.string] | `basic_string` access operations should give stronger guarantees | Yes |  |
180(i) | CD1 | 21.3.3 [basic.string] | Container member iterator arguments constness has unintended consequences | Yes |  |
263(i) | CD1 | 21.3.3 [basic.string] | Severe restriction on `basic_string` reference counting | Yes |  |
530(i) | CD1 | 21.3.3 [basic.string] | Must elements of a string be contiguous? | Yes |  |
534(i) | CD1 | 21.3.3 [basic.string] | Missing basic_string members | Yes |  |
42(i) | TC1 | 21.3.3 [basic.string] | String ctors specify wrong default allocator | Yes |  |
83(i) | TC1 | 21.3.3 [basic.string] | String::npos vs. string::max_size() | Yes |  | 89
209(i) | TC1 | 21.3.3 [basic.string] | basic_string declarations inconsistent | Yes |  |
2836(i) | Resolved | 21.3.3 [basic.string] | More string operations should be `noexcept` | Yes | 2 |
2318(i) | Resolved | 21.3.3 [basic.string] | `basic_string`'s wording has confusing relics from the copy-on-write era | Yes | 4 |
2391(i) | Resolved | 21.3.3 [basic.string] | `basic_string` is missing non-`const` `data()` | Yes | 3 |
718(i) | NAD Editorial | 21.3.3 [basic.string] | `basic_string` is not a sequence | Yes |  |
3165(i) | NAD | 21.3.3 [basic.string] | All `starts_with()` overloads should be called "`begins_with`" | Yes | 2 |
2372(i) | NAD | 21.3.3 [basic.string] | Assignment from int to `std::string` | Yes | 4 |
4(i) | NAD | 21.3.3 [basic.string] | `basic_string` `size_type` and `difference_type` should be implementation defined | Yes |  |
614(i) | NAD | 21.3.3 [basic.string] | `std::string` allocator requirements still inconsistent | Yes |  |
2084(i) | NAD | 21.3.3 [basic.string] | `basic_string` use of `charT*` | Yes |  |
3650(i) | WP | 21.3.3.1 [basic.string.general] | Are `std::basic_string`'s `iterator` and `const_iterator` constexpr iterators? | Yes |  |
2861(i) | C++17 | 21.3.3.2 [string.require] | `basic_string` should require that `charT` match `traits::char_type` | Yes |  |
2760(i) | C++17 | 21.3.3.2 [string.require] | non-const `basic_string::data` should not invalidate iterators | Yes |  |
2003(i) | C++14 | 21.3.3.2 [string.require] | String exception inconsistency in erase. | Yes | 0 |
847(i) | C++11 | 21.3.3.2 [string.require] | string exception safety guarantees | Yes |  |
301(i) | CD1 | 21.3.3.2 [string.require] | basic_string template ctor effects clause omits allocator argument | Yes |  |
86(i) | TC1 | 21.3.3.2 [string.require] | String constructors don't describe exceptions | Yes |  |
2151(i) | Resolved | 21.3.3.2 [string.require] | `basic_string<>::swap` semantics ignore allocators | Yes | 3 |
466(i) | NAD | 21.3.3.2 [string.require] | `basic_string` ctor should prevent null pointer error | Yes |  |
3663(i) | New | 21.3.3.3 [string.cons] | `basic_string(const T&, const Alloc&)` turns moves into copies | Yes | 3 |
2946(i) | C++20 | 21.3.3.3 [string.cons] | LWG 2758's resolution missed further corrections | Yes | 2 |
3076(i) | C++20 | 21.3.3.3 [string.cons] | `basic_string` CTAD ambiguity | Yes |  |
2742(i) | C++17 | 21.3.3.3 [string.cons] | Inconsistent `string` interface taking `string_view` | Yes | 1 |
2583(i) | C++17 | 21.3.3.3 [string.cons] | There is no way to supply an allocator for `basic_string(str, pos)` | Yes | 0 |
2069(i) | C++14 | 21.3.3.3 [string.cons] | Inconsistent exception spec for `basic_string` move constructor | Yes |  |
2235(i) | C++14 | 21.3.3.3 [string.cons] | Undefined behavior without proper requirements on `basic_string` constructors | Yes |  |
3111(i) | Resolved | 21.3.3.3 [string.cons] | Too strong precondition on `basic_string` constructor | Yes | 2 |
3033(i) | NAD Editorial | 21.3.3.3 [string.cons] | `basic_string` move ctor is underspecified | Yes |  |
2319(i) | NAD | 21.3.3.3 [string.cons] | `basic_string`'s move constructor should not be `noexcept` | Yes | 1 |
2822(i) | NAD | 21.3.3.3 [string.cons] | Resolution for LWG 2742 introduces ambiguities | Yes |  |
2580(i) | NAD | 21.3.3.3 [string.cons] | Who is definitive: `operator=` or `assign`? | Yes | 4 |
2402(i) | NAD | 21.3.3.3 [string.cons] | `basic_string(const basic_string& str, size_type pos, size_type n = npos)` shouldn't use `Allocator()` | Yes | 3 |
3311(i) | Dup | 21.3.3.3 [string.cons] | `basic_string::operator=(charT c)` should be constrained | Yes |  |
1192(i) | C++11 | 21.3.3.4 [string.iterators] | `basic_string` missing definitions for `cbegin` / `cend` / `crbegin` / `crend` | Yes |  |
3579(i) | Tentatively NAD | 21.3.3.5 [string.capacity] | Complexity guarantees for `resize()` and `append()` functions across the library | No | 3 |
3645(i) | New | 21.3.3.5 [string.capacity] | `resize_and_overwrite` is overspecified to call its callback with lvalues | Yes | 2 |
3004(i) | C++20 | 21.3.3.5 [string.capacity] | §[string.capacity] and §[vector.capacity] should specify time complexity for `capacity()` | Yes | 0 |
2834(i) | C++17 | 21.3.3.5 [string.capacity] | Resolution LWG 2223 is missing wording about end iterators | Yes | 0 |
259(i) | CD1 | 21.3.3.5 [string.capacity] | `basic_string::operator[]` and const correctness | Yes |  |
2968(i) | Resolved | 21.3.3.5 [string.capacity] | Inconsistencies between `basic_string reserve` and `vector/unordered_map/unordered_set reserve` functions | Yes | 3 |
104(i) | NAD | 21.3.3.5 [string.capacity] | Description of basic_string::operator[] is unclear | Yes |  |
2475(i) | C++17 | 21.3.3.6 [string.access] | Allow overwriting of `std::basic_string` terminator with `charT()` to allow cleaner interoperation with legacy APIs | Yes | 3 |
2207(i) | C++14 | 21.3.3.6 [string.access] | `basic_string::at` should not have a Requires clause | Yes |  |
84(i) | NAD | 21.3.3.6 [string.access] | Ambiguity with string::insert() | Yes |  |
3662(i) | New | 21.3.3.7.2 [string.append] | `basic_string::append/assign(NTBS, pos, n)` suboptimal | Yes | 3 |
2788(i) | C++17 | 21.3.3.7.2 [string.append] | `basic_string` range mutators unintentionally require a default constructible allocator | Yes | 2 |
2758(i) | C++17 | 21.3.3.7.3 [string.assign] | `std::string{}.assign("ABCDE", 0, 1)` is ambiguous | Yes | 1 |
2579(i) | C++17 | 21.3.3.7.3 [string.assign] | Inconsistency wrt Allocators in `basic_string` assignment vs. `basic_string::assign` | Yes | 0 |
2929(i) | Resolved | 21.3.3.7.3 [string.assign] | `basic_string` misuses "Effects: Equivalent to" | Yes | 3 |
141(i) | TC1 | 21.3.3.7.4 [string.insert] | basic_string::find_last_of, find_last_not_of say pos instead of xpos | Yes |  |
2757(i) | Resolved | 21.3.3.7.4 [string.insert] | `std::string{}.insert(3, "ABCDE", 0, 1)` is ambiguous | Yes | 1 |
88(i) | NAD | 21.3.3.7.4 [string.insert] | Inconsistency between string::insert() and string::append() | Yes |  |
377(i) | NAD | 21.3.3.7.4 [string.insert] | basic_string::insert and length_error | Yes |  |
89(i) | Dup | 21.3.3.7.4 [string.insert] | Missing throw specification for string::insert() and string::replace() | Yes |  | 83
428(i) | CD1 | 21.3.3.7.5 [string.erase] | string::erase(iterator) validity | Yes |  |
27(i) | TC1 | 21.3.3.7.5 [string.erase] | String::erase(range) yields wrong iterator | Yes |  |
1323(i) | C++11 | 21.3.3.7.6 [string.replace] | `basic_string::replace` should use `const_iterator` | Yes |  |
368(i) | NAD Editorial | 21.3.3.7.6 [string.replace] | basic_string::replace has two "Throws" paragraphs | Yes |  |
403(i) | CD1 | 21.3.3.7.8 [string.swap] | basic_string::swap should not throw exceptions | Yes |  |
535(i) | CD1 | 21.3.3.7.8 [string.swap] | std::string::swap specification poorly worded | Yes |  |
5(i) | TC1 | 21.3.3.7.8 [string.swap] | String::compare specification questionable | Yes |  | 87
87(i) | Dup | 21.3.3.7.8 [string.swap] | Error in description of string::compare() | Yes |  | 5
2771(i) | C++17 | 21.3.3.8.4 [string.compare] | Broken Effects of some `basic_string::compare` functions in terms of `basic_string_view` | Yes | 1 |
1138(i) | C++11 | 21.3.4.1 [string.op.plus] | Unusual return value for `operator+` | Yes |  |
2852(i) | NAD | 21.3.4.2 [string.cmp] | Specifications of `operator==` for `std::basic_string`s and `std::basic_string_view`s are difficult to conform to | Yes | 2 |
2011(i) | C++14 | 21.3.4.4 [string.io] | Unexpected output required of strings | Yes |  |
91(i) | CD1 | 21.3.4.4 [string.io] | Description of operator>> and getline() for string<> might cause endless loop | Yes |  |
435(i) | CD1 | 21.3.4.4 [string.io] | bug in DR 25 | Yes |  |
586(i) | CD1 | 21.3.4.4 [string.io] | string inserter not a formatted function | Yes |  |
824(i) | CD1 | 21.3.4.4 [string.io] | rvalue ref issue with `basic_string` inserter | Yes |  |
25(i) | TC1 | 21.3.4.4 [string.io] | String operator<< uses width() value wrong | Yes |  | 67
90(i) | TC1 | 21.3.4.4 [string.io] | Incorrect description of operator >> for strings | Yes |  |
211(i) | TC1 | 21.3.4.4 [string.io] | operator>>(istream&, string&) doesn't set failbit | Yes |  |
2535(i) | NAD | 21.3.4.4 [string.io] | Inconsistency between `ostream::write` and `ostream::operator<<` | Yes | 2 |
67(i) | Dup | 21.3.4.4 [string.io] | Setw useless for strings | Yes |  | 25
2403(i) | C++17 | 21.3.5 [string.conversions] | `stof()` should call `strtof()` and `wcstof()` | Yes | 2 |
2009(i) | C++14 | 21.3.5 [string.conversions] | Reporting out-of-bound values on numeric string conversions | Yes |  |
1261(i) | C++11 | 21.3.5 [string.conversions] | Insufficent overloads for `to_string` / `to_wstring` | Yes |  |
771(i) | CD1 | 21.3.5 [string.conversions] | Impossible throws clause in [string.conversions] | Yes |  |
772(i) | CD1 | 21.3.5 [string.conversions] | Impossible return clause in [string.conversions] | Yes |  |
2270(i) | NAD | 21.3.5 [string.conversions] | Inconsistent `to_string` overloads | Yes |  |
2978(i) | C++20 | 21.3.6 [basic.string.hash] | Hash support for `pmr::string` and friends | Yes | 0 |
2355(i) | NAD | 21.3.7 [basic.string.literals] | `"s"` UDL suffix should be reserved for a compile-time string library type | Yes | 1 |
2883(i) | LEWG | 21.4 [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 |  |
2778(i) | C++17 | 21.4 [string.view] | `basic_string_view` is missing `constexpr` | Yes | 0 |
2780(i) | Resolved | 21.4 [string.view] | `basic_string_view::copy` is missing `constexpr` | Yes | 2 |
3457(i) | New | 21.4.3 [string.view.template] | `*this` is not invalidated | Yes | 3 |
3068(i) | Open | 21.4.3 [string.view.template] | Forbid assigning an rvalue `basic_string` to `basic_string_view` | Yes | 2 |
2938(i) | Resolved | 21.4.3 [string.view.template] | `basic_string_view::const_iterator` should be literal types | Yes | 2 |
3573(i) | WP | 21.4.3.2 [string.view.cons] | Missing Throws element for `basic_string_view(It begin, End end)` | Yes |  |
3581(i) | WP | 21.4.3.2 [string.view.cons] | The range constructor makes `basic_string_view` not trivially move constructible | Yes |  |
2826(i) | C++17 | 21.4.3.3 [string.view.iterators] | `string_view` iterators use old wording | Yes | 0 |
3040(i) | C++20 | 21.4.3.7 [string.view.ops] | `basic_string_view::starts_with` Effects are incorrect | Yes | 0 |
2777(i) | C++17 | 21.4.3.7 [string.view.ops] | `basic_string_view::copy` should use `char_traits::copy` | Yes | 0 |
3432(i) | WP | 21.4.5 [string.view.comparison] | Missing requirement for `comparison_category` | Yes | 0 |
2755(i) | C++17 | 21.4.6 [string.view.io] | §[string.view.io] uses non-existent `basic_string_view::to_string` function | Yes | 0 |
2791(i) | Resolved | 21.4.7 [string.view.hash] | `string_view` objects and strings should yield the same hash values | Yes |  |
2237(i) | New | 21.5 [c.strings] | `<cuchar>` macros | No | 4 |
2238(i) | Open | 21.5 [c.strings] | Problematic iterator-pair constructor of containers | No | 3 |
2482(i) | C++17 | 21.5 [c.strings] | §[c.strings] Table 73 mentions nonexistent functions | Yes |  |
345(i) | CD1 | 21.5 [c.strings] | type tm in <cwchar> | Yes |  |
615(i) | NAD Editorial | 21.5 [c.strings] | Inconsistencies in Section 21.4 | Yes |  |

## Section 22 (311 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2307(i) | LEWG | 22 [containers] | Should the Standard Library use `explicit` only when necessary? | No | 2 |
2885(i) | LEWG | 22 [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(i) | LEWG | 22 [containers] | Relational operators for containers should sfinae; if the underlying type is not comparable, neither should the container be | No |  |
2193(i) | C++14 | 22 [containers] | Default constructors for standard library containers are explicit | Yes | 1 |
774(i) | C++11 | 22 [containers] | Member `swap` undefined for most containers | Yes |  |
868(i) | C++11 | 22 [containers] | Default construction and value-initialization | Yes |  |
883(i) | C++11 | 22 [containers] | swap circular definition | Yes |  |
2913(i) | Resolved | 22 [containers] | Containers need deduction guides | Yes |  |
767(i) | Resolved | 22 [containers] | Forwarding and backward compatibility | Yes |  |
1242(i) | NAD | 22 [containers] | Enable SCARY iterators | Yes |  |
97(i) | NAD | 22 [containers] | Insert inconsistent definition | Yes |  |
470(i) | NAD | 22 [containers] | accessing containers from their elements' special functions | Yes |  |
3059(i) | New | 22.2 [container.requirements] | Wrong requirements for map-like associative container assignment? | No | 3 |
2261(i) | C++17 | 22.2 [container.requirements] | Are containers required to use their '`pointer`' type internally? | Yes | 2 |
704(i) | C++11 | 22.2 [container.requirements] | `MoveAssignable` requirement for container value type overly strict | Yes |  |
861(i) | C++11 | 22.2 [container.requirements] | Incomplete specification of `EqualityComparable` for `std::forward_list` | Yes |  |
1416(i) | C++11 | 22.2 [container.requirements] | `forward_list::erase_after` should not be allowed to throw | Yes |  |
179(i) | CD1 | 22.2 [container.requirements] | Comparison of const_iterators to iterators doesn't work | Yes |  |
276(i) | CD1 | 22.2 [container.requirements] | Assignable requirement for container value type overly strict | Yes |  |
322(i) | CD1 | 22.2 [container.requirements] | iterator and const_iterator should have the same value type | Yes |  |
371(i) | CD1 | 22.2 [container.requirements] | Stability of multiset and multimap member functions | Yes |  |
589(i) | CD1 | 22.2 [container.requirements] | Requirements on iterators of member template functions of containers | Yes |  | 536
675(i) | CD1 | 22.2 [container.requirements] | Move assignment of containers | Yes |  |
759(i) | CD1 | 22.2 [container.requirements] | A reference is not an object | Yes |  |
766(i) | CD1 | 22.2 [container.requirements] | Inconsistent exception guarantees between ordered and unordered associative containers | Yes |  |
842(i) | CD1 | 22.2 [container.requirements] | `ConstructibleAsElement` and bit containers | Yes |  |
51(i) | TC1 | 22.2 [container.requirements] | Requirement to not invalidate iterators missing | Yes |  |
760(i) | NAD | 22.2 [container.requirements] | The emplace issue | Yes | 2 |
279(i) | NAD | 22.2 [container.requirements] | const and non-const iterators should have equivalent typedefs | Yes |  |
632(i) | NAD | 22.2 [container.requirements] | Time complexity of `size()` for `std::set` | Yes |  |
1330(i) | NAD | 22.2 [container.requirements] | Move container requirements into requirements tables | Yes |  |
479(i) | Dup | 22.2 [container.requirements] | Container requirements and placement new | Yes |  | 580
536(i) | Dup | 22.2 [container.requirements] | Container iterator constructor and explicit convertibility | Yes |  | 589
3028(i) | New | 22.2.1 [container.requirements.general] | Container requirements tables should distinguish `const` and non-`const` variables | Yes | 3 |
3431(i) | New | 22.2.1 [container.requirements.general] | `<=>` for containers should require `three_way_comparable<T>` instead of `<=>` | Yes | 2 |
2269(i) | New | 22.2.1 [container.requirements.general] | Container iterators and argument-dependent lookup | No | 4 |
1521(i) | Open | 22.2.1 [container.requirements.general] | Requirements on internal pointer representations in containers | Yes | 3 |
2321(i) | Open | 22.2.1 [container.requirements.general] | Moving containers should (usually) be required to preserve iterators | Yes | 3 |
3352(i) | C++20 | 22.2.1 [container.requirements.general] | `strong_equality` isn't a thing | Yes | 1 |
2218(i) | C++17 | 22.2.1 [container.requirements.general] | Unclear how containers use `allocator_traits::construct()` | Yes | 3 |
2448(i) | C++17 | 22.2.1 [container.requirements.general] | Non-normative Container destructor specification | Yes | 0 |
2794(i) | C++17 | 22.2.1 [container.requirements.general] | Missing requirements for allocator pointers | Yes | 0 |
2177(i) | C++14 | 22.2.1 [container.requirements.general] | Requirements on `Copy/MoveInsertable` | Yes |  |
2182(i) | C++14 | 22.2.1 [container.requirements.general] | `Container::[const_]reference` types are misleadingly specified | Yes | 0 |
2308(i) | C++14 | 22.2.1 [container.requirements.general] | Clarify container destructor requirements w.r.t. `std::array` | Yes | 0 |
2320(i) | C++14 | 22.2.1 [container.requirements.general] | `select_on_container_copy_construction()` takes allocators, not containers | Yes | 0 |
2105(i) | C++14 | 22.2.1 [container.requirements.general] | Inconsistent requirements on `const_iterator`'s `value_type` | Yes |  |
2211(i) | C++14 | 22.2.1 [container.requirements.general] | Replace ambiguous use of "Allocator" in container requirements | Yes |  |
2257(i) | C++14 | 22.2.1 [container.requirements.general] | Simplify container requirements with the new algorithms | Yes |  |
1034(i) | C++11 | 22.2.1 [container.requirements.general] | Clarify generality of Container Requirement tables | Yes |  |
1319(i) | C++11 | 22.2.1 [container.requirements.general] | Containers should require an iterator that is at least a Forward Iterator | Yes |  |
985(i) | Resolved | 22.2.1 [container.requirements.general] | Allowing throwing move | Yes |  |
580(i) | NAD Editorial | 22.2.1 [container.requirements.general] | unused allocator members | Yes |  | 479
1415(i) | NAD Editorial | 22.2.1 [container.requirements.general] | Iterator stability bans the short-string optimization | Yes |  |
1035(i) | NAD | 22.2.1 [container.requirements.general] | `<array>::swap` can invalidate references, pointers, and iterators | Yes |  |
2167(i) | NAD | 22.2.1 [container.requirements.general] | Copy assignment requirements of Containers | Yes |  |
2200(i) | C++14 | 22.2.2 [container.requirements.dataraces] | Data race avoidance for all containers, not only for sequences | Yes |  |
1329(i) | Resolved | 22.2.2 [container.requirements.dataraces] | Data races on `vector<bool>` | Yes |  |
2705(i) | New | 22.2.3 [sequence.reqmts] | Questionable precondition on Sequence containers `a.assign(n, t)` | Yes | 3 |
3297(i) | New | 22.2.3 [sequence.reqmts] | Useless sequence container requirement | Yes | 3 |
2206(i) | Open | 22.2.3 [sequence.reqmts] | Inaccuracy in `initializer_list` constructor requirements | Yes | 3 |
2266(i) | C++17 | 22.2.3 [sequence.reqmts] | `vector` and `deque` have incorrect `insert` requirements | Yes | 2 |
2698(i) | C++17 | 22.2.3 [sequence.reqmts] | Effect of `assign()` on iterators/pointers/references | Yes | 0 |
2231(i) | C++14 | 22.2.3 [sequence.reqmts] | DR 704 removes complexity guarantee for `clear()` | Yes |  |
149(i) | C++11 | 22.2.3 [sequence.reqmts] | Insert should return iterator to first element inserted | Yes |  |
1037(i) | C++11 | 22.2.3 [sequence.reqmts] | Unclear status of `match_results` as library container | Yes |  |
1038(i) | C++11 | 22.2.3 [sequence.reqmts] | Sequence requirement table needs to reference several new containers | Yes |  |
1039(i) | C++11 | 22.2.3 [sequence.reqmts] | Sequence container `back` function should also support `const_iterator` | Yes |  |
1234(i) | C++11 | 22.2.3 [sequence.reqmts] | "Do the right thing" and `NULL` | Yes |  |
355(i) | CD1 | 22.2.3 [sequence.reqmts] | Operational semantics for a.back() | Yes |  |
438(i) | CD1 | 22.2.3 [sequence.reqmts] | Ambiguity in the "do the right thing" clause | Yes |  |
139(i) | TC1 | 22.2.3 [sequence.reqmts] | Optional sequence operation table description unclear | Yes |  |
151(i) | TC1 | 22.2.3 [sequence.reqmts] | Can't currently clear() empty container | Yes |  |
725(i) | NAD Editorial | 22.2.3 [sequence.reqmts] | Optional sequence container requirements column label | Yes |  |
1058(i) | NAD Editorial | 22.2.3 [sequence.reqmts] | New container issue | Yes |  |
1301(i) | NAD Editorial | 22.2.3 [sequence.reqmts] | `clear()` and assignment | Yes |  |
526(i) | NAD | 22.2.3 [sequence.reqmts] | Is it undefined if a function in the standard changes in parameters? | Yes |  |
1259(i) | NAD | 22.2.3 [sequence.reqmts] | Should initializer-list constructors move elements? | Yes |  |
1036(i) | NAD Concepts | 22.2.3 [sequence.reqmts] | Remove iterator specification that is redundant due to concept constraints | Yes |  |
3438(i) | New | 22.2.4.1 [container.node.overview] | §[container.node.overview] missing `multiset`/`map` cases | No | 3 |
2743(i) | WP | 22.2.4.1 [container.node.overview] | p0083r3 `node_handle` private members missing "exposition only" comment | Yes | 3 |
3227(i) | New | 22.2.6 [associative.reqmts] | Ambiguity issue for `extract` in ordered and unordered associative containers | Yes | 3 |
2362(i) | New | 22.2.6 [associative.reqmts] | unique, associative `emplace()` should not move/copy the `mapped_type` constructor arguments when no insertion happens | No | 3 |
2844(i) | Open | 22.2.6 [associative.reqmts] | Stability of `a_uniq.insert(i, j)` | No | 3 |
2227(i) | Open | 22.2.6 [associative.reqmts] | Stateful comparison objects in associative containers | No | 3 |
2215(i) | Open | 22.2.6 [associative.reqmts] | (unordered) associative container functors should be `CopyConstructible` | Yes | 3 |
2436(i) | C++17 | 22.2.6 [associative.reqmts] | Comparators for associative containers should always be `CopyConstructible` | Yes | 2 |
2542(i) | C++17 | 22.2.6 [associative.reqmts] | Missing `const` requirements for associative containers | Yes | 1 |
2322(i) | C++14 | 22.2.6 [associative.reqmts] | Associative(`initializer_list`, stuff) constructors are underspecified | Yes | 0 |
1214(i) | C++14 | 22.2.6 [associative.reqmts] | Insufficient/inconsistent key immutability requirements for associative containers | Yes |  |
2258(i) | C++14 | 22.2.6 [associative.reqmts] | `a.erase(q1, q2)` unable to directly return `q2` | Yes | 0 |
2299(i) | C++14 | 22.2.6 [associative.reqmts] | [CD] Effects of inaccessible `key_compare::is_transparent` type are not clear | Yes | 1 |
982(i) | C++11 | 22.2.6 [associative.reqmts] | Wrong complexity for initializer_list assignment in Table 85 | Yes |  |
1040(i) | C++11 | 22.2.6 [associative.reqmts] | Clarify possible sameness of associative container's `iterator` and `const_iterator` | Yes |  |
1253(i) | C++11 | 22.2.6 [associative.reqmts] | invalidation of iterators and `emplace` vs. `insert` inconsistence in assoc. containers | Yes |  |
103(i) | CD1 | 22.2.6 [associative.reqmts] | set::iterator is required to be modifiable, but this allows modification of keys | Yes |  |
130(i) | CD1 | 22.2.6 [associative.reqmts] | Return type of container::erase(iterator) differs for associative containers | Yes |  | 451
233(i) | CD1 | 22.2.6 [associative.reqmts] | Insertion hints in associative containers | Yes |  | 192, 246
264(i) | CD1 | 22.2.6 [associative.reqmts] | Associative container `insert(i, j)` complexity requirements are not feasible. | Yes |  | 102
316(i) | CD1 | 22.2.6 [associative.reqmts] | Vague text in Table 69 | Yes |  |
354(i) | CD1 | 22.2.6 [associative.reqmts] | Associative container lower/upper bound requirements | Yes |  |
224(i) | TC1 | 22.2.6 [associative.reqmts] | clear() complexity for associative containers refers to undefined N | Yes |  |
1041(i) | Resolved | 22.2.6 [associative.reqmts] | Add associative/unordered container functions that allow to extract elements | Yes |  |
2830(i) | Resolved | 22.2.6 [associative.reqmts] | `insert_return_type` is only defined for containers with unique keys | Yes |  |
2052(i) | Resolved | 22.2.6 [associative.reqmts] | Mixup between `mapped_type` and `value_type` for associative containers | Yes | 2 |
2430(i) | NAD | 22.2.6 [associative.reqmts] | Heterogeneous container lookup should be enabled using meta-function instead of nested type | Yes |  |
2772(i) | NAD | 22.2.6 [associative.reqmts] | Inconsistency in the `insert(node)` interface | Yes | 2 |
82(i) | NAD | 22.2.6 [associative.reqmts] | Missing constant for set elements | Yes |  |
192(i) | NAD | 22.2.6 [associative.reqmts] | a.insert(p,t) is inefficient and overconstrained | Yes |  | 233
215(i) | NAD | 22.2.6 [associative.reqmts] | Can a map's key_type be const? | Yes |  |
494(i) | NAD | 22.2.6 [associative.reqmts] | Wrong runtime complexity for associative container's insert and delete | Yes |  |
763(i) | NAD | 22.2.6 [associative.reqmts] | Renaming `emplace()` overloads | Yes |  |
1302(i) | NAD | 22.2.6 [associative.reqmts] | different `emplace` semantics for sequence and associated containers | Yes |  |
102(i) | Dup | 22.2.6 [associative.reqmts] | Bug in insert range in associative containers | Yes |  | 264
246(i) | Dup | 22.2.6 [associative.reqmts] | `a.insert(p,t)` is incorrectly specified | Yes |  | 233
451(i) | Dup | 22.2.6 [associative.reqmts] | Associative erase should return an iterator | Yes |  | 130
3577(i) | New | 22.2.6.1 [associative.reqmts.general] | Merging an (unordered) associative container with itself | No | 3 |
3578(i) | New | 22.2.6.1 [associative.reqmts.general] | Iterator SCARYness in the context of associative container merging | No | 3 |
1175(i) | Open | 22.2.7 [unord.req] | `unordered` complexity | Yes | 3 |
2198(i) | Open | 22.2.7 [unord.req] | `max_load_factor(z)` makes no strong guarantees, but bans useful behavior | Yes | 3 |
2977(i) | C++20 | 22.2.7 [unord.req] | `unordered_meow::merge()` has incorrect Throws: clause | Yes | 0 |
2156(i) | C++17 | 22.2.7 [unord.req] | Unordered containers' `reserve(n)` reserves for `n-1` elements | Yes | 3 |
2540(i) | C++17 | 22.2.7 [unord.req] | `unordered_multimap::insert` hint iterator | Yes | 3 |
2550(i) | C++17 | 22.2.7 [unord.req] | Wording of unordered container's `clear()` method complexity | Yes | 2 |
2304(i) | C++14 | 22.2.7 [unord.req] | Complexity of `count` in unordered associative containers | Yes | 0 |
2356(i) | C++14 | 22.2.7 [unord.req] | Stability of erasure in unordered associative containers | Yes | 2 |
869(i) | C++11 | 22.2.7 [unord.req] | Bucket (local) iterators and iterating past end | Yes |  |
870(i) | C++11 | 22.2.7 [unord.req] | Do unordered containers not support function pointers for predicate/hasher? | Yes |  |
981(i) | C++11 | 22.2.7 [unord.req] | Unordered container requirements should add `initializer_list` support | Yes |  |
1189(i) | C++11 | 22.2.7 [unord.req] | Awkward interface for changing the number of buckets in an unordered associative container | Yes |  |
1197(i) | C++11 | 22.2.7 [unord.req] | Can unordered containers have `bucket_count() == 0`? | Yes |  |
518(i) | CD1 | 22.2.7 [unord.req] | Are insert and erase stable for unordered_multiset and unordered_multimap? | Yes |  |
2831(i) | Resolved | 22.2.7 [unord.req] | Equality can be defined when `Hash` function objects have different behaviour | Yes |  |
3176(i) | Resolved | 22.2.7 [unord.req] | Underspecified behavior of unordered containers when `Container::key_equal` differs from `Pred` | Yes | 2 |
3468(i) | NAD | 22.2.7 [unord.req] | Transparent lookups in unordered containers are inconsistent | Yes |  |
1188(i) | NAD | 22.2.7 [unord.req] | Unordered containers should have a minimum load factor as well as a maximum | Yes |  |
2199(i) | NAD | 22.2.7 [unord.req] | unordered containers are required to have an initial max load factor of 1.0 | Yes | 3 |
579(i) | NAD | 22.2.7 [unord.req] | `erase(iterator)` for unordered containers should not return an iterator | Yes |  |
764(i) | NAD | 22.2.7 [unord.req] | `equal_range` on unordered containers should return a `pair` of `local_iterators` | Yes |  |
1190(i) | NAD | 22.2.7 [unord.req] | Setting the maximum load factor should return the previous value | Yes |  |
2006(i) | NAD | 22.2.7 [unord.req] | `emplace` broken for associative containers | Yes |  |
3622(i) | New | 22.2.7.1 [unord.req.general] | Misspecified transitivity of equivalence in §[unord.req.general] | Yes | 2 |
2189(i) | Open | 22.2.7.2 [unord.req.except] | Throwing `swap` breaks unordered containers' state | No | 3 |
2209(i) | C++14 | 22.3 [sequences] | `assign()` overspecified for sequence containers | Yes |  |
2210(i) | C++14 | 22.3 [sequences] | Missing allocator-extended constructor for allocator-aware containers | Yes |  |
679(i) | CD1 | 22.3 [sequences] | resize parameter by value | Yes |  |
1042(i) | NAD | 22.3 [sequences] | Provide `ContiguousStorage` concept and apply it to corresponding containers | Yes |  |
2427(i) | C++17 | 22.3.1 [sequences.general] | Container adaptors as sequence containers, redux | Yes | 0 |
2914(i) | Resolved | 22.3.2 [array.syn] | `std::array` does not support class-template deduction from initializers | Yes |  |
1306(i) | C++11 | 22.3.7 [array] | `pointer` and `const_pointer` for `<array>` | Yes |  |
519(i) | CD1 | 22.3.7 [array] | Data() undocumented | Yes |  |
720(i) | CD1 | 22.3.7 [array] | Omissions in constexpr usages | Yes |  |
776(i) | CD1 | 22.3.7 [array] | Undescribed `assign` function of `std::array` | Yes |  |
2443(i) | Resolved | 22.3.7 [array] | `std::array` member functions should be `constexpr` | Yes |  |
2335(i) | NAD | 22.3.7 [array] | `array<array<int, 3>, 4>` should be layout-compatible with `int[4][3]` | Yes | 3 |
851(i) | NAD | 22.3.7 [array] | simplified array construction | Yes |  |
588(i) | NAD | 22.3.7 [array] | requirements on zero sized `tr1::arrays` and other details | Yes |  |
617(i) | NAD | 22.3.7 [array] | `std::array` is a sequence that doesn't satisfy the sequence requirements? | Yes |  |
930(i) | NAD | 22.3.7 [array] | Access to std::array data as built-in array type | Yes |  |
3219(i) | New | 22.3.7.1 [array.overview] | `std::array` overview container requirements are incorrect | Yes | 3 |
2823(i) | Open | 22.3.7.1 [array.overview] | `std::array` initialization is still not permissive enough | Yes | 3 |
2310(i) | C++17 | 22.3.7.1 [array.overview] | Public exposition only member in `std::array` | Yes | 4 |
2590(i) | C++17 | 22.3.7.1 [array.overview] | Aggregate initialization for `std::array` | Yes | 0 |
2897(i) | Resolved | 22.3.7.1 [array.overview] | `array::iterator` and `array::const_iterator` should be literal types | Yes | 2 |
3488(i) | Open | 22.3.7.4 [array.special] | Is `array<const int, 0>` swappable or not? | Yes | 3 |
2157(i) | Open | 22.3.7.5 [array.zero] | How does `std::array<T,0>` initialization work when `T` is not default-constructible? | Yes | 3 |
1417(i) | C++11 | 22.3.7.5 [array.zero] | `front/back` on a zero-sized `array` should be undefined | Yes |  |
237(i) | CD1 | 22.3.8.2 [deque.cons] | Undefined expression in complexity specification | Yes |  |
144(i) | TC1 | 22.3.8.2 [deque.cons] | Deque constructor complexity wrong | Yes |  |
1418(i) | C++11 | 22.3.8.3 [deque.capacity] | Effects of `resize(size())` on a `deque` | Yes |  |
850(i) | CD1 | 22.3.8.3 [deque.capacity] | Should `shrink_to_fit` apply to `std::deque`? | Yes |  |
855(i) | NAD | 22.3.8.3 [deque.capacity] | capacity() and reserve() for deque? | Yes |  |
3308(i) | New | 22.3.8.4 [deque.modifiers] | `vector` and `deque` iterator `erase` invalidates elements even when no change occurs | Yes | 3 |
2953(i) | C++20 | 22.3.8.4 [deque.modifiers] | LWG 2853 should apply to `deque::erase` too | Yes | 0 |
2364(i) | C++17 | 22.3.8.4 [deque.modifiers] | `deque` and `vector` `pop_back` don't specify iterator invalidation requirements | Yes | 0 |
2477(i) | C++17 | 22.3.8.4 [deque.modifiers] | Inconsistency of wordings in `std::vector::erase()` and `std::deque::erase()` | Yes | 0 |
638(i) | CD1 | 22.3.8.4 [deque.modifiers] | `deque` end invalidation during erase | Yes |  |
3088(i) | WP | 22.3.9.6 [forward.list.ops] | `forward_list::merge` behavior unclear when passed `*this` | Yes | 3 |
307(i) | CD1 | 22.3.10 [list] | Lack of reference typedefs in container adaptors | Yes |  |
320(i) | CD1 | 22.3.10.2 [list.cons] | list::assign overspecified | Yes |  |
410(i) | CD1 | 22.3.10.2 [list.cons] | Missing semantics for stack and queue comparison operators | Yes |  |
1420(i) | C++11 | 22.3.10.3 [list.capacity] | Effects of `resize(size())` on a `list` | Yes |  |
132(i) | TC1 | 22.3.10.3 [list.capacity] | list::resize description uses random access iterators | Yes |  |
2997(i) | WP | 22.3.10.5 [list.ops] | LWG 491 and the specification of `{forward_,}list::unique` | Yes | 3 |
2998(i) | C++20 | 22.3.10.5 [list.ops] | Requirements on function objects passed to `{forward_,}list`-specific algorithms | Yes | 0 |
3087(i) | C++20 | 22.3.10.5 [list.ops] | One final `&x` in §[list.ops] | Yes | 3 |
2824(i) | C++17 | 22.3.10.5 [list.ops] | `list::sort` should say that the order of elements is unspecified if an exception is thrown | Yes | 0 |
2122(i) | C++14 | 22.3.10.5 [list.ops] | `merge()` stability for lists versus forward lists | Yes |  |
1207(i) | C++11 | 22.3.10.5 [list.ops] | Underspecified `std::list` operations? | Yes |  |
1215(i) | C++11 | 22.3.10.5 [list.ops] | `list::merge` with unequal allocators | Yes |  |
250(i) | CD1 | 22.3.10.5 [list.ops] | splicing invalidates iterators | Yes |  |
278(i) | CD1 | 22.3.10.5 [list.ops] | What does iterator validity mean? | Yes |  |
300(i) | CD1 | 22.3.10.5 [list.ops] | list::merge() specification incomplete | Yes |  |
315(i) | CD1 | 22.3.10.5 [list.ops] | Bad "range" in list::unique complexity | Yes |  |
131(i) | NAD | 22.3.10.5 [list.ops] | list::splice throws nothing | Yes |  |
491(i) | NAD | 22.3.10.5 [list.ops] | std::list<>::unique incorrectly specified | Yes |  |
2279(i) | NAD | 22.3.10.5 [list.ops] | Carefully state effects of `list::splice` function | Yes |  |
464(i) | CD1 | 22.3.11 [vector] | Suggestion for new member functions in standard containers | Yes |  |
469(i) | CD1 | 22.3.11 [vector] | vector<bool> ill-formed relational operators | Yes |  |
496(i) | CD1 | 22.3.11 [vector] | Illegal use of "T" in vector<bool> | Yes |  |
69(i) | TC1 | 22.3.11 [vector] | Must elements of a vector be contiguous? | Yes |  |
101(i) | NAD Editorial | 22.3.11 [vector] | No way to free storage for vector and deque | Yes |  |
757(i) | NAD Editorial | 22.3.11 [vector] | Typo in the synopsis of vector | Yes |  |
1184(i) | NAD | 22.3.11 [vector] | Feature request: dynamic bitset | Yes |  |
96(i) | NAD | 22.3.11 [vector] | Vector<bool> is not a container | Yes |  |
134(i) | TC1 | 22.3.11.2 [vector.cons] | vector constructors over specified | Yes |  |
2158(i) | Open | 22.3.11.3 [vector.capacity] | Conditional copy/move in `std::vector` | Yes | 3 |
1102(i) | Open | 22.3.11.3 [vector.capacity] | `std::vector`'s reallocation policy still unclear | Yes | 3 |
2160(i) | C++17 | 22.3.11.3 [vector.capacity] | Unintended destruction ordering-specification of `resize` | Yes | 1 |
2223(i) | C++17 | 22.3.11.3 [vector.capacity] | `shrink_to_fit` effect on iterator validity | Yes | 2 |
2323(i) | C++14 | 22.3.11.3 [vector.capacity] | `vector::resize(n, t)`'s specification should be simplified | Yes | 0 |
2033(i) | C++14 | 22.3.11.3 [vector.capacity] | Preconditions of `reserve`, `shrink_to_fit`, and `resize` functions | Yes |  |
1525(i) | C++11 | 22.3.11.3 [vector.capacity] | Effects of `resize(size())` on a `vector` | Yes |  |
329(i) | CD1 | 22.3.11.3 [vector.capacity] | vector capacity, reserve and reallocation | Yes |  |
341(i) | CD1 | 22.3.11.3 [vector.capacity] | Vector reallocation and swap | Yes |  |
755(i) | CD1 | 22.3.11.3 [vector.capacity] | `std::vector` and `std:string` lack explicit shrink-to-fit operations | Yes |  |
2066(i) | Resolved | 22.3.11.3 [vector.capacity] | Missing specification of `vector::resize(size_type)` | Yes |  |
1246(i) | NAD | 22.3.11.3 [vector.capacity] | `vector::resize()` missing efficiency guarantee | Yes |  |
2596(i) | C++17 | 22.3.11.4 [vector.data] | `vector::data()` should use `addressof` | Yes | 0 |
1312(i) | C++11 | 22.3.11.4 [vector.data] | `vector::data` no longer returns a raw pointer | Yes |  |
2164(i) | C++20 | 22.3.11.5 [vector.modifiers] | What are the semantics of `vector.emplace(vector.begin(), vector.back())`? | Yes | 2 |
3077(i) | C++20 | 22.3.11.5 [vector.modifiers] | `(push|emplace)_back` should invalidate the `end` iterator | Yes | 3 |
2853(i) | C++17 | 22.3.11.5 [vector.modifiers] | Possible inconsistency in specification of `erase` in [vector.modifiers] | Yes | 0 |
2252(i) | C++14 | 22.3.11.5 [vector.modifiers] | Strong guarantee on `vector::push_back()` still broken with C++11? | Yes |  |
247(i) | CD1 | 22.3.11.5 [vector.modifiers] | `vector`, `deque::insert` complexity | Yes |  |
406(i) | CD1 | 22.3.11.5 [vector.modifiers] | vector::insert(s) exception safety | Yes |  |
414(i) | CD1 | 22.3.11.5 [vector.modifiers] | Which iterators are invalidated by v.erase()? | Yes |  |
2256(i) | NAD | 22.3.11.5 [vector.modifiers] | On `vector` iterator invalidation | Yes | 3 |
2449(i) | NAD | 22.3.11.5 [vector.modifiers] | `vector::insert` invalidates `end()`? | Yes | 3 |
3638(i) | New | 22.3.12 [vector.bool] | `vector<bool>::swap(reference, reference)` is useless | Yes | 3 |
1422(i) | Open | 22.3.12 [vector.bool] | `vector<bool>` iterators are not random access | No | 3 |
2187(i) | C++14 | 22.3.12 [vector.bool] | `vector<bool>` is missing `emplace` and `emplace_back` member functions | Yes |  |
814(i) | C++11 | 22.3.12 [vector.bool] | `vector<bool>::swap(reference, reference)` not defined | Yes |  |
1254(i) | C++11 | 22.3.12 [vector.bool] | Misleading sentence in `vector<bool>::flip` | Yes |  |
1284(i) | C++11 | 22.3.12 [vector.bool] | `vector<bool> initializer_list` constructor missing an allocator argument | Yes |  |
751(i) | NAD | 22.3.12 [vector.bool] | change pass-by-reference members of `vector<bool>` to pass-by-value? | Yes |  |
839(i) | Resolved | 22.4 [associative] | Maps and sets missing splice operation | Yes |  |
2012(i) | Resolved | 22.4 [associative] | Associative maps should insert `pair`, not `tuple` | Yes |  |
2161(i) | NAD | 22.4 [associative] | `const` equivalence of `std::map` | Yes | 2 |
1111(i) | NAD Concepts | 22.4 [associative] | associative containers underconstrained | Yes |  |
2059(i) | C++17 | 22.4.4 [map] | C++0x ambiguity problem with `map::erase` | Yes | 3 |
2300(i) | C++14 | 22.4.4 [map] | [CD] Redundant sections for `map` and `multimap` members should be removed | Yes |  |
1423(i) | C++11 | 22.4.4 [map] | `map` constructor accepting an allocator as single parameter should be explicit | Yes |  |
133(i) | TC1 | 22.4.4 [map] | map missing get_allocator() | Yes |  |
140(i) | NAD Editorial | 22.4.4 [map] | map<Key, T>::value_type does not satisfy the assignable requirement | Yes |  |
1296(i) | NAD | 22.4.4 [map] | `map` and `multimap value_compare` overspecified | Yes |  |
3531(i) | New | 22.4.4.1 [map.overview] | LWG 3025 broke previous valid code | Yes | 3 |
3025(i) | C++20 | 22.4.4.1 [map.overview] | Map-like container deduction guides should use `pair<Key, T>`, not `pair<const Key, T>` | Yes | 2 |
2354(i) | C++17 | 22.4.4.1 [map.overview] | Unnecessary copying when inserting into maps with braced-init syntax | Yes | 2 |
2469(i) | C++17 | 22.4.4.3 [map.access] | Wrong specification of Requires clause of `operator[]` for `map` and `unordered_map` | Yes | 3 |
2007(i) | C++11 | 22.4.4.3 [map.access] | Incorrect specification of return value for `map<>::at()` | Yes |  |
334(i) | CD1 | 22.4.4.3 [map.access] | map::operator[] specification forces inefficient implementation | Yes |  |
703(i) | CD1 | 22.4.4.3 [map.access] | `map::at()` need a complexity specification | Yes |  |
2274(i) | Resolved | 22.4.4.3 [map.access] | Does `map::operator[]` value-initialize or default-insert a missing element? | Yes | 3 |
2464(i) | C++17 | 22.4.4.4 [map.modifiers] | `try_emplace` and `insert_or_assign` misspecified | Yes | 2 |
2571(i) | C++17 | 22.4.4.4 [map.modifiers] | §[map.modifiers]/2 imposes nonsensical requirement on `insert(InputIterator, InputIterator)` | Yes | 0 |
2005(i) | C++14 | 22.4.4.4 [map.modifiers] | `unordered_map::insert(T&&)` protection should apply to `map` too | Yes |  |
1424(i) | C++11 | 22.4.5 [multimap] | `multimap` constructor accepting an allocator as a single parameter should be explicit | Yes |  |
1091(i) | NAD | 22.4.5.3 [multimap.modifiers] | Multimap description confusing | Yes |  |
1425(i) | C++11 | 22.4.6 [set] | `set` constructor accepting an allocator as a single parameter should be explicit | Yes |  |
214(i) | CD1 | 22.4.6 [set] | set::find() missing const overload | Yes |  | 450
450(i) | Dup | 22.4.6 [set] | set::find is inconsistent with associative container requirements | Yes |  | 214
2076(i) | C++17 | 22.4.6.2 [set.cons] | Bad `CopyConstructible` requirement in set constructors | Yes | 3 |
1426(i) | C++11 | 22.4.7 [multiset] | `multiset` constructor accepting an allocator as a single parameter should be explicit | Yes |  |
2713(i) | New | 22.5 [unord] | More missing allocator-extended constructors for unordered containers | Yes | 3 |
2230(i) | C++17 | 22.5 [unord] | "see below" for initializer-list constructors of unordered containers | Yes | 4 |
2050(i) | C++14 | 22.5 [unord] | Unordered associative containers do not use `allocator_traits` to define member types | Yes |  |
676(i) | C++11 | 22.5 [unord] | Moving the unordered containers | Yes |  |
691(i) | CD1 | 22.5 [unord] | const_local_iterator cbegin, cend missing from TR1 | Yes |  |
852(i) | CD1 | 22.5 [unord] | unordered containers `begin(n)` mistakenly `const` | Yes |  |
1248(i) | Resolved | 22.5 [unord] | Equality comparison for unordered containers | Yes |  |
528(i) | NAD | 22.5 [unord] | `const_iterator` `iterator` issue when they are the same type | Yes |  |
2026(i) | NAD | 22.5 [unord] | `hash` should be `std` qualified for unordered container | Yes |  |
1427(i) | C++11 | 22.5.4 [unord.map] | `unordered_map` constructor accepting an allocator as a single parameter should be explicit | Yes |  |
1519(i) | C++11 | 22.5.4 [unord.map] | bucketsize() const only for unordered set | Yes |  |
761(i) | CD1 | 22.5.4.3 [unord.map.elem] | `unordered_map` needs an `at()` member function | Yes |  |
1428(i) | C++11 | 22.5.5 [unord.multimap] | `unordered_multimap` constructor accepting an allocator as a single parameter should be explicit | Yes |  |
1429(i) | C++11 | 22.5.6 [unord.set] | `unordered_set` constructor accepting an allocator as a single parameter should be explicit | Yes |  |
2982(i) | C++20 | 22.5.6.1 [unord.set.overview] | Making `size_type` consistent in associative container deduction guides | Yes | 2 |
1430(i) | C++11 | 22.5.7 [unord.multiset] | `unordered_multiset` constructor accepting an allocator as a single parameter should be explicit | Yes |  |
2566(i) | C++17 | 22.6 [container.adaptors] | Requirements on the first template parameter of container adaptors | Yes | 0 |
2194(i) | C++14 | 22.6 [container.adaptors] | Impossible container requirements for adaptor types | Yes |  |
1199(i) | C++11 | 22.6 [container.adaptors] | Missing extended copy constructor in container adaptors | Yes |  |
1194(i) | C++11 | 22.6 [container.adaptors] | Unintended `queue` constructor | Yes |  |
1198(i) | C++11 | 22.6 [container.adaptors] | Container adaptor swap: member or non-member? | Yes |  |
2915(i) | Resolved | 22.6 [container.adaptors] | The three container adapters should each have a deduction guide | Yes |  |
756(i) | Resolved | 22.6 [container.adaptors] | Container adaptors push | Yes |  |
1421(i) | Resolved | 22.6 [container.adaptors] | Accidental move-only library types due to new core language rules | Yes |  | 1350
2783(i) | C++20 | 22.6.4.1 [queue.defn] | `stack::emplace()` and `queue::emplace()` should return `decltype(auto)` | Yes | 2 |
3189(i) | New | 22.6.5 [priority.queue] | Missing requirement for `std::priority_queue` | No | 3 |
3506(i) | WP | 22.6.5 [priority.queue] | Missing allocator-extended constructors for `priority_queue` | Yes | 3 |
3522(i) | WP | 22.6.5 [priority.queue] | Missing requirement on `InputIterator` template parameter for `priority_queue` constructors | Yes |  |
3529(i) | WP | 22.6.5 [priority.queue] | `priority_queue(first, last)` should construct `c` with `(first, last)` | Yes |  |
2684(i) | C++17 | 22.6.5 [priority.queue] | priority_queue lacking comparator typedef | Yes | 0 |
2552(i) | NAD | 22.6.5 [priority.queue] | `priority_queue` doesn't work with move-only types | Yes | 3 |
1196(i) | Resolved | 22.6.5.2 [priqueue.cons] | move semantics undefined for priority_queue | Yes |  |
2537(i) | C++17 | 22.6.5.3 [priqueue.cons.alloc] | Constructors for `priority_queue` taking allocators should call `make_heap` | Yes | 0 |
3161(i) | Open | 22.6.6 [stack] | Container adapters mandate use of `emplace_back` but don't require it | Yes | 3 |
1186(i) | NAD Concepts | 22.6.6 [stack] | Forward list could model a stack | Yes |  |
976(i) | Resolved | 22.6.6.2 [stack.defn] | Class template `std::stack` should be movable | Yes |  |
3203(i) | New | 22.7.3.1 [span.overview] | `span` element access invalidation | Yes | 2 |
3102(i) | C++20 | 22.7.3.1 [span.overview] | Clarify `span iterator` and `const_iterator` behavior | Yes | 0 |
3144(i) | C++20 | 22.7.3.1 [span.overview] | `span` does not have a `const_pointer` typedef | Yes | 0 |
3369(i) | C++20 | 22.7.3.1 [span.overview] | `span`'s deduction-guide for built-in arrays doesn't work | Yes | 0 |
3100(i) | C++20 | 22.7.3.2 [span.cons] | Unnecessary and confusing "empty `span`" wording | Yes | 0 |
3101(i) | C++20 | 22.7.3.2 [span.cons] | `span`'s `Container` constructors need another constraint | Yes | 1 |
3198(i) | C++20 | 22.7.3.2 [span.cons] | Bad constraint on `std::span::span()` | Yes |  |
3255(i) | C++20 | 22.7.3.2 [span.cons] | `span`'s `array` constructor is too strict | Yes | 2 |
3358(i) | C++20 | 22.7.3.2 [span.cons] | §[span.cons] is mistaken that `to_address` can throw | Yes | 0 |
3103(i) | C++20 | 22.7.3.4 [span.sub] | Errors in taking subview of `span` should be ill-formed where possible | Yes | 3 |
3320(i) | C++20 | 22.7.3.7 [span.iterators] | `span::cbegin/cend` methods produce different results than `std::[ranges::]cbegin/cend` | Yes | 0 |

## Section 23 (170 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2061(i) | C++14 | 23.2 [iterator.synopsis] | `make_move_iterator` and arrays | Yes |  |
2128(i) | C++14 | 23.2 [iterator.synopsis] | Absence of global functions `cbegin/cend` | Yes |  |
1320(i) | NAD | 23.2 [iterator.synopsis] | Header for `iter_swap` | Yes |  |
1128(i) | NAD Concepts | 23.2 [iterator.synopsis] | Missing definition of `iterator_traits<T*>` | Yes |  |
1213(i) | Open | 23.3 [iterator.requirements] | Meaning of valid and singular iterator underspecified | No | 4 |
2578(i) | C++17 | 23.3 [iterator.requirements] | Iterator requirements should reference iterator traits | Yes | 3 |
1185(i) | Resolved | 23.3 [iterator.requirements] | Iterator categories and output iterators | Yes |  |
1210(i) | Resolved | 23.3 [iterator.requirements] | Iterator reachability should not require a container | Yes |  |
1212(i) | Resolved | 23.3 [iterator.requirements] | result of post-increment/decrement operator | Yes |  |
408(i) | NAD Editorial | 23.3 [iterator.requirements] | Is `vector<reverse_iterator<char*> >` forbidden? | Yes |  |
446(i) | NAD Editorial | 23.3 [iterator.requirements] | Iterator equality between different containers | Yes |  |
2107(i) | NAD | 23.3 [iterator.requirements] | Some iterator category should guarantee the lifetime of references | Yes |  |
3259(i) | C++20 | 23.3.1 [iterator.requirements.general] | The definition of constexpr iterators should be adjusted | Yes | 0 |
2375(i) | Resolved | 23.3.1 [iterator.requirements.general] | Is [iterator.requirements.general]/9 too broadly applied? | Yes | 3 |
3110(i) | Resolved | 23.3.1 [iterator.requirements.general] | Contiguous Iterators should always be Random-Access | Yes | 3 |
3615(i) | New | 23.3.2.1 [incrementable.traits] | The last specialization of `incrementable_traits` has wrong operand types | Yes | 3 |
3541(i) | WP | 23.3.2.2 [readable.traits] | `indirectly_readable_traits` should be SFINAE-friendly for all types | Yes |  |
3446(i) | WP | 23.3.2.2 [readable.traits] | `indirectly_readable_traits` ambiguity for types with both `value_type` and `element_type` | Yes | 2 |
3287(i) | New | 23.3.2.3 [iterator.traits] | Exposition-only `cpp17-input-iterator` concept is needlessly complex | Yes | 3 |
3420(i) | WP | 23.3.2.3 [iterator.traits] | `cpp17-iterator` should check that the type looks like an iterator first | Yes | 0 |
2952(i) | C++20 | 23.3.2.3 [iterator.traits] | `iterator_traits` should work for pointers to cv `T` | Yes | 0 |
445(i) | CD1 | 23.3.2.3 [iterator.traits] | iterator_traits::reference unspecified for some iterator categories | Yes |  |
3283(i) | Resolved | 23.3.2.3 [iterator.traits] | Types satisfying `input_iterator` but not `equality_comparable` look like C++17 output iterators | Yes | 2 |
3289(i) | Resolved | 23.3.2.3 [iterator.traits] | Cannot opt out of C++17 iterator-ness without also opting out of C++20 iterator-ness | Yes | 2 |
2951(i) | Resolved | 23.3.2.3 [iterator.traits] | `iterator_traits` should SFINAE for `void*` and function pointers | Yes | 3 |
1127(i) | NAD Concepts | 23.3.2.3 [iterator.traits] | rvalue references and iterator traits | Yes |  |
3247(i) | C++20 | 23.3.3.1 [iterator.cust.move] | `ranges::iter_move` should perform ADL-only lookup of `iter_move` | Yes | 2 |
3299(i) | C++20 | 23.3.3.1 [iterator.cust.move] | Pointers don't need customized iterator behavior | Yes | 0 |
765(i) | C++11 | 23.3.4 [iterator.concepts] | More on iterator validity | Yes |  |
198(i) | CD1 | 23.3.4 [iterator.concepts] | Validity of pointers and references unspecified after iterator destruction | Yes |  |
346(i) | CD1 | 23.3.4 [iterator.concepts] | Some iterator member functions should be const | Yes |  |
407(i) | CD1 | 23.3.4 [iterator.concepts] | Can singular iterators be destroyed? | Yes |  |
208(i) | TC1 | 23.3.4 [iterator.concepts] | Unnecessary restriction on past-the-end iterators | Yes |  |
304(i) | NAD | 23.3.4 [iterator.concepts] | Must `*a` return an lvalue when `a` is an input iterator? | Yes |  |
3279(i) | Resolved | 23.3.4.2 [iterator.concept.readable] | `shared_ptr<int>&` does not not satisfy `readable` | Yes | 1 |
3467(i) | WP | 23.3.4.4 [iterator.concept.winc] | `bool` can't be an integer-like type | Yes | 0 |
3367(i) | C++20 | 23.3.4.4 [iterator.concept.winc] | Integer-class conversions should not throw | Yes | 0 |
3366(i) | Resolved | 23.3.4.4 [iterator.concept.winc] | Narrowing conversions between integer and integer-class types | Yes | 3 |
3376(i) | Resolved | 23.3.4.4 [iterator.concept.winc] | "integer-like class type" is too restrictive | Yes | 3 |
3575(i) | Resolved | 23.3.4.4 [iterator.concept.winc] | `<=>` for integer-class types isn't consistently specified | Yes | 3 |
3183(i) | C++20 | 23.3.4.8 [iterator.concept.sizedsentinel] | Normative permission to specialize Ranges variable templates | Yes | 0 |
3277(i) | C++20 | 23.3.4.13 [iterator.concept.random.access] | Pre-increment on prvalues is not a requirement of `weakly_incrementable` | Yes | 0 |
3284(i) | C++20 | 23.3.4.13 [iterator.concept.random.access] | `random_access_iterator` semantic constraints accidentally promote difference type using unary negate | Yes | 0 |
3607(i) | WP | 23.3.4.14 [iterator.concept.contiguous] | `contiguous_iterator` should not be allowed to have custom `iter_move` and `iter_swap` behavior | Yes |  |
2437(i) | C++17 | 23.3.5.2 [iterator.iterators] | `iterator_traits<OutIt>::reference` can and can't be `void` | Yes | 3 |
1009(i) | NAD | 23.3.5.2 [iterator.iterators] | `InputIterator` post-increment dangerous | Yes |  |
2962(i) | Open | 23.3.5.3 [input.iterators] | Iterators of Containers of move-only types do not model `InputIterator` | Yes | 2 |
484(i) | Open | 23.3.5.3 [input.iterators] | Convertible to `T` | No | 2 |
98(i) | CD1 | 23.3.5.3 [input.iterators] | Input iterator requirements are badly written | Yes |  |
558(i) | NAD Editorial | 23.3.5.3 [input.iterators] | lib.input.iterators Defect | Yes |  |
392(i) | NAD | 23.3.5.3 [input.iterators] | 'equivalence' for input iterators | Yes |  |
493(i) | NAD | 23.3.5.3 [input.iterators] | Undefined Expression in Input Iterator Note Title | Yes |  |
2035(i) | Open | 23.3.5.4 [output.iterators] | Output iterator requirements are broken | Yes | 3 |
2038(i) | Open | 23.3.5.4 [output.iterators] | Missing definition for `incrementable` iterator | No | 3 |
324(i) | CD1 | 23.3.5.4 [output.iterators] | Do output iterators have value types? | Yes |  |
485(i) | Resolved | 23.3.5.4 [output.iterators] | output iterator insufficiently constrained | Yes |  |
200(i) | CD1 | 23.3.5.5 [forward.iterators] | Forward iterator requirements don't allow constant iterators | Yes |  |
478(i) | CD1 | 23.3.5.5 [forward.iterators] | Should forward iterator requirements table have a line for r->m? | Yes |  | 477
1311(i) | Resolved | 23.3.5.5 [forward.iterators] | multi-pass property of Forward Iterator underspecified | Yes |  |
476(i) | NAD | 23.3.5.5 [forward.iterators] | Forward Iterator implied mutability | Yes |  |
477(i) | Dup | 23.3.5.5 [forward.iterators] | Operator-> for const forward iterators | Yes |  | 478
1084(i) | NAD Concepts | 23.3.5.5 [forward.iterators] | Concept `ForwardIterator` should provide default implementation for post-increment | Yes |  |
383(i) | CD1 | 23.3.5.6 [bidirectional.iterators] | Bidirectional iterator assertion typo | Yes |  |
299(i) | NAD Editorial | 23.3.5.6 [bidirectional.iterators] | Incorrect return types for iterator dereference | Yes |  |
1085(i) | NAD Concepts | 23.3.5.6 [bidirectional.iterators] | `BidirectionalIterator` concept should provide default implementation for post-decrement | Yes |  |
3236(i) | WP | 23.3.5.7 [random.access.iterators] | Random access iterator requirements lack limiting relational operators domain to comparing those from the same range | Yes | 3 |
2519(i) | C++17 | 23.3.5.7 [random.access.iterators] | Iterator `operator-=` has gratuitous undefined behaviour | Yes | 2 |
1079(i) | C++11 | 23.3.5.7 [random.access.iterators] | UK-265: `RandomAccessIterator`'s `operator-` has nonsensical effects clause | Yes |  |
448(i) | CD1 | 23.3.5.7 [random.access.iterators] | Random Access Iterators over abstract classes | Yes |  |
458(i) | NAD | 23.3.5.7 [random.access.iterators] | 24.1.5 contains unintended limitation for `operator-` | Yes |  |
1010(i) | NAD Concepts | 23.3.5.7 [random.access.iterators] | `operator-=` should use default in concept | Yes |  |
3197(i) | New | 23.4.3 [iterator.operations] | `std::prev` should not require `BidirectionalIterator` | Yes | 3 |
3439(i) | New | 23.4.3 [iterator.operations] | "`Distance`" template parameter is underspecified | No | 3 |
3344(i) | New | 23.4.3 [iterator.operations] | `advance(i, most-negative)` and `prev(i, most-negative)` | Yes | 3 |
2931(i) | Open | 23.4.3 [iterator.operations] | Missed optimization opportunity with single-argument `std::next` | No | 3 |
2353(i) | C++17 | 23.4.3 [iterator.operations] | `std::next` is over-constrained | Yes | 4 |
1011(i) | C++11 | 23.4.3 [iterator.operations] | `next/prev` wrong iterator type | Yes |  |
940(i) | Resolved | 23.4.3 [iterator.operations] | `std::distance` | Yes |  |
204(i) | NAD | 23.4.3 [iterator.operations] | distance(first, last) when "last" is before "first" | Yes |  |
3306(i) | WP | 23.4.4.2 [range.iter.op.advance] | `ranges::advance` violates its preconditions | Yes | 2 |
3453(i) | WP | 23.4.4.2 [range.iter.op.advance] | Generic code cannot call `ranges::advance(i, s)` | Yes | 2 |
3664(i) | New | 23.4.4.3 [range.iter.op.distance] | LWG 3392 broke `std::ranges::distance(a, a+3)` | Yes | 2 |
3392(i) | WP | 23.4.4.3 [range.iter.op.distance] | `ranges::distance()` cannot be used on a move-only iterator with a sized sentinel | Yes | 3 |
2858(i) | New | 23.5.1 [reverse.iterators] | LWG 2472: actually an incompatibility with C++03 | Yes | 4 |
2285(i) | C++14 | 23.5.1 [reverse.iterators] | `make_reverse_iterator` | Yes |  |
280(i) | CD1 | 23.5.1 [reverse.iterators] | Comparison of reverse_iterator to const reverse_iterator | Yes |  |
2208(i) | Resolved | 23.5.1 [reverse.iterators] | `std::reverse_iterator` should be a literal type | Yes | 3 |
3623(i) | New | 23.5.1.1 [reverse.iterators.general] | Uses of `std::reverse_iterator` with containers should not require manually including `<iterator>` | Yes | 3 |
2595(i) | New | 23.5.1.2 [reverse.iterator] | `reverse_iterator::operator[]`'s return type revisited | Yes | 3 |
2360(i) | C++14 | 23.5.1.2 [reverse.iterator] | `reverse_iterator::operator*()` is unimplementable | Yes | 1 |
235(i) | CD1 | 23.5.1.2 [reverse.iterator] | No specification of default ctor for reverse_iterator | Yes |  |
3602(i) | New | 23.5.1.4 [reverse.iter.cons] | `reverse_iterator`'s converting assignment is overconstrained | Yes | 3 |
1012(i) | C++11 | 23.5.1.4 [reverse.iter.cons] | `reverse_iterator` default ctor should value initialize | Yes |  |
2188(i) | C++14 | 23.5.1.6 [reverse.iter.elem] | Reverse iterator does not fully support targets that overload `operator&` | Yes | 1 |
386(i) | CD1 | 23.5.1.6 [reverse.iter.elem] | Reverse iterator's operator[] has impossible return type | Yes |  |
1052(i) | Resolved | 23.5.1.6 [reverse.iter.elem] | `reverse_iterator::operator->` should also support smart pointers | Yes |  | 2775
1051(i) | NAD | 23.5.1.6 [reverse.iter.elem] | Specify subscript operation return types of `reverse_iterator` and `move_iterator` | Yes |  |
2204(i) | NAD | 23.5.1.6 [reverse.iter.elem] | `reverse_iterator` should not require a second copy of the base iterator | Yes |  |
2347(i) | NAD | 23.5.1.6 [reverse.iter.elem] | `reverse_iterator::operator[]` calls const version of `current[]` | Yes | 2 |
2775(i) | Dup | 23.5.1.6 [reverse.iter.elem] | `reverse_iterator` is does not compile for fancy pointers | Yes |  | 1052
99(i) | NAD | 23.5.1.8 [reverse.iter.cmp] | Reverse_iterator comparisons completely wrong | Yes |  |
685(i) | CD1 | 23.5.1.9 [reverse.iter.nonmember] | reverse_iterator/move_iterator difference has invalid signatures | Yes |  |
2916(i) | NAD | 23.5.2 [insert.iterators] | Insert iterators should each have an instantiation guide to initialize from a container | Yes |  |
100(i) | NAD | 23.5.2 [insert.iterators] | Insert iterators/ostream_iterators overconstrained | Yes |  |
977(i) | NAD | 23.5.2 [insert.iterators] | insert iterators inefficient for expensive to move types | Yes |  |
1062(i) | NAD | 23.5.2 [insert.iterators] | Missing insert_iterator for stacks/queues | Yes |  |
3415(i) | NAD | 23.5.2.2 [back.insert.iterator] | `back_insert_iterator` fails when a container is also its value type | Yes |  |
903(i) | NAD | 23.5.2.2 [back.insert.iterator] | `back_insert_iterator` issue | Yes |  |
2324(i) | C++14 | 23.5.2.2.1 [back.insert.iter.ops] | Insert iterator constructors should use `addressof()` | Yes | 0 |
1334(i) | C++11 | 23.5.2.2.1 [back.insert.iter.ops] | Insert iterators are broken for some proxy containers compared to C++03 | Yes |  |
901(i) | NAD | 23.5.2.4 [insert.iterator] | insert iterators can move from lvalues | Yes |  |
561(i) | CD1 | 23.5.2.4.2 [inserter] | inserter overly generic | Yes |  |
3593(i) | WP | 23.5.3 [move.iterators] | Several iterators' `base() const &` and `lazy_split_view::outer-iterator::value_type::end()` missing `noexcept` | Yes |  |
3391(i) | WP | 23.5.3 [move.iterators] | Problems with `counted_iterator/move_iterator::base() const &` | Yes | 2 |
2106(i) | C++17 | 23.5.3 [move.iterators] | `move_iterator` wrapping iterators returning prvalues | Yes | 3 |
979(i) | NAD Editorial | 23.5.3 [move.iterators] | Bad example | Yes |  |
680(i) | CD1 | 23.5.3.2 [move.iterator] | move_iterator `operator->` return | Yes |  |
1211(i) | Resolved | 23.5.3.2 [move.iterator] | Move iterators should be restricted as input iterators | Yes |  |
3265(i) | WP | 23.5.3.4 [move.iter.cons] | `move_iterator`'s conversions are more broken after P1207 | Yes | 2 |
3435(i) | WP | 23.5.3.4 [move.iter.cons] | `three_way_comparable_with<reverse_iterator<int*>, reverse_iterator<const int*>>` | Yes | 2 |
872(i) | C++11 | 23.5.3.6 [move.iter.elem] | `move_iterator::operator[]` has wrong return type | Yes |  |
3293(i) | WP | 23.5.3.9 [move.iter.nonmember] | `move_iterator operator+()` has incorrect constraints | Yes | 3 |
3390(i) | C++20 | 23.5.3.9 [move.iter.nonmember] | `make_move_iterator()` cannot be used to construct a `move_iterator` for a move-only iterator | Yes | 0 |
3574(i) | WP | 23.5.4.1 [common.iterator] | `common_iterator` should be completely `constexpr`-able | Yes | 3 |
3385(i) | C++20 | 23.5.4.1 [common.iterator] | `common_iterator` is not sufficiently constrained for non-copyable iterators | Yes | 0 |
3660(i) | WP | 23.5.4.2 [common.iter.types] | `iterator_traits<common_iterator>::pointer` should conform to §[iterator.traits] | Yes |  |
3672(i) | Tentatively Ready | 23.5.4.4 [common.iter.access] | `common_iterator::operator->()` should return by value | Yes |  |
3595(i) | WP | 23.5.4.4 [common.iter.access] | Exposition-only classes `proxy` and `postfix-proxy` for `common_iterator` should be fully `constexpr` | Yes |  |
3601(i) | WP | 23.5.4.5 [common.iter.nav] | `common_iterator`'s `postfix-proxy` needs `indirectly_readable` | Yes |  |
3546(i) | WP | 23.5.4.5 [common.iter.nav] | `common_iterator`'s `postfix-proxy` is not quite right | Yes |  |
3472(i) | WP | 23.5.6 [iterators.counted] | `counted_iterator` is missing preconditions | Yes |  |
3543(i) | WP | 23.5.6.1 [counted.iterator] | Definition of when `counted_iterators` refer to the same sequence isn't quite right | Yes |  |
3408(i) | Resolved | 23.5.6.1 [counted.iterator] | LWG 3291 reveals deficiencies in `counted_iterator` | Yes | 2 |
3389(i) | C++20 | 23.5.6.2 [counted.iter.const] | A move-only iterator still does not have a `counted_iterator` | Yes | 0 |
3643(i) | WP | 23.5.6.5 [counted.iter.nav] | Missing `constexpr` in `std::counted_iterator` | Yes |  |
2576(i) | C++17 | 23.6 [stream.iterators] | `istream_iterator` and `ostream_iterator` should use `std::addressof` | Yes | 0 |
1086(i) | NAD Concepts | 23.6 [stream.iterators] | Stream iterators need to be concept-constrained templates | Yes |  |
788(i) | C++11 | 23.6.2 [istream.iterator] | Ambiguity in [istream.iterator] | Yes |  |
838(i) | C++11 | 23.6.2 [istream.iterator] | Can an end-of-stream iterator become a non-end-of-stream one? | Yes |  |
245(i) | NAD | 23.6.2 [istream.iterator] | Which operations on `istream_iterator` trigger input operations? | Yes |  |
3600(i) | New | 23.6.2.2 [istream.iterator.cons] | Making `istream_iterator` copy constructor trivial is an ABI break | Yes | 3 |
2793(i) | C++17 | 23.6.2.2 [istream.iterator.cons] | Awkward conflation of trivial special members of `istream_iterator` | Yes |  |
2878(i) | C++17 | 23.6.2.2 [istream.iterator.cons] | Missing `DefaultConstructible` requirement for `istream_iterator` default constructor | Yes |  |
2804(i) | C++17 | 23.6.2.2 [istream.iterator.cons] | Unconditional `constexpr` default constructor for `istream_iterator` | Yes | 0 |
1280(i) | C++11 | 23.6.2.2 [istream.iterator.cons] | Initialization of stream iterators | Yes |  |
1129(i) | Resolved | 23.6.2.2 [istream.iterator.cons] | `istream(buf)_iterator` should support literal sentinel value | Yes |  |
260(i) | CD1 | 23.6.2.3 [istream.iterator.ops] | Inconsistent return type of `istream_iterator::operator++(int)` | Yes |  |
261(i) | CD1 | 23.6.2.3 [istream.iterator.ops] | Missing description of `istream_iterator::operator!=` | Yes |  |
349(i) | CD1 | 23.6.3 [ostream.iterator] | Minor typographical error in ostream_iterator | Yes |  |
1125(i) | NAD | 23.6.3.3 [ostream.iterator.ops] | ostream_iterator does not work with movable types | Yes |  |
3107(i) | New | 23.6.4 [istreambuf.iterator] | `istreambuf_iterator` has public exposition-only member | Yes | 4 |
3188(i) | New | 23.6.4 [istreambuf.iterator] | `istreambuf_iterator::pointer` should not be unspecified | Yes | 3 |
2366(i) | New | 23.6.4 [istreambuf.iterator] | `istreambuf_iterator` end-of-stream equality | No | 3 |
2790(i) | C++17 | 23.6.4 [istreambuf.iterator] | Missing specification of `istreambuf_iterator::operator->` | Yes | 3 |
659(i) | C++11 | 23.6.4 [istreambuf.iterator] | `istreambuf_iterator` should have an `operator->()` | Yes |  |
110(i) | TC1 | 23.6.4 [istreambuf.iterator] | istreambuf_iterator::equal not const | Yes |  |
3108(i) | New | 23.6.4.2 [istreambuf.iterator.proxy] | `istreambuf_iterator::proxy::operator*` should be `const` | Yes | 3 |
2544(i) | C++17 | 23.6.4.3 [istreambuf.iterator.cons] | `istreambuf_iterator(basic_streambuf<charT, traits>* s)` effects unclear when `s` is `0` | Yes | 3 |
1126(i) | C++11 | 23.6.4.4 [istreambuf.iterator.ops] | `istreambuff_iterator::equal` needs a const & parameter | Yes |  |
39(i) | TC1 | 23.6.4.4 [istreambuf.iterator.ops] | istreambuf_iterator<>::operator++(int) definition garbled | Yes |  |
111(i) | NAD | 23.6.4.4 [istreambuf.iterator.ops] | `istreambuf_iterator::equal` overspecified, inefficient | Yes |  |
112(i) | TC1 | 23.6.5.2 [ostreambuf.iter.cons] | Minor typo in `ostreambuf_iterator` constructor | Yes |  |
3537(i) | New | 23.7 [iterator.range] | §[iterator.range] Missing `noexcept` for `std::rbegin`/`rend` for arrays and `initializer_list` | No | 3 |
2457(i) | New | 23.7 [iterator.range] | `std::begin()` and `std::end()` do not support multi-dimensional arrays correctly | No | 3 |
3009(i) | C++20 | 23.7 [iterator.range] | Including `<string_view>` doesn't provide `std::size/empty/data` | Yes | 0 |
3208(i) | C++20 | 23.7 [iterator.range] | `Boolean`'s expression requirements are ordered inconsistently | Yes | 0 |
3300(i) | C++20 | 23.7 [iterator.range] | Non-array `ssize` overload is underconstrained | Yes | 3 |
2812(i) | C++17 | 23.7 [iterator.range] | Range access is available with `<string_view>` | Yes | 0 |
2280(i) | C++14 | 23.7 [iterator.range] | `begin/end` for arrays should be `constexpr` and `noexcept` | Yes |  |
3207(i) | NAD | 23.7 [iterator.range] | `N` in `ssize(const T (&)[N])` should be `size_t` | Yes |  |

## Section 24 (94 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3302(i) | C++20 | 24.2 [ranges.syn] | Range adaptor objects `keys` and `values` are unspecified | Yes | 1 |
3335(i) | C++20 | 24.2 [ranges.syn] | Resolve C++20 NB comments US 273 and GB 274 | Yes | 1 |
3351(i) | C++20 | 24.2 [ranges.syn] | `ranges::enable_safe_range` should not be constrained | Yes | 0 |
3379(i) | C++20 | 24.2 [ranges.syn] | "`safe`" in several library names is misleading | Yes | 1 |
3398(i) | C++20 | 24.2 [ranges.syn] | `tuple_element_t` is also wrong for `const subrange` | Yes | 0 |
3258(i) | Resolved | 24.3.2 [range.access.begin] | Range access and `initializer_list` | Yes | 3 |
3333(i) | NAD | 24.3.4 [range.access.cbegin] | `ranges::cbegin/ranges::cend`, (and maybe `ranges::crbegin/ranges::crend`) are under-specified to allow rvalue-arrays | Yes |  |
3368(i) | Resolved | 24.3.10 [range.prim.size] | Exactly when does `size` return `end - begin`? | Yes | 0 |
3403(i) | WP | 24.3.11 [range.prim.ssize] | Domain of `ranges::ssize(E)` doesn't match `ranges::size(E)` | Yes | 2 |
3361(i) | WP | 24.4.2 [range.range] | `safe_range<SomeRange&>` case | Yes | 3 |
3559(i) | WP | 24.4.3 [range.sized] | Semantic requirements of `sized_range` is circular | Yes |  |
3264(i) | C++20 | 24.4.3 [range.sized] | `sized_range` and `ranges::size` redundantly use `disable_sized_range` | Yes | 1 |
3326(i) | C++20 | 24.4.4 [range.view] | `enable_view` has false positives | Yes | 0 |
3452(i) | Resolved | 24.4.4 [range.view] | Are views really supposed to have strict `𝒪(1)` destruction? | Yes | 2 |
3481(i) | WP | 24.4.5 [range.refinements] | `viewable_range` mishandles lvalue move-only views | Yes | 2 |
3375(i) | C++20 | 24.4.5 [range.refinements] | `decay` in `viewable_range` should be `remove_cvref` | Yes | 0 |
3381(i) | C++20 | 24.4.5 [range.refinements] | `begin` and `data` must agree for `contiguous_range` | Yes | 0 |
3549(i) | WP | 24.5.3 [view.interface] | `view_interface` is overspecified to derive from `view_base` | Yes | 2 |
3646(i) | LEWG | 24.5.3.1 [view.interface.general] | `std::ranges::view_interface::size` returns a signed type | Yes | 3 |
3470(i) | WP | 24.5.4 [range.subrange] | `convertible-to-non-slicing` seems to reject valid case | Yes | 3 |
3589(i) | WP | 24.5.4 [range.subrange] | The `const` lvalue reference overload of `get` for `subrange` does not constrain `I` to be `copyable` when `N == 0` | Yes | 3 |
3404(i) | WP | 24.5.4 [range.subrange] | Finish removing `subrange`'s conversions from `pair-like` | Yes | 0 |
3281(i) | C++20 | 24.5.4 [range.subrange] | Conversion from `pair-like` types to `subrange` is a silent semantic promotion | Yes | 1 |
3282(i) | C++20 | 24.5.4 [range.subrange] | `subrange` converting constructor should disallow derived to base conversions | Yes | 1 |
3179(i) | C++20 | 24.5.4.2 [range.subrange.ctor] | `subrange` should always model `Range` | Yes | 0 |
3433(i) | WP | 24.5.4.3 [range.subrange.access] | `subrange::advance(n)` has UB when `n < 0` | Yes | 2 |
3551(i) | WP | 24.5.5 [range.dangling] | `borrowed_{iterator,subrange}_t` are overspecified | Yes |  |
3428(i) | WP | 24.6.3.2 [range.single.view] | `single_view`'s in place constructor should be explicit | Yes | 0 |
3597(i) | New | 24.6.4.2 [range.iota.view] | Unsigned integer types don't model `advanceable` | No | 3 |
3614(i) | New | 24.6.4.2 [range.iota.view] | `iota_view::size` and the most negative signed integer values | Yes | 3 |
3610(i) | WP | 24.6.4.2 [range.iota.view] | `iota_view::size` sometimes rejects integer-class types | Yes |  |
3523(i) | WP | 24.6.4.2 [range.iota.view] | `iota_view::sentinel` is not always `iota_view`'s sentinel | Yes |  |
3292(i) | C++20 | 24.6.4.2 [range.iota.view] | `iota_view` is under-constrained | Yes |  |
3670(i) | Tentatively Ready | 24.6.4.3 [range.iota.iterator] | Cpp17InputIterators don't have integer-class difference types | Yes |  |
3580(i) | WP | 24.6.4.3 [range.iota.iterator] | `iota_view's iterator`'s binary `operator+` should be improved | Yes |  |
3291(i) | C++20 | 24.6.4.3 [range.iota.iterator] | `iota_view::iterator` has the wrong `iterator_category` | Yes | 0 |
3388(i) | C++20 | 24.6.4.3 [range.iota.iterator] | `view` iterator types have ill-formed `<=>` operators | Yes | 0 |
3609(i) | New | 24.6.4.4 [range.iota.sentinel] | `std::ranges::iota_view<int, long>` has non-subtractable `iterator` and `sentinel` types | Yes | 3 |
3679(i) | New | 24.6.5 [range.istream] | Is `<ranges>` sufficient for `istream_view`? | No | 3 |
3568(i) | WP | 24.6.5.2 [range.istream.view] | `basic_istream_view` needs to initialize `value_` | Yes |  |
3489(i) | New | 24.6.5.3 [range.istream.iterator] | Improve `istream_view` wording | Yes | 3 |
3397(i) | C++20 | 24.6.5.3 [range.istream.iterator] | `ranges::basic_istream_view::iterator` should not provide `iterator_category` | Yes | 1 |
3394(i) | NAD | 24.6.5.3 [range.istream.iterator] | `ranges::basic_istream_view::iterator` has an empty `iterator_traits` | Yes | 2 |
3524(i) | Resolved | 24.7 [range.adaptors] | Unimplementable narrowing and evaluation order requirements for range adaptors | Yes | 3 |
3509(i) | Resolved | 24.7.2 [range.adaptor.object] | Range adaptor objects are underspecified | Yes | 2 |
3572(i) | WP | 24.7.3 [range.copy.wrap] | `copyable-box` should be fully `constexpr` | Yes |  |
3173(i) | C++20 | 24.7.5.2 [range.ref.view] | Enable CTAD for `ref-view` | Yes | 0 |
3280(i) | C++20 | 24.7.6.2 [range.filter.view] | View converting constructors can cause constraint recursion and are unneeded | Yes | 1 |
3533(i) | WP | 24.7.6.3 [range.filter.iterator] | Make `base() const &` consistent across iterator wrappers that supports `input_iterator`s | Yes |  |
3325(i) | C++20 | 24.7.7.2 [range.transform.view] | Constrain return type of transformation function for `transform_view` | Yes | 0 |
3564(i) | SG9 | 24.7.7.3 [range.transform.iterator] | `transform_view::iterator<true>::value_type` and `iterator_category` should use `const F&` | Yes | 2 |
3618(i) | WP | 24.7.7.3 [range.transform.iterator] | Unnecessary `iter_move` for `transform_view::iterator` | Yes |  |
3520(i) | WP | 24.7.7.3 [range.transform.iterator] | `iter_move` and `iter_swap` are inconsistent for `transform_view::iterator` | Yes | 2 |
3555(i) | WP | 24.7.7.3 [range.transform.iterator] | `{transform,elements}_view::iterator::iterator_concept` should consider const-qualification of the underlying range | Yes |  |
3483(i) | WP | 24.7.7.3 [range.transform.iterator] | `transform_view::iterator`'s difference is overconstrained | Yes | 0 |
3301(i) | C++20 | 24.7.7.3 [range.transform.iterator] | `transform_view::iterator` has incorrect `iterator_category` | Yes | 1 |
3448(i) | WP | 24.7.7.4 [range.transform.sentinel] | `transform_view`'s `sentinel<false>` not comparable with `iterator<true>` | Yes | 1 |
3384(i) | C++20 | 24.7.7.4 [range.transform.sentinel] | `transform_view::sentinel` has an incorrect `operator-` | Yes | 0 |
3407(i) | WP | 24.7.8.1 [range.take.overview] | Some problems with the wording changes of P1739R4 | Yes | 2 |
3447(i) | WP | 24.7.8.2 [range.take.view] | Deduction guides for `take_view` and `drop_view` have different constraints | Yes | 0 |
3286(i) | C++20 | 24.7.8.2 [range.take.view] | `ranges::size` is not required to be valid after a call to `ranges::begin` on an input range | Yes | 0 |
3449(i) | WP | 24.7.8.3 [range.take.sentinel] | `take_view` and `take_while_view`'s `sentinel<false>` not comparable with their const iterator | Yes | 1 |
3450(i) | WP | 24.7.9.2 [range.take.while.view] | The `const` overloads of `take_while_view::begin/end` are underconstrained | Yes | 0 |
3364(i) | C++20 | 24.7.9.2 [range.take.while.view] | Initialize data members of ranges and their iterators | Yes | 0 |
3298(i) | NAD | 24.7.9.2 [range.take.while.view] | Range adaptors introduced by P1035 do not require `viewable_range` | Yes |  |
3482(i) | WP | 24.7.10.2 [range.drop.view] | `drop_view`'s `const begin` should additionally require `sized_range` | Yes | 0 |
3490(i) | WP | 24.7.11.2 [range.drop.while.view] | `ranges::drop_while_view::begin()` is missing a precondition | Yes | 0 |
3363(i) | C++20 | 24.7.11.2 [range.drop.while.view] | `drop_while_view` should opt-out of `sized_range` | Yes | 1 |
3666(i) | New | 24.7.12 [range.join] | `join_view`'s difference type is too small | No | 2 |
3474(i) | WP | 24.7.12 [range.join] | Nesting `join_view`s is broken because of CTAD | Yes |  |
3322(i) | Resolved | 24.7.12.2 [range.join.view] | Add `join_view::base()` member function | Yes | 0 |
3278(i) | Resolved | 24.7.12.2 [range.join.view] | `join_view<V>::iterator<true>` tries to write through `const join_view` ptr | Yes | 2 |
3569(i) | New | 24.7.12.3 [range.join.iterator] | `join_view` fails to support ranges of ranges with non-`default_initializable` iterators | Yes | 3 |
3535(i) | WP | 24.7.12.3 [range.join.iterator] | `join_view::iterator::iterator_category` and `::iterator_concept` lie | Yes | 2 |
3517(i) | WP | 24.7.12.3 [range.join.iterator] | `join_view::iterator`'s `iter_swap` is underconstrained | Yes |  |
3500(i) | WP | 24.7.12.3 [range.join.iterator] | `join_view::iterator::operator->()` is bogus | Yes | 0 |
3313(i) | C++20 | 24.7.12.3 [range.join.iterator] | `join_view::iterator::operator--` is incorrectly constrained | Yes | 0 |
3365(i) | NAD | 24.7.12.3 [range.join.iterator] | Rename ref-is-glvalue to deref-is-ref | Yes | 0 |
3599(i) | New | 24.7.13.2 [range.lazy.split.view] | The `const` overload of `lazy_split_view::begin` should be constrained by `const Pattern` | Yes | 3 |
3592(i) | WP | 24.7.13.2 [range.lazy.split.view] | `lazy_split_view` needs to check the simpleness of `Pattern` | Yes |  |
3591(i) | WP | 24.7.13.5 [range.lazy.split.inner] | `lazy_split_view<input_view>::inner-iterator::base() &&` invalidates outer iterators | Yes |  |
3478(i) | Resolved | 24.7.14 [range.split] | `views::split` drops trailing empty range | Yes | 2 |
3590(i) | WP | 24.7.14.2 [range.split.view] | `split_view::base() const &` is overconstrained | Yes |  |
3405(i) | WP | 24.7.16.2 [range.common.view] | `common_view`'s converting constructor is bad, too | Yes | 0 |
3494(i) | WP | 24.7.17 [range.reverse] | Allow ranges to be conditionally borrowed | Yes |  |
3387(i) | C++20 | 24.7.17.2 [range.reverse.view] | §[range.reverse.view] `reverse_view<V>` unintentionally requires `range<const V>` | Yes | 0 |
3386(i) | C++20 | 24.7.18 [range.elements] | `elements_view` needs its own `sentinel` type | Yes | 1 |
3563(i) | WP | 24.7.18.1 [range.elements.overview] | `keys_view` example is broken | Yes | 3 |
3406(i) | WP | 24.7.18.2 [range.elements.view] | `elements_view::begin()` and `elements_view::end()` have incompatible constraints | Yes | 1 |
3323(i) | C++20 | 24.7.18.2 [range.elements.view] | `has-tuple-element` helper concept needs `convertible_to` | Yes | 0 |
3492(i) | WP | 24.7.18.3 [range.elements.iterator] | Minimal improvements to `elements_view::iterator` | Yes | 0 |
3502(i) | WP | 24.7.18.3 [range.elements.iterator] | `elements_view` should not be allowed to return dangling references | Yes | 2 |
3377(i) | C++20 | 24.7.18.3 [range.elements.iterator] | `elements_view::iterator` befriends a specialization of itself | Yes | 0 |
3558(i) | NAD Editorial | 24.7.18.4 [range.elements.sentinel] | `elements_view::sentinel`'s first `operator-` has wrong return type | Yes |  |

## Section 25 (171 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2963(i) | New | 25 [algorithms] | Algorithms with underspecified iterator requirements | No | 3 |
1238(i) | Open | 25 [algorithms] | Defining algorithms taking iterator for range | No | 3 |
2173(i) | Open | 25 [algorithms] | The meaning of `operator +` in the description of the algorithms | Yes | 4 |
1205(i) | C++11 | 25 [algorithms] | Some algorithms could more clearly document their handling of empty ranges | Yes |  |
92(i) | CD1 | 25 [algorithms] | Incomplete Algorithm Requirements | Yes |  |
210(i) | TC1 | 25 [algorithms] | distance first and last confused | Yes |  |
2917(i) | Resolved | 25 [algorithms] | Parallel algorithms cannot easily work with `InputIterator`s | Yes |  |
1282(i) | NAD | 25 [algorithms] | A proposal to add `std::split` algorithm | Yes |  |
1053(i) | NAD | 25 [algorithms] | Unify algorithms with operator and function object variants | Yes |  |
631(i) | NAD | 25 [algorithms] | conflicting requirements for `BinaryPredicate` | Yes |  |
2082(i) | NAD | 25 [algorithms] | Misleading complexity requirements in `<algorithm>` | Yes |  |
2727(i) | C++17 | 25.1 [algorithms.general] | Parallel algorithms with `constexpr` specifier | Yes | 0 |
3049(i) | Open | 25.2 [algorithms.requirements] | Missing wording allowing algorithms to use copies of function objects as substitutes for their parameters | Yes | 3 |
3419(i) | WP | 25.2 [algorithms.requirements] | §[algorithms.requirements]/15 doesn't reserve as many rights as it intends to | Yes | 0 |
2932(i) | C++20 | 25.3.3 [algorithms.parallel.exec] | Constraints on parallel algorithm implementations are underspecified | Yes |  |
2718(i) | C++17 | 25.3.3 [algorithms.parallel.exec] | Parallelism bug in [algorithms.parallel.exec] p2 | Yes |  |
2880(i) | Resolved | 25.3.3 [algorithms.parallel.exec] | Relax complexity specifications for non-sequenced policies | Yes |  |
3062(i) | C++20 | 25.3.5 [algorithms.parallel.overloads] | Unnecessary `decay_t` in `is_execution_policy_v` should be `remove_cvref_t` | Yes | 0 |
3180(i) | C++20 | 25.4 [algorithm.syn] | Inconsistently named return type for `ranges::minmax_element` | Yes | 0 |
483(i) | Dup | 25.6 [alg.nonmodifying] | Heterogeneous equality and EqualityComparable | Yes |  | 283
2747(i) | C++17 | 25.6.4 [alg.foreach] | Possibly redundant `std::move` in [alg.foreach] | Yes | 0 |
1110(i) | C++11 | 25.6.4 [alg.foreach] | Is `for_each` overconstrained? | Yes |  |
475(i) | CD1 | 25.6.4 [alg.foreach] | May the function object passed to for_each modify the elements of the iterated sequence? | Yes |  |
3213(i) | Resolved | 25.6.4 [alg.foreach] | `for_each_n` and `copy_n` missing requirements for `Size` | Yes | 3 |
969(i) | NAD Editorial | 25.6.4 [alg.foreach] | What happened to Library Issue 475? | Yes |  |
290(i) | NAD | 25.6.4 [alg.foreach] | Requirements to for_each and its function object | Yes |  |
219(i) | NAD | 25.6.5 [alg.find] | `find` algorithm missing version that takes a binary predicate argument | Yes |  |
244(i) | NAD | 25.6.5 [alg.find] | Must `find`'s third argument be CopyConstructible? | Yes |  |
2150(i) | C++14 | 25.6.6 [alg.find.end] | Unclear specification of `find_end` | Yes |  |
576(i) | CD1 | 25.6.7 [alg.find.first.of] | find_first_of is overconstrained | Yes |  |
150(i) | TC1 | 25.6.7 [alg.find.first.of] | Find_first_of says integer instead of iterator | Yes |  |
240(i) | CD1 | 25.6.8 [alg.adjacent.find] | Complexity of adjacent_find() is meaningless | Yes |  |
1000(i) | NAD Concepts | 25.6.8 [alg.adjacent.find] | adjacent_find is over-constrained | Yes |  |
2404(i) | C++17 | 25.6.10 [mismatch] | `mismatch()`'s complexity needs to be updated | Yes | 0 |
3178(i) | Resolved | 25.6.10 [mismatch] | `std::mismatch` is missing an upper bound | Yes | 0 |
3560(i) | WP | 25.6.11 [alg.equal] | `ranges::equal` and `ranges::is_permutation` should short-circuit for `sized_ranges` | Yes |  |
2967(i) | NAD | 25.6.11 [alg.equal] | `std::equal` on empty ranges | Yes |  |
1431(i) | C++11 | 25.6.12 [alg.is.permutation] | `is_permutation` must be more restrictive | Yes |  |
1338(i) | C++11 | 25.6.13 [alg.search] | LWG 1205 incorrectly applied | Yes |  |
426(i) | CD1 | 25.6.13 [alg.search] | search_n(), fill_n(), and generate_n() with negative n | Yes |  |
714(i) | CD1 | 25.6.13 [alg.search] | `search_n` complexity is too lax | Yes |  |
3596(i) | NAD | 25.6.14 [alg.starts.with] | `ranges::starts_with` and `ranges::ends_with` are underspecified | Yes |  |
3089(i) | New | 25.7.1 [alg.copy] | `copy_n` should require non-overlapping ranges | Yes | 3 |
2471(i) | Open | 25.7.1 [alg.copy] | `copy_n`'s number of `InputIterator` increments unspecified | No | 3 |
2689(i) | C++17 | 25.7.1 [alg.copy] | Parallel versions of `std::copy` and `std::move` shouldn't be in order | Yes | 0 |
2039(i) | C++14 | 25.7.1 [alg.copy] | Issues with `std::reverse` and `std::copy_if` | Yes |  |
2242(i) | NAD | 25.7.1 [alg.copy] | `[uninitialized_]copy_n()` defect | Yes | 2 |
1206(i) | C++11 | 25.7.2 [alg.move] | Incorrect requires for `move_backward` and `copy_backward` | Yes |  |
187(i) | CD1 | 25.7.3 [alg.swap] | iter_swap underspecified | Yes |  |
809(i) | CD1 | 25.7.3 [alg.swap] | `std::swap` should be overloaded for array types | Yes |  |
227(i) | TC1 | 25.7.3 [alg.swap] | std::swap() should require CopyConstructible or DefaultConstructible arguments | Yes |  |
912(i) | NAD Concepts | 25.7.3 [alg.swap] | Array swap needs to be conceptualized | Yes |  |
242(i) | CD1 | 25.7.4 [alg.transform] | Side effects of function objects | Yes |  |
293(i) | NAD | 25.7.4 [alg.transform] | Order of execution in transform algorithm | Yes |  |
283(i) | CD1 | 25.7.5 [alg.replace] | std::replace() requirement incorrect/insufficient | Yes |  | 483
337(i) | CD1 | 25.7.5 [alg.replace] | replace_copy_if's template parameter should be InputIterator | Yes |  |
913(i) | NAD Concepts | 25.7.5 [alg.replace] | Superfluous requirements for replace algorithms | Yes |  |
1087(i) | NAD Concepts | 25.7.5 [alg.replace] | Incorrect `OutputIterator` concept requirements for `replace` algorithms | Yes |  |
865(i) | C++11 | 25.7.6 [alg.fill] | More algorithms that throw away information | Yes |  |
3186(i) | C++20 | 25.7.8 [alg.remove] | `ranges` removal, partition, and `partial_sort_copy` algorithms discard useful information | Yes | 1 |
2110(i) | C++14 | 25.7.8 [alg.remove] | `remove` can't swap but note says it might | Yes |  |
779(i) | CD1 | 25.7.8 [alg.remove] | Resolution of #283 incomplete | Yes |  |
367(i) | NAD | 25.7.8 [alg.remove] | remove_copy/remove_copy_if and Input Iterators | Yes |  |
489(i) | NAD | 25.7.8 [alg.remove] | std::remove / std::remove_if wrongly specified | Yes |  |
2439(i) | C++17 | 25.7.9 [alg.unique] | `unique_copy()` sometimes can't fall back to reading its output | Yes | 3 |
1241(i) | C++11 | 25.7.9 [alg.unique] | `unique_copy` needs to require `EquivalenceRelation` | Yes |  |
202(i) | CD1 | 25.7.9 [alg.unique] | unique() effects unclear when predicate not an equivalence relation | Yes |  |
239(i) | CD1 | 25.7.9 [alg.unique] | Complexity of unique() and/or unique_copy incorrect | Yes |  |
241(i) | CD1 | 25.7.9 [alg.unique] | Does unique_copy() require CopyConstructible and Assignable? | Yes |  |
538(i) | CD1 | 25.7.9 [alg.unique] | 241 again: Does unique_copy() require CopyConstructible and Assignable? | Yes |  |
1101(i) | NAD Editorial | 25.7.9 [alg.unique] | `unique` requirements | Yes |  |
481(i) | NAD | 25.7.9 [alg.unique] | unique's effects on the range [result, last) | Yes |  |
490(i) | NAD | 25.7.9 [alg.unique] | std::unique wrongly specified | Yes |  |
914(i) | NAD Concepts | 25.7.9 [alg.unique] | Superfluous requirement for unique | Yes |  |
2985(i) | LEWG | 25.7.10 [alg.reverse] | `std::reverse` should be permitted to be vectorized | Yes |  |
2074(i) | C++14 | 25.7.10 [alg.reverse] | Off by one error in `std::reverse_copy` | Yes |  |
223(i) | TC1 | 25.7.10 [alg.reverse] | reverse algorithm should use iter_swap rather than swap | Yes |  |
488(i) | CD1 | 25.7.11 [alg.rotate] | rotate throws away useful information | Yes |  |
2405(i) | NAD | 25.7.11 [alg.rotate] | `rotate()`'s return value is incorrect when `middle == first` | Yes |  |
2716(i) | C++17 | 25.7.12 [alg.random.sample] | Specification of `shuffle` and `sample` disallows lvalue `URNG`s | Yes | 0 |
3191(i) | C++20 | 25.7.13 [alg.random.shuffle] | `std::ranges::shuffle` synopsis does not match algorithm definition | Yes | 1 |
1432(i) | C++11 | 25.7.13 [alg.random.shuffle] | `random_shuffle` signatures are inconsistent | Yes |  | 1433
552(i) | CD1 | 25.7.13 [alg.random.shuffle] | random_shuffle and its generator | Yes |  |
1093(i) | Resolved | 25.7.13 [alg.random.shuffle] | Multiple definitions for `random_shuffle` algorithm | Yes |  |
1433(i) | Dup | 25.7.13 [alg.random.shuffle] | `random_shuffle` and `shuffle` should have consistent signatures | Yes |  | 1432
3031(i) | C++20 | 25.8 [alg.sorting] | Algorithms and predicates with non-const reference arguments | Yes | 2 |
2492(i) | C++17 | 25.8 [alg.sorting] | Clarify requirements for `comp` | Yes | 0 |
556(i) | C++11 | 25.8 [alg.sorting] | Is `Compare` a `BinaryPredicate`? | Yes |  |
218(i) | NAD | 25.8 [alg.sorting] | Algorithms do not use binary predicate objects for default comparisons | Yes |  |
812(i) | NAD Editorial | 25.8.2 [alg.sort] | unsolicited multithreading considered harmful? | Yes |  |
713(i) | CD1 | 25.8.2.1 [sort] | `sort()` complexity is too lax | Yes |  |
499(i) | NAD Editorial | 25.8.2.2 [stable.sort] | Std. doesn't seem to require stable_sort() to be stable! | Yes |  |
2267(i) | New | 25.8.2.4 [partial.sort.copy] | `partial_sort_copy` underspecified for ranges of two different types | No | 3 |
2339(i) | C++14 | 25.8.3 [alg.nth.element] | Wording issue in `nth_element` | Yes | 0 |
2163(i) | C++14 | 25.8.3 [alg.nth.element] | `nth_element` requires inconsistent post-conditions | Yes |  |
270(i) | CD1 | 25.8.4 [alg.binary.search] | Binary search requirements overly strict | Yes |  | 472
191(i) | NAD | 25.8.4 [alg.binary.search] | Unclear complexity for algorithms such as binary search | Yes |  |
577(i) | CD1 | 25.8.4.3 [upper.bound] | upper_bound(first, last, ...) cannot return last | Yes |  |
384(i) | CD1 | 25.8.4.4 [equal.range] | equal_range has unimplementable runtime complexity | Yes |  |
472(i) | Dup | 25.8.4.4 [equal.range] | Missing "Returns" clause in std::equal_range | Yes |  | 270
787(i) | CD1 | 25.8.4.5 [binary.search] | complexity of `binary_search` | Yes |  |
2357(i) | C++14 | 25.8.5 [alg.partitions] | Remaining "`Assignable`" requirement | Yes | 0 |
498(i) | C++11 | 25.8.5 [alg.partitions] | Requirements for partition() and stable_partition() too strong | Yes |  |
2741(i) | Resolved | 25.8.5 [alg.partitions] | `is_partitioned` requirements need updating | Yes | 3 |
2973(i) | LEWG | 25.8.6 [alg.merge] | `inplace_merge` exact comparison count complexity prohibits useful real-world optimizations | Yes |  |
780(i) | C++11 | 25.8.6 [alg.merge] | `std::merge()` specification incorrect/insufficient | Yes |  |
291(i) | CD1 | 25.8.7 [alg.set.operations] | Underspecification of set algorithms | Yes |  |
411(i) | CD1 | 25.8.7 [alg.set.operations] | Wrong names of set member functions | Yes |  |
3115(i) | Resolved | 25.8.7.2 [includes] | Unclear description for algorithm `includes` | Yes | 3 |
862(i) | NAD Editorial | 25.8.7.2 [includes] | Impossible complexity for 'includes' | Yes |  |
1109(i) | NAD Concepts | 25.8.7.2 [includes] | `std::includes` should require `CopyConstructible` predicate | Yes |  |
3534(i) | LEWG | 25.8.7.4 [set.intersection] | `ranges::set_intersection` and `ranges::set_difference` algorithm requirements are too strict | Yes | 3 |
3032(i) | New | 25.8.8 [alg.heap.operations] | `ValueSwappable` requirement missing for `push_heap` and `make_heap` | Yes | 3 |
2166(i) | C++17 | 25.8.8 [alg.heap.operations] | Heap property underspecified? | Yes | 3 |
193(i) | TC1 | 25.8.8 [alg.heap.operations] | Heap operations description incorrect | Yes |  | 216
3029(i) | Open | 25.8.8.3 [pop.heap] | `pop_heap` over-constrains input | Yes | 3 |
2444(i) | C++20 | 25.8.8.5 [sort.heap] | Inconsistent complexity for `std::sort_heap` | Yes | 3 |
2239(i) | C++17 | 25.8.9 [alg.min.max] | `min/max/minmax` requirements | Yes | 3 |
2325(i) | C++17 | 25.8.9 [alg.min.max] | `minmax_element()`'s behavior differing from `max_element()`'s should be noted | Yes | 3 |
2369(i) | C++17 | 25.8.9 [alg.min.max] | `constexpr max(initializer_list)` vs `max_element` | Yes | 3 |
2350(i) | C++14 | 25.8.9 [alg.min.max] | `min`, `max`, and `minmax` should be `constexpr` | Yes | 1 |
281(i) | CD1 | 25.8.9 [alg.min.max] | std::min() and max() requirements overly restrictive | Yes |  | 486
715(i) | CD1 | 25.8.9 [alg.min.max] | `minmax_element` complexity is too lax | Yes |  |
212(i) | TC1 | 25.8.9 [alg.min.max] | Empty range behavior unclear for several algorithms | Yes |  |
915(i) | NAD Editorial | 25.8.9 [alg.min.max] | `minmax` with `initializer_list` should return `pair` of `T`, not `pair` of `const T&` | Yes |  |
1013(i) | NAD Editorial | 25.8.9 [alg.min.max] | Remove `IsSameType` hold-over constraints | Yes |  |
1434(i) | NAD Editorial | 25.8.9 [alg.min.max] | For `min/max` functions replace variadic arguments by `initializer_list` argument | Yes |  |
1308(i) | NAD | 25.8.9 [alg.min.max] | Concerns about `initializer_list` overloads of `min`, `max`, and `minmax` | Yes |  |
190(i) | NAD | 25.8.9 [alg.min.max] | min() and max() functions should be std::binary_functions | Yes |  |
486(i) | Dup | 25.8.9 [alg.min.max] | min/max CopyConstructible requirement is too strict | Yes |  | 281
2688(i) | C++17 | 25.8.10 [alg.clamp] | `clamp` misses preconditions and has extraneous condition on result | Yes | 0 |
142(i) | TC1 | 25.8.11 [alg.lex.comparison] | lexicographical_compare complexity wrong | Yes |  |
3410(i) | WP | 25.8.12 [alg.three.way] | `lexicographical_compare_three_way` is overspecified | Yes | 3 |
3350(i) | C++20 | 25.8.12 [alg.three.way] | Simplify return type of `lexicographical_compare_three_way` | Yes | 0 |
3061(i) | Resolved | 25.8.12 [alg.three.way] | What is the return type of `compare_3way`? | Yes | 2 |
3169(i) | C++20 | 25.8.13 [alg.permutation.generators] | `ranges` permutation generators discard useful information | Yes | 0 |
3487(i) | New | 25.10 [numeric.ops] | Missing precondition on input and output aliasing of [numeric.ops] | No | 3 |
2055(i) | Resolved | 25.10 [numeric.ops] | `std::move` in `std::accumulate` and other algorithms | Yes | 3 |
2924(i) | Resolved | 25.10 [numeric.ops] | An `ExecutionPolicy` overload for `inner_product()` seems impractical | Yes |  |
1067(i) | NAD Concepts | 25.10 [numeric.ops] | simplified wording for inner_product | Yes |  |
2918(i) | Resolved | 25.10.5 [inner.product] | Possible need for extra storage in `inner_product` | Yes |  |
3048(i) | C++20 | 25.10.6 [transform.reduce] | `transform_reduce(exec, first1, last1, first2, init)` discards execution policy | Yes | 0 |
539(i) | C++11 | 25.10.7 [partial.sum] | `partial_sum` and `adjacent_difference` should mention requirements | Yes |  |
3060(i) | New | 25.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 |
2687(i) | C++17 | 25.10.8 [exclusive.scan] | `{inclusive,exclusive}_scan` misspecified | Yes | 1 |
3222(i) | C++20 | 25.10.9 [inclusive.scan] | P0574R1 introduced preconditions on non-existent parameters | Yes | 0 |
3463(i) | New | 25.10.11 [transform.inclusive.scan] | Incorrect requirements for `transform_inclusive_scan` without initial value | Yes | 3 |
3058(i) | C++20 | 25.10.12 [adjacent.difference] | Parallel `adjacent_difference` shouldn't require creating temporaries | Yes | 3 |
2919(i) | Resolved | 25.10.12 [adjacent.difference] | The specification for `adjacent_difference` has baked-in sequential semantics | Yes |  |
871(i) | C++11 | 25.10.13 [numeric.iota] | Iota's requirements on `T` are too strong | Yes |  |
2837(i) | C++17 | 25.10.14 [numeric.ops.gcd] | `gcd` and `lcm` should support a wider range of input values | Yes | 0 |
2759(i) | C++17 | 25.10.14 [numeric.ops.gcd] | `gcd` / `lcm` and `bool` for the WP | Yes |  |
3200(i) | C++20 | 25.10.16 [numeric.ops.midpoint] | `midpoint` should not constrain `T` is complete | Yes | 2 |
3628(i) | New | 25.11 [specialized.algorithms] | "Effects: Equivalent to:" and uninitialized memory algorithms | No | 3 |
3063(i) | New | 25.11 [specialized.algorithms] | Parallel algorithms in `<memory>` are underspecified | No | 3 |
3064(i) | New | 25.11 [specialized.algorithms] | How do uninitialized memory algorithms obtain pointer without undefined behavior? | No | 3 |
2433(i) | C++17 | 25.11 [specialized.algorithms] | `uninitialized_copy()`/etc. should tolerate overloaded `operator&` | Yes | 0 |
866(i) | C++11 | 25.11 [specialized.algorithms] | Qualification of placement new-expressions | Yes |  |
999(i) | C++11 | 25.11 [specialized.algorithms] | Taking the address of a function | Yes |  |
3156(i) | Resolved | 25.11 [specialized.algorithms] | `ForwardIterator` should only mean forward iterator | Yes | 3 |
1029(i) | NAD Concepts | 25.11 [specialized.algorithms] | Specialized algorithms for memory management need to be concept-constrained templates | Yes |  |
3647(i) | New | 25.11.2 [special.mem.concepts] | `nothrow-input-iterator` constraints should not mention copying | Yes | 3 |
3054(i) | C++20 | 25.11.5 [uninitialized.copy] | `uninitialized_copy` appears to not be able to meet its exception-safety guarantee | Yes | 2 |
3355(i) | C++20 | 25.11.5 [uninitialized.copy] | The memory algorithms should support move-only input iterators introduced by P1207 | Yes | 2 |
754(i) | NAD Editorial | 25.11.5 [uninitialized.copy] | Ambiguous return clause for `std::uninitialized_copy` | Yes |  |
582(i) | NAD | 25.11.5 [uninitialized.copy] | specialized algorithms and volatile storage | Yes |  |
1339(i) | C++11 | 25.11.7 [uninitialized.fill] | `uninitialized_fill_n` should return the end of its range | Yes |  |
3436(i) | New | 25.11.8 [specialized.construct] | `std::construct_at` should support arrays | Yes | 2 |
3521(i) | WP | 25.12 [alg.c.library] | Overly strict requirements on `qsort` and `bsearch` | Yes |  |
286(i) | CD1 | 25.12 [alg.c.library] | <cstdlib> requirements missing size_t typedef | Yes |  |
405(i) | CD1 | 25.12 [alg.c.library] | qsort and POD | Yes |  |

## Section 26 (164 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
860(i) | C++11 | 26 [numerics] | Floating-Point State | Yes |  |
1140(i) | NAD Concepts | 26 [numerics] | Numerics library not concept enabled | Yes |  |
3133(i) | C++20 | 26.2 [numeric.requirements] | Modernizing numeric type requirements | Yes | 0 |
2699(i) | C++17 | 26.2 [numeric.requirements] | Missing restriction in [numeric.requirements] | Yes | 3 |
387(i) | CD1 | 26.4 [complex.numbers] | `std::complex` over-encapsulated | Yes |  |
2693(i) | Resolved | 26.4 [complex.numbers] | `constexpr` for various `std::complex` arithmetic and value operators | Yes | 3 |
1154(i) | NAD | 26.4 [complex.numbers] | `complex` should accept integral types | Yes |  |
1217(i) | NAD | 26.4 [complex.numbers] | Quaternion support | Yes |  |
388(i) | NAD | 26.4 [complex.numbers] | Use of `complex` as a key in associative containers | Yes |  |
79(i) | TC1 | 26.4.2 [complex.syn] | Inconsistent declaration of polar() | Yes |  |
80(i) | TC1 | 26.4.2 [complex.syn] | Global Operators of complex declared twice | Yes |  |
2714(i) | New | 26.4.7 [complex.ops] | `complex` stream extraction underspecified | Yes | 3 |
629(i) | CD1 | 26.4.7 [complex.ops] | `complex<T>` insertion and locale dependence | Yes |  |
146(i) | TC1 | 26.4.7 [complex.ops] | complex<T> Inserter and Extractor need sentries | Yes |  |
177(i) | NAD | 26.4.7 [complex.ops] | Complex operators cannot be explicitly instantiated | Yes |  |
2870(i) | C++20 | 26.4.8 [complex.value.ops] | Default value of parameter `theta` of `polar` should be dependent | Yes |  |
2459(i) | C++17 | 26.4.8 [complex.value.ops] | `std::polar` should require a non-negative rho | Yes | 0 |
1435(i) | C++11 | 26.4.8 [complex.value.ops] | Unclear returns specifications for C99 complex number functions | Yes |  |
595(i) | CD1 | 26.4.8 [complex.value.ops] | TR1/C++0x: `fabs(complex<T>)` redundant / wrongly specified | Yes |  |
781(i) | CD1 | 26.4.8 [complex.value.ops] | `std::complex` should add missing C99 functions | Yes |  |
2597(i) | C++20 | 26.4.9 [complex.transcendentals] | `std::log` misspecified for complex numbers | Yes | 3 |
440(i) | NAD | 26.4.9 [complex.transcendentals] | Should std::complex use unqualified transcendentals? | Yes |  |
2846(i) | New | 26.4.10 [cmplx.over] | Undefined phrase "effectively cast" | Yes | 3 |
1137(i) | C++11 | 26.4.10 [cmplx.over] | Return type of `conj` and `proj` | Yes |  |
1522(i) | C++11 | 26.4.10 [cmplx.over] | `conj` specification is now nonsense | Yes |  |
844(i) | CD1 | 26.4.10 [cmplx.over] | `complex pow` return type is ambiguous | Yes |  |
3656(i) | Open | 26.5.5 [bit.pow.two] | Inconsistent bit operations returning a count | Yes | 3 |
507(i) | CD1 | 26.6 [rand] | Missing requirement for variate_generator::operator() | Yes |  |
699(i) | CD1 | 26.6 [rand] | N2111 changes min/max | Yes |  |
506(i) | NAD | 26.6 [rand] | Requirements of Distribution parameter for variate_generator | Yes |  |
547(i) | NAD | 26.6 [rand] | division should be floating-point, not integer | Yes |  |
572(i) | NAD | 26.6 [rand] | Oops, we gave 507 WP status | Yes |  |
1056(i) | NAD | 26.6 [rand] | Must all Engines and Distributions be Streamable? | Yes |  |
1057(i) | NAD Concepts | 26.6 [rand] | `RandomNumberEngineAdaptor` | Yes |  |
656(i) | NAD Editorial | 26.6.2 [rand.synopsis] | Typo in subtract_with_carry_engine declaration | Yes |  |
515(i) | NAD | 26.6.2 [rand.synopsis] | Random number engine traits | Yes |  |
505(i) | CD1 | 26.6.3 [rand.req] | Result_type in random distribution requirements | Yes |  |
504(i) | NAD Editorial | 26.6.3 [rand.req] | Integer types in pseudo-random number engine requirements | Yes |  |
517(i) | NAD | 26.6.3 [rand.req] | Should include name in external representation | Yes |  |
2326(i) | NAD | 26.6.3.1 [rand.req.genl] | `uniform_int_distribution<unsigned char>` should be permitted | Yes | 2 |
2181(i) | C++17 | 26.6.3.2 [rand.req.seedseq] | Exceptions from seed sequence operations | Yes | 3 |
2124(i) | NAD | 26.6.3.2 [rand.req.seedseq] | Seed sequence over-specified | Yes |  |
3150(i) | C++20 | 26.6.3.3 [rand.req.urng] | `UniformRandomBitGenerator` should validate `min` and `max` | Yes | 3 |
2154(i) | Resolved | 26.6.3.3 [rand.req.urng] | What exactly does compile-time complexity imply? | Yes | 4 |
2327(i) | NAD | 26.6.3.3 [rand.req.urng] | Non-power-of-two URNGs should be forbidden | Yes |  |
654(i) | CD1 | 26.6.3.4 [rand.req.eng] | Missing IO roundtrip for random number engines | Yes |  |
678(i) | CD1 | 26.6.3.4 [rand.req.eng] | Changes for [rand.req.eng] | Yes |  |
729(i) | NAD | 26.6.3.4 [rand.req.eng] | Problem in [rand.req.eng]/3 | Yes |  |
730(i) | NAD | 26.6.3.5 [rand.req.adapt] | Comment on [rand.req.adapt]/3 e) | Yes |  |
1235(i) | NAD | 26.6.3.6 [rand.req.dist] | Issue with C++0x random number proposal | Yes |  |
733(i) | NAD | 26.6.3.6 [rand.req.dist] | Comment on [rand.req.dist]/9 | Yes |  |
3519(i) | WP | 26.6.4 [rand.eng] | Incomplete synopses for `<random>` classes | Yes | 3 |
1436(i) | C++11 | 26.6.4 [rand.eng] | Random number engine constructor concerns | Yes |  |
512(i) | NAD Editorial | 26.6.4 [rand.eng] | Seeding `subtract_with_carry_01` from a single unsigned long | Yes |  |
513(i) | NAD Editorial | 26.6.4 [rand.eng] | Size of state for subtract_with_carry_01 | Yes |  |
516(i) | NAD Editorial | 26.6.4 [rand.eng] | Seeding subtract_with_carry_01 using a generator | Yes |  |
2351(i) | NAD | 26.6.4 [rand.eng] | Does `.seed()` completely reset state of engine? | Yes | 2 |
1437(i) | C++11 | 26.6.4.3 [rand.eng.mers] | Mersenne twister meaningless for word sizes less than two | Yes |  |
728(i) | CD1 | 26.6.4.3 [rand.eng.mers] | Problem in [rand.eng.mers]/6 | Yes |  |
514(i) | NAD Editorial | 26.6.4.4 [rand.eng.sub] | Size of state for subtract_with_carry | Yes |  |
3561(i) | WP | 26.6.5.2 [rand.adapt.disc] | Issue with internal counter in `discard_block_engine` | Yes |  |
1438(i) | C++11 | 26.6.5.2 [rand.adapt.disc] | No definition for `base()` | Yes |  |
738(i) | NAD Editorial | 26.6.5.2 [rand.adapt.disc] | Editorial issue in [rand.adapt.disc]/3 | Yes |  |
609(i) | CD1 | 26.6.5.3 [rand.adapt.ibits] | missing static const | Yes |  |
508(i) | CD1 | 26.6.6 [rand.predef] | Bad parameters for ranlux64_base_01 | Yes |  |
796(i) | NAD | 26.6.6 [rand.predef] | `ranlux48_base` returns wrong value | Yes |  |
797(i) | NAD | 26.6.6 [rand.predef] | `ranlux48` returns wrong value | Yes |  |
802(i) | NAD | 26.6.6 [rand.predef] | `knuth_b` returns wrong value | Yes |  |
548(i) | NAD | 26.6.7 [rand.device] | May random_device block? | Yes |  |
1068(i) | NAD | 26.6.7 [rand.device] | class `random_device` should be movable | Yes |  |
2352(i) | New | 26.6.8.1 [rand.util.seedseq] | Is a default-constructed `std::seed_seq` intended to produce a predictable `.generate()`? | No | 2 |
3422(i) | WP | 26.6.8.1 [rand.util.seedseq] | Issues of `seed_seq`'s constructors | Yes | 3 |
2440(i) | C++17 | 26.6.8.1 [rand.util.seedseq] | `seed_seq::size()` should be `noexcept` | Yes | 0 |
2180(i) | C++14 | 26.6.8.1 [rand.util.seedseq] | Exceptions from `std::seed_seq` operations | Yes |  |
607(i) | CD1 | 26.6.8.1 [rand.util.seedseq] | Concern about short seed vectors | Yes |  |
608(i) | CD1 | 26.6.8.1 [rand.util.seedseq] | Unclear seed_seq construction details | Yes |  |
677(i) | CD1 | 26.6.8.1 [rand.util.seedseq] | Weaknesses in seed_seq::randomize [rand.util.seedseq] | Yes |  |
712(i) | CD1 | 26.6.8.1 [rand.util.seedseq] | `seed_seq::size` no longer useful | Yes |  |
782(i) | CD1 | 26.6.8.1 [rand.util.seedseq] | Extended `seed_seq` constructor is useless | Yes |  |
800(i) | Resolved | 26.6.8.1 [rand.util.seedseq] | Issues in 26.4.7.1 [rand.util.seedseq](6) | Yes |  |
803(i) | Resolved | 26.6.8.1 [rand.util.seedseq] | Simplification of `seed_seq::seq_seq` | Yes |  |
731(i) | NAD | 26.6.8.1 [rand.util.seedseq] | proposal for a customizable `seed_seq` | Yes |  |
1069(i) | NAD | 26.6.8.1 [rand.util.seedseq] | class `seed_seq` should support efficient move operations | Yes |  |
1313(i) | NAD | 26.6.8.1 [rand.util.seedseq] | Seed sequence's param function not useful for pure output iterator | Yes |  |
655(i) | CD1 | 26.6.8.2 [rand.util.canonical] | Signature of generate_canonical not useful | Yes |  |
739(i) | NAD | 26.6.8.2 [rand.util.canonical] | Defect in [rand.util.canonical]/3 | Yes |  |
549(i) | NAD Editorial | 26.6.9 [rand.dist] | Undefined variable in binomial_distribution | Yes |  |
511(i) | NAD | 26.6.9 [rand.dist] | Input_type for binomial_distribution | Yes |  |
509(i) | NAD | 26.6.9.2 [rand.dist.uni] | Uniform_int template parameters | Yes |  |
773(i) | NAD | 26.6.9.2 [rand.dist.uni] | issues with random | Yes |  |
2168(i) | C++17 | 26.6.9.2.2 [rand.dist.uni.real] | Inconsistent specification of `uniform_real_distribution` constructor | Yes | 3 |
510(i) | NAD | 26.6.9.3 [rand.dist.bern] | Input_type for bernoulli_distribution | Yes |  |
735(i) | NAD | 26.6.9.3.2 [rand.dist.bern.bin] | Unfortunate naming | Yes |  |
3402(i) | New | 26.6.9.3.4 [rand.dist.bern.negbin] | Wording for `negative_binomial_distribution` is unclear as a consequence of LWG 2406 resolution | No | 3 |
2406(i) | C++17 | 26.6.9.3.4 [rand.dist.bern.negbin] | `negative_binomial_distribution` should reject `p == 1` | Yes | 3 |
2524(i) | Open | 26.6.9.4.2 [rand.dist.pois.exp] | `generate_canonical` can occasionally return 1.0 | No | 2 |
734(i) | CD1 | 26.6.9.5.3 [rand.dist.norm.chisq] | Unnecessary restriction in [rand.dist.norm.chisq] | Yes |  |
793(i) | Resolved | 26.6.9.6.1 [rand.dist.samp.discrete] | `discrete_distribution` missing constructor | Yes |  |
874(i) | Resolved | 26.6.9.6.1 [rand.dist.samp.discrete] | Missing `initializer_list` constructor for `discrete_distribution` | Yes |  |
736(i) | NAD | 26.6.9.6.1 [rand.dist.samp.discrete] | Comment on [rand.dist.samp.discrete] | Yes |  |
1439(i) | C++11 | 26.6.9.6.2 [rand.dist.samp.pconst] | Return from `densities()` functions? | Yes |  |
792(i) | CD1 | 26.6.9.6.2 [rand.dist.samp.pconst] | `piecewise_constant_distribution` is undefined for a range with just one endpoint | Yes |  |
794(i) | Resolved | 26.6.9.6.2 [rand.dist.samp.pconst] | `piecewise_constant_distribution` missing constructor | Yes |  |
875(i) | Resolved | 26.6.9.6.2 [rand.dist.samp.pconst] | Missing `initializer_list` constructor for `piecewise_constant_distribution` | Yes |  |
737(i) | NAD | 26.6.9.6.2 [rand.dist.samp.pconst] | Comment on [rand.dist.samp.pconst] | Yes |  |
791(i) | NAD | 26.6.9.6.2 [rand.dist.samp.pconst] | `piecewise_constant_distribution::densities` has wrong name | Yes |  |
1440(i) | C++11 | 26.6.9.6.3 [rand.dist.samp.plinear] | Incorrect specification for `piecewise_linear_distribution` | Yes |  |
2058(i) | C++14 | 26.7 [numarray] | `valarray` and `begin/end` | Yes |  |
621(i) | CD1 | 26.7 [numarray] | non-const copy assignment operators of helper arrays | Yes |  |
93(i) | NAD | 26.7 [numarray] | Incomplete Valarray Subset Definitions | Yes |  |
125(i) | TC1 | 26.7.2 [template.valarray] | valarray<T>::operator!() return type is inconsistent | Yes |  |
107(i) | NAD | 26.7.2 [template.valarray] | Valarray constructor is strange | Yes |  |
630(i) | C++11 | 26.7.2.2 [valarray.cons] | arrays of `valarray` | Yes |  |
1208(i) | C++11 | 26.7.2.2 [valarray.cons] | `valarray initializer_list` constructor has incorrect effects | Yes |  |
253(i) | CD1 | 26.7.2.2 [valarray.cons] | valarray helper functions are almost entirely useless | Yes |  |
620(i) | CD1 | 26.7.2.2 [valarray.cons] | valid uses of empty valarrays | Yes |  |
867(i) | NAD Editorial | 26.7.2.2 [valarray.cons] | Valarray and value-initialization | Yes |  |
2071(i) | C++14 | 26.7.2.3 [valarray.assign] | `std::valarray` move-assignment | Yes |  |
624(i) | CD1 | 26.7.2.3 [valarray.assign] | `valarray` assignment and arrays of unequal length | Yes |  |
389(i) | CD1 | 26.7.2.4 [valarray.access] | Const overload of valarray::operator[] returns by value | Yes |  | 77
636(i) | NAD Editorial | 26.7.2.4 [valarray.access] | 26.5.2.3 valarray::operator[] | Yes |  |
717(i) | NAD Editorial | 26.7.2.4 [valarray.access] | Incomplete `valarray::operator[]` specification in [valarray.access] | Yes |  |
77(i) | Dup | 26.7.2.4 [valarray.access] | Valarray operator[] const returning value | Yes |  | 389
430(i) | C++11 | 26.7.2.5 [valarray.sub] | `valarray` subset operations | Yes |  |
188(i) | NAD | 26.7.2.7 [valarray.cassign] | valarray helpers missing augmented assignment operators | Yes |  |
1243(i) | NAD | 26.7.2.7 [valarray.cassign] | Missing `operator+= (initializer_list<T>)` for `valarray` | Yes |  |
618(i) | CD1 | 26.7.2.8 [valarray.members] | valarray::cshift() effects on empty array | Yes |  |
3074(i) | C++20 | 26.7.3 [valarray.nonmembers] | Non-member functions for `valarray` should only deduce from the `valarray` | Yes | 0 |
543(i) | CD1 | 26.7.4 [class.slice] | valarray slice default constructor | Yes |  |
2423(i) | New | 26.7.5 [template.slice.array] | Missing specification `slice_array`, `gslice_array`, `mask_array`, `indirect_array` copy constructor | Yes | 4 |
106(i) | TC1 | 26.7.5 [template.slice.array] | Numeric library private members are implementation defined | Yes |  |
81(i) | NAD | 26.7.5 [template.slice.array] | Wrong declaration of slice operations | Yes |  |
123(i) | CD1 | 26.7.5.4 [slice.arr.fill] | Should valarray helper arrays fill functions be const? | Yes |  |
2115(i) | Open | 26.7.8 [template.mask.array] | Undefined behaviour for `valarray` assignments with `mask_array` index? | No | 4 |
2192(i) | C++17 | 26.8 [c.math] | Validity and return type of `std::abs(0u)` is unclear | Yes | 2 |
2735(i) | C++17 | 26.8 [c.math] | `std::abs(short)`, `std::abs(signed char)` and others should return `int` instead of `double` in order to be compatible with C++98 and C | Yes | 3 |
2086(i) | C++14 | 26.8 [c.math] | Overly generic type support for math functions | Yes |  |
1134(i) | C++11 | 26.8 [c.math] | Redundant specification of `<stdint.h>`, `<fenv.h>`, `<tgmath.h>`, and maybe `<complex.h>` | Yes |  |
1441(i) | C++11 | 26.8 [c.math] | Floating-point test functions are incorrectly specified | Yes |  |
295(i) | CD1 | 26.8 [c.math] | Is abs defined in <cmath>? | Yes |  |
395(i) | CD1 | 26.8 [c.math] | inconsistencies in the definitions of rand() and random_shuffle() | Yes |  |
550(i) | CD1 | 26.8 [c.math] | What should the return type of `pow(float,int)` be? | Yes |  |
722(i) | CD1 | 26.8 [c.math] | Missing [c.math] functions `nanf` and `nanl` | Yes |  |
2294(i) | Resolved | 26.8 [c.math] | `<cstdlib>` should declare `abs(double)` | Yes | 2 |
1327(i) | Resolved | 26.8 [c.math] | templates defined in `<cmath>` replacing C macros with the same name | Yes |  |
637(i) | NAD Editorial | 26.8 [c.math] | §[c.math]/10 inconsistent return values | Yes |  |
357(i) | NAD Editorial | 26.8 [c.math] | <cmath> float functions cannot return HUGE_VAL | Yes |  |
690(i) | NAD Editorial | 26.8 [c.math] | abs(long long) should return long long | Yes |  |
213(i) | NAD | 26.8 [c.math] | Math function overloads ambiguous | Yes |  |
289(i) | NAD | 26.8 [c.math] | <cmath> requirements missing C float and long double versions | Yes |  |
323(i) | NAD | 26.8 [c.math] | `abs()` overloads in different headers | Yes |  |
583(i) | NAD | 26.8 [c.math] | `div()` for unsigned integral types | Yes |  |
584(i) | NAD | 26.8 [c.math] | missing int `pow(int,int)` functionality | Yes |  |
2079(i) | NAD | 26.8 [c.math] | Required `pow()` overloads | Yes | 3 |
2474(i) | NAD | 26.8 [c.math] | `<cmath>` functions unfriendly to `integral_constant` arguments | Yes | 4 |
2847(i) | New | 26.8.1 [cmath.syn] | `sin(float)` should call `sinf(float)` | No | 3 |
3234(i) | New | 26.8.1 [cmath.syn] | Sufficient Additional Special Math Overloads | No | 3 |
3223(i) | New | 26.8.1 [cmath.syn] | `lerp` should not add the "sufficient additional overloads" | No | 2 |
2923(i) | New | 26.8.1 [cmath.syn] | `noexcept` is inconsistently applied across headers which import components of the C standard library | No | 4 |
3051(i) | C++20 | 26.8.1 [cmath.syn] | Floating point classifications were inadvertently changed in P0175 | Yes | 0 |
3093(i) | New | 26.8.2 [c.math.abs] | LWG 2294/2192 missed a `std::abs` overload | No | 3 |
3172(i) | New | 26.8.3 [c.math.hypot3] | 3-arg `std::hypot` is underspecified compared to the 2-arg overload | Yes | 3 |
3201(i) | C++20 | 26.8.4 [c.math.lerp] | `lerp` should be marked as `noexcept` | Yes | 2 |
3066(i) | New | 26.8.6 [sf.cmath] | "report a domain error" in [sf.cmath]/1 is underspecified | No | 3 |

## Section 27 (75 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
786(i) | Resolved | 27 [time] | Thread library timed waits, UTC and monotonic clocks | Yes |  |
1032(i) | NAD Concepts | 27 [time] | Tome utility templates need to be concept-constrained | Yes |  |
2592(i) | New | 27.2 [time.syn] | Require that `chrono::duration_cast`s from smaller durations to larger durations do not overflow | Yes | 4 |
2278(i) | C++14 | 27.2 [time.syn] | User-defined literals for Standard Library types | Yes |  |
954(i) | C++11 | 27.3 [time.clock.req] | Various threading bugs #4 | Yes |  |
956(i) | C++11 | 27.3 [time.clock.req] | Various threading bugs #6 | Yes |  |
953(i) | Resolved | 27.3 [time.clock.req] | Various threading bugs #3 | Yes |  |
955(i) | NAD | 27.3 [time.clock.req] | Various threading bugs #5 | Yes |  |
951(i) | C++11 | 27.4.1 [time.traits.is.fp] | Various threading bugs #1 | Yes |  |
3123(i) | WP | 27.5 [time.duration] | `duration` constructor from representation shouldn't be effectively non-throwing | Yes | 3 |
934(i) | C++11 | 27.5 [time.duration] | `duration` is missing `operator%` | Yes |  |
1171(i) | C++11 | 27.5 [time.duration] | duration types should be literal | Yes |  |
1177(i) | C++11 | 27.5 [time.duration] | Improve "diagnostic required" wording | Yes |  |
2912(i) | Resolved | 27.5 [time.duration] | Add a deduction guide for class template `duration` | Yes |  |
3090(i) | New | 27.5.2 [time.duration.cons] | What is §[time.duration.cons]p4's "no overflow is induced in the conversion" intended to mean? | Yes | 3 |
3050(i) | C++20 | 27.5.2 [time.duration.cons] | Conversion specification problem in `chrono::duration` constructor | Yes | 3 |
2094(i) | C++14 | 27.5.2 [time.duration.cons] | `duration` conversion overflow shouldn't participate in overload resolution | Yes |  |
974(i) | C++11 | 27.5.2 [time.duration.cons] | `duration<double>` should not implicitly convert to `duration<int>` | Yes |  |
3104(i) | C++20 | 27.5.6 [time.duration.nonmember] | Fixing `duration` division | Yes | 0 |
1271(i) | C++11 | 27.5.6 [time.duration.nonmember] | `CR` undefined in duration operators | Yes |  |
2004(i) | C++11 | 27.5.6 [time.duration.nonmember] | `duration::operator*` has template parameters in funny order | Yes |  |
2020(i) | C++11 | 27.5.6 [time.duration.nonmember] | Time utility arithmetic `constexpr` functions have invalid effects | Yes |  |
882(i) | CD1 | 27.5.6 [time.duration.nonmember] | `duration` non-member arithmetic requirements | Yes |  |
947(i) | Resolved | 27.5.6 [time.duration.nonmember] | `duration` arithmetic: contradictory requirements | Yes |  |
3503(i) | New | 27.5.8 [time.duration.cast] | `chrono::ceil` has surprising requirement | No | 3 |
952(i) | NAD Editorial | 27.5.8 [time.duration.cast] | Various threading bugs #2 | Yes |  |
946(i) | NAD | 27.5.8 [time.duration.cast] | `duration_cast` improperly specified | Yes |  |
2383(i) | Open | 27.5.9 [time.duration.literals] | Overflow cannot be ill-formed for chrono::duration integer literals | No | 3 |
3536(i) | WP | 27.5.11 [time.duration.io] | Should `chrono::from_stream()` assign zero to `duration` for failure? | Yes |  |
3094(i) | C++20 | 27.5.11 [time.duration.io] | §[time.duration.io]p4 makes surprising claims about encoding | Yes | 0 |
3314(i) | C++20 | 27.5.11 [time.duration.io] | Is stream insertion behavior locale dependent when `Period::type` is `micro`? | Yes | 2 |
3317(i) | C++20 | 27.5.11 [time.duration.io] | Incorrect `operator<<` for floating-point durations | Yes | 0 |
3125(i) | Resolved | 27.5.11 [time.duration.io] | `duration` streaming precondition should be a SFINAE condition | Yes | 2 |
2054(i) | Resolved | 27.6 [time.point] | `time_point` constructors need to be `constexpr` | Yes |  |
2739(i) | C++17 | 27.6.6 [time.point.nonmember] | Issue with `time_point` non-member subtraction with an unsigned duration | Yes | 0 |
2057(i) | Resolved | 27.6.6 [time.point.nonmember] | `time_point + duration` semantics should be made `constexpr` conforming | Yes |  |
935(i) | NAD | 27.7 [time.clock] | clock error handling needs to be specified | Yes |  |
957(i) | C++11 | 27.7.2 [time.clock.system] | Various threading bugs #7 | Yes |  |
945(i) | NAD Editorial | 27.7.2 [time.clock.system] | `system_clock::rep` not specified | Yes |  |
3318(i) | C++20 | 27.7.2.1 [time.clock.system.overview] | Clarify whether clocks can represent time before their epoch | Yes | 0 |
3316(i) | C++20 | 27.7.3.1 [time.clock.utc.overview] | Correctly define epoch for `utc_clock` / `utc_timepoint` | Yes | 0 |
3145(i) | C++20 | 27.7.6 [time.clock.file] | `file_clock` breaks ABI for C++17 implementations | Yes | 1 |
1413(i) | NAD | 27.7.8 [time.clock.hires] | Specify whether `high_resolution_clock` is a distinct type or a typedef | Yes |  |
3260(i) | C++20 | 27.8 [time.cal] | `year_month*` arithmetic rejects durations convertible to years | Yes | 2 |
3209(i) | C++20 | 27.8.5.2 [time.cal.year.members] | Expression in `year::ok()` returns clause is ill-formed | Yes | 0 |
3273(i) | C++20 | 27.8.7.2 [time.cal.wdidx.members] | Specify `weekday_indexed` to range of `[0, 7]` | Yes | 0 |
3221(i) | C++20 | 27.8.13.3 [time.cal.ym.nonmembers] | Result of `year_month` arithmetic with `months` is ambiguous | Yes | 0 |
3206(i) | C++20 | 27.8.14.2 [time.cal.ymd.members] | `year_month_day` conversion to `sys_days` uses not-existing member function | Yes | 0 |
3231(i) | C++20 | 27.8.15.2 [time.cal.ymdlast.members] | `year_month_day_last::day` specification does not cover `!ok()` values | Yes | 0 |
3091(i) | Resolved | 27.9 [time.hms] | subsecond-precision `time_of_day` and durations that `seconds` cannot convert to | Yes | 2 |
3319(i) | C++20 | 27.11.1 [time.zone.general] | Properly reference specification of IANA time zone database | Yes | 0 |
3678(i) | New | 27.11.5.1 [time.zone.overview] | Constructors of `std::chrono::time_zone` might be overly unspecified | No | 4 |
3232(i) | C++20 | 27.11.7.1 [time.zone.zonedtime.overview] | Inconsistency in `zoned_time` deduction guides | Yes | 0 |
3294(i) | C++20 | 27.11.7.1 [time.zone.zonedtime.overview] | `zoned_time` deduction guides misinterprets `string`/`char*` | Yes | 0 |
3224(i) | C++20 | 27.11.7.2 [time.zone.zonedtime.ctor] | `zoned_time` constructor from `TimeZonePtr` does not specify initialization of `tp_` | Yes | 0 |
3225(i) | C++20 | 27.11.7.2 [time.zone.zonedtime.ctor] | `zoned_time` converting constructor shall not be `noexcept` | Yes | 0 |
3226(i) | C++20 | 27.11.7.2 [time.zone.zonedtime.ctor] | `zoned_time` constructor from `string_view` should accept `zoned_time<Duration2, TimeZonePtr2>` | Yes | 2 |
3359(i) | C++20 | 27.11.8 [time.zone.leap] | `<chrono>` leap second support should allow for negative leap seconds | Yes | 3 |
3383(i) | C++20 | 27.11.8.3 [time.zone.leap.nonmembers] | §[time.zone.leap.nonmembers] `sys_seconds` should be replaced with `seconds` | Yes | 1 |
3565(i) | SG16 | 27.12 [time.format] | Handling of encodings in localized formatting of `chrono` types is underspecified | Yes | 2 |
3241(i) | C++20 | 27.12 [time.format] | `chrono-spec` grammar ambiguity in §[time.format] | Yes | 0 |
3262(i) | C++20 | 27.12 [time.format] | Formatting of negative durations is not specified | Yes | 2 |
3270(i) | C++20 | 27.12 [time.format] | Parsing and formatting `%j` with `duration`s | Yes | 2 |
3272(i) | C++20 | 27.12 [time.format] | `%I%p` should parse/format `duration` since midnight | Yes | 0 |
3332(i) | C++20 | 27.12 [time.format] | Issue in §[time.format] | Yes | 0 |
3547(i) | Resolved | 27.12 [time.format] | Time formatters should not be locale sensitive by default | Yes | 2 |
3554(i) | WP | 27.13 [time.parse] | `chrono::parse` needs `const charT*` and `basic_string_view<charT>` overloads | Yes | 2 |
3131(i) | C++20 | 27.13 [time.parse] | `addressof` all the things | Yes | 0 |
3218(i) | C++20 | 27.13 [time.parse] | Modifier for `%d` parse flag does not match POSIX and `format` specification | Yes | 0 |
3230(i) | C++20 | 27.13 [time.parse] | Format specifier `%y/%Y` is missing locale alternative versions | Yes | 0 |
3235(i) | C++20 | 27.13 [time.parse] | `parse` manipulator without abbreviation is not callable | Yes | 0 |
3245(i) | C++20 | 27.13 [time.parse] | Unnecessary restriction on `'%p'` parse specifier | Yes | 0 |
3252(i) | C++20 | 27.13 [time.parse] | Parse locale's aware modifiers for commands are not consistent with POSIX spec | Yes | 2 |
3269(i) | C++20 | 27.13 [time.parse] | Parse manipulators do not specify the result of the extraction from stream | Yes | 2 |
3271(i) | NAD | 27.13 [time.parse] | Parsing functions should save and restore stream format state | Yes | 3 |

## Section 28 (125 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
317(i) | CD1 | 28 [localization] | Instantiation vs. specialization of facets | Yes |  |
495(i) | CD1 | 28 [localization] | Clause 22 template parameter requirements | Yes |  |
708(i) | NAD | 28 [localization] | Locales need to be per thread and updated for POSIX changes | Yes |  |
1082(i) | NAD Concepts | 28 [localization] | `codecvt` needs to be a concept-constrained template | Yes |  |
1083(i) | NAD Concepts | 28 [localization] | `InputIterator` and `OutputIterator` template parameters need to be concept constraints | Yes |  |
1298(i) | C++11 | 28.2 [locale.syn] | Missing specialization of `ctype_byname<char>` | Yes |  |
3353(i) | New | 28.3.1 [locale] | `locale`'s copy assignment operator should return `locale&` | Yes | 3 |
268(i) | CD1 | 28.3.1 [locale] | Typo in locale synopsis | Yes |  |
360(i) | CD1 | 28.3.1 [locale] | locale mandates inefficient implementation | Yes |  |
31(i) | TC1 | 28.3.1 [locale] | Immutable locale values | Yes |  | 378
37(i) | TC1 | 28.3.1 [locale] | Leftover "global" reference | Yes |  |
137(i) | TC1 | 28.3.1 [locale] | Do use_facet and has_facet look in the global locale? | Yes |  |
330(i) | NAD | 28.3.1 [locale] | Misleading "exposition only" value in class locale definition | Yes |  |
378(i) | Dup | 28.3.1 [locale] | locale immutability and locale::operator=() | Yes |  | 31
327(i) | CD1 | 28.3.1.2.1 [locale.category] | Typo in time_get facet in table 52 | Yes |  | 447
340(i) | CD1 | 28.3.1.2.1 [locale.category] | interpretation of `has_facet<Facet>(loc)` | Yes |  |
347(i) | CD1 | 28.3.1.2.1 [locale.category] | locale::category and bitmask requirements | Yes |  |
21(i) | TC1 | 28.3.1.2.1 [locale.category] | Codecvt_byname<> instantiations | Yes |  |
30(i) | TC1 | 28.3.1.2.1 [locale.category] | Wrong header for LC_* | Yes |  |
121(i) | NAD | 28.3.1.2.1 [locale.category] | Detailed definition for ctype<wchar_t> specialization | Yes |  |
502(i) | NAD | 28.3.1.2.1 [locale.category] | Proposition: Clarification of the interaction between a facet and an iterator | Yes |  |
447(i) | Dup | 28.3.1.2.1 [locale.category] | Wrong template argument for time facets | Yes |  | 327
2694(i) | C++17 | 28.3.1.2.2 [locale.facet] | Application of LWG 436 accidentally deleted definition of "facet" | Yes | 3 |
436(i) | CD1 | 28.3.1.2.2 [locale.facet] | are cv-qualified facet types valid facets? | Yes |  |
3673(i) | New | 28.3.1.3 [locale.cons] | §[locale.cons] Ambiguous argument in Throws for locale+name+category constructor | No | 3 |
3676(i) | New | 28.3.1.3 [locale.cons] | Name of locale composed using `std::locale::none` | No | 3 |
2295(i) | New | 28.3.1.3 [locale.cons] | Locale name when the provided `Facet` is a `nullptr` | No | 3 |
3674(i) | New | 28.3.1.4 [locale.members] | Removal of requirement for locale names for construction of locales not explained | Yes | 2 |
2394(i) | C++17 | 28.3.1.4 [locale.members] | `locale::name` specification unclear — what is implementation-defined? | Yes | 3 |
14(i) | TC1 | 28.3.1.4 [locale.members] | Locale::combine should be const | Yes |  |
15(i) | TC1 | 28.3.1.4 [locale.members] | Locale::name requirement inconsistent | Yes |  |
452(i) | NAD | 28.3.1.4 [locale.members] | locale::combine should be permitted to generate a named locale | Yes |  |
8(i) | TC1 | 28.3.1.6 [locale.statics] | Locale::global lacks guarantee | Yes |  |
38(i) | TC1 | 28.3.2 [locale.global.templates] | Facet definition incomplete | Yes |  |
2019(i) | C++11 | 28.3.3.1 [classification] | `isblank` not supported by `std::locale` | Yes |  |
391(i) | CD1 | 28.3.3.2 [conversions.character] | non-member functions specified as const | Yes |  |
228(i) | CD1 | 28.4 [locale.categories] | Incorrect specification of "..._byname" facets | Yes |  |
338(i) | CD1 | 28.4 [locale.categories] | is whitespace allowed between `-' and a digit? | Yes |  |
439(i) | NAD | 28.4 [locale.categories] | Should facets be copyable? | Yes |  |
503(i) | NAD | 28.4 [locale.categories] | more on locales | Yes |  |
585(i) | NAD | 28.4 [locale.categories] | facet error reporting | Yes |  |
339(i) | CD1 | 28.4.2 [category.ctype] | definition of bitmask type restricted to clause 27 | Yes |  |
356(i) | NAD | 28.4.2 [category.ctype] | Meaning of ctype_base::mask enumerators | Yes |  |
473(i) | C++11 | 28.4.2.2 [locale.ctype] | underspecified `ctype` calls | Yes |  |
379(i) | CD1 | 28.4.2.2.3 [locale.ctype.virtuals] | nonsensical ctype::do_widen() requirement | Yes |  |
126(i) | TC1 | 28.4.2.2.3 [locale.ctype.virtuals] | typos in Effects clause of ctype::do_narrow() | Yes |  |
152(i) | TC1 | 28.4.2.2.3 [locale.ctype.virtuals] | Typo in `scan_is()` semantics | Yes |  |
417(i) | NAD | 28.4.2.2.3 [locale.ctype.virtuals] | what does `ctype::do_widen()` return on failure | Yes |  |
616(i) | CD1 | 28.4.2.3 [locale.ctype.byname] | missing 'typename' in ctype_byname | Yes |  |
124(i) | TC1 | 28.4.2.3 [locale.ctype.byname] | ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT* | Yes |  |
695(i) | CD1 | 28.4.2.4 [facet.ctype.special] | ctype<char>::classic_table() not accessible | Yes |  |
153(i) | CD1 | 28.4.2.4.3 [facet.ctype.char.members] | Typo in `narrow()` semantics | Yes |  | 207
28(i) | TC1 | 28.4.2.4.3 [facet.ctype.char.members] | Ctype<char>is ambiguous | Yes |  | 236
207(i) | Dup | 28.4.2.4.3 [facet.ctype.char.members] | ctype<char> members return clause incomplete | Yes |  | 153
236(i) | Dup | 28.4.2.4.3 [facet.ctype.char.members] | ctype<char>::is() member modifies facet | Yes |  | 28
76(i) | CD1 | 28.4.2.5 [locale.codecvt] | Can a `codecvt` facet always convert one internal character at a time? | Yes |  |
16(i) | TC1 | 28.4.2.5 [locale.codecvt] | Bad ctype_byname<char> decl | Yes |  |
19(i) | TC1 | 28.4.2.5 [locale.codecvt] | "Noconv" definition too vague | Yes |  | 10
24(i) | TC1 | 28.4.2.5 [locale.codecvt] | "do_convert" doesn't exist | Yes |  | 72
33(i) | TC1 | 28.4.2.5 [locale.codecvt] | Codecvt<> mentions from_type | Yes |  | 43
74(i) | TC1 | 28.4.2.5 [locale.codecvt] | Garbled text for `codecvt::do_max_length` | Yes |  |
75(i) | TC1 | 28.4.2.5 [locale.codecvt] | Contradiction in `codecvt::length`'s argument types | Yes |  |
138(i) | NAD | 28.4.2.5 [locale.codecvt] | Class `ctype_byname<char>` redundant and misleading | Yes |  |
382(i) | NAD | 28.4.2.5 [locale.codecvt] | codecvt do_in/out result | Yes |  |
72(i) | Dup | 28.4.2.5 [locale.codecvt] | Do_convert phantom member function | Yes |  | 24
3337(i) | New | 28.4.2.5.3 [locale.codecvt.virtuals] | What is "is initialized" supposed to mean? | No | 3 |
664(i) | CD1 | 28.4.2.5.3 [locale.codecvt.virtuals] | `do_unshift` for `codecvt<char, char, mbstate_t>` | Yes |  |
665(i) | CD1 | 28.4.2.5.3 [locale.codecvt.virtuals] | `do_unshift` return value | Yes |  |
393(i) | NAD Editorial | 28.4.2.5.3 [locale.codecvt.virtuals] | do_in/do_out operation on state unclear | Yes |  |
305(i) | CD1 | 28.4.2.6 [locale.codecvt.byname] | Default behavior of codecvt<wchar_t, char, mbstate_t>::length() | Yes |  |
380(i) | CD1 | 28.4.2.6 [locale.codecvt.byname] | typos in codecvt tables 53 and 54 | Yes |  |
381(i) | CD1 | 28.4.2.6 [locale.codecvt.byname] | detection of invalid mbstate_t in codecvt | Yes |  |
302(i) | NAD | 28.4.2.6 [locale.codecvt.byname] | Need error indication from codecvt<>::do_length | Yes |  |
500(i) | NAD | 28.4.2.6 [locale.codecvt.byname] | do_length cannot be implemented correctly | Yes |  |
10(i) | Dup | 28.4.2.6 [locale.codecvt.byname] | Codecvt<>::do unclear | Yes |  | 19
43(i) | Dup | 28.4.2.6 [locale.codecvt.byname] | Locale table correction | Yes |  | 33
344(i) | NAD | 28.4.3 [category.numeric] | grouping + showbase | Yes |  |
275(i) | CD1 | 28.4.3.2.2 [facet.num.get.members] | Wrong type in num_get::get() overloads | Yes |  |
18(i) | TC1 | 28.4.3.2.2 [facet.num.get.members] | Get(...bool&) omitted | Yes |  |
3214(i) | New | 28.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 |
2381(i) | WP | 28.4.3.2.3 [facet.num.get.virtuals] | Inconsistency in parsing floating point numbers | Yes | 2 |
1169(i) | C++17 | 28.4.3.2.3 [facet.num.get.virtuals] | `num_get` not fully compatible with `strto*` | Yes | 3 |
427(i) | C++11 | 28.4.3.2.3 [facet.num.get.virtuals] | Stage 2 and rationale of DR 221 | Yes |  |
2041(i) | C++11 | 28.4.3.2.3 [facet.num.get.virtuals] | Stage 2 accumulate incompatibilty | Yes |  |
23(i) | CD1 | 28.4.3.2.3 [facet.num.get.virtuals] | Num_get overflow result | Yes |  |
221(i) | CD1 | 28.4.3.2.3 [facet.num.get.virtuals] | num_get<>::do_get stage 2 processing broken | Yes |  |
321(i) | CD1 | 28.4.3.2.3 [facet.num.get.virtuals] | Typo in num_get | Yes |  |
358(i) | CD1 | 28.4.3.2.3 [facet.num.get.virtuals] | interpreting `thousands_sep` after a `decimal_point` | Yes |  |
17(i) | TC1 | 28.4.3.2.3 [facet.num.get.virtuals] | Bad bool parsing | Yes |  |
154(i) | TC1 | 28.4.3.2.3 [facet.num.get.virtuals] | Missing `double` specifier for `do_get()` | Yes |  |
459(i) | NAD | 28.4.3.2.3 [facet.num.get.virtuals] | Requirement for widening in stage 2 is overspecification | Yes |  |
662(i) | NAD | 28.4.3.2.3 [facet.num.get.virtuals] | Inconsistent handling of incorrectly-placed thousands separators | Yes |  |
826(i) | NAD | 28.4.3.3 [locale.nm.put] | Equivalent of `%'d`, or rather, lack thereof? | Yes |  |
359(i) | CD1 | 28.4.3.3.2 [facet.num.put.members] | num_put<>::do_put (..., bool) undocumented | Yes |  |
2703(i) | New | 28.4.3.3.3 [facet.num.put.virtuals] | No provision for fill-padding when `boolalpha` is set | No | 3 |
2702(i) | New | 28.4.3.3.3 [facet.num.put.virtuals] | `num_put::do_put(..., bool)` performs ill-formed `do_put` call | No | 3 |
2117(i) | Open | 28.4.3.3.3 [facet.num.put.virtuals] | `ios_base` manipulators should have `showgrouping/noshowgrouping` | No | 3 |
2293(i) | C++14 | 28.4.3.3.3 [facet.num.put.virtuals] | Wrong facet used by `num_put::do_put` | Yes | 0 |
671(i) | C++11 | 28.4.3.3.3 [facet.num.put.virtuals] | precision of `hexfloat` | Yes |  |
1152(i) | C++11 | 28.4.3.3.3 [facet.num.put.virtuals] | Expressions parsed differently than intended | Yes |  |
231(i) | CD1 | 28.4.3.3.3 [facet.num.put.virtuals] | Precision in iostream? | Yes |  |
282(i) | CD1 | 28.4.3.3.3 [facet.num.put.virtuals] | What types does numpunct grouping refer to? | Yes |  |
34(i) | TC1 | 28.4.3.3.3 [facet.num.put.virtuals] | True/falsename() not in ctype<> | Yes |  |
361(i) | NAD | 28.4.3.3.3 [facet.num.put.virtuals] | num_get<>::do_get (..., void*&) checks grouping | Yes |  |
20(i) | TC1 | 28.4.4.1.3 [facet.numpunct.virtuals] | Thousands_sep returns wrong type | Yes |  |
318(i) | CD1 | 28.4.4.2 [locale.numpunct.byname] | Misleading comment in definition of numpunct_byname | Yes |  |
248(i) | CD1 | 28.4.6 [category.time] | time_get fails to set eofbit | Yes |  |
71(i) | TC1 | 28.4.6.2 [locale.time.get] | Do_get_monthname synopsis missing argument | Yes |  |
3275(i) | New | 28.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(i) | Open | 28.4.6.2.3 [locale.time.get.virtuals] | Y2K bites; what is an "unambiguous year identifier"? | No | 4 |
461(i) | CD1 | 28.4.6.2.3 [locale.time.get.virtuals] | time_get hard or impossible to implement | Yes |  |
164(i) | TC1 | 28.4.6.4.2 [locale.time.put.virtuals] | do_put() has apparently unused fill argument | Yes |  |
836(i) | C++11 | 28.4.7.2.2 [locale.money.get.virtuals] | Effects of `money_base::space` and `money_base::none` on `money_get` | Yes |  | 670
667(i) | NAD | 28.4.7.2.2 [locale.money.get.virtuals] | `money_get`'s widened minus sign | Yes |  |
668(i) | NAD | 28.4.7.2.2 [locale.money.get.virtuals] | `money_get`'s empty minus sign | Yes |  |
669(i) | NAD | 28.4.7.2.2 [locale.money.get.virtuals] | Equivalent postive and negative signs in `money_get` | Yes |  |
2983(i) | New | 28.4.7.3.2 [locale.money.put.virtuals] | `money_put::do_put` underspecified | Yes | 3 |
328(i) | CD1 | 28.4.7.3.2 [locale.money.put.virtuals] | Bad sprintf format modifier in money_put<>::do_put() | Yes |  |
2691(i) | New | 28.4.7.4 [locale.moneypunct] | `money_base::space` and `do_put`: U+0020 versus `fill` | Yes | 3 |
670(i) | Dup | 28.4.7.4 [locale.moneypunct] | `money_base::pattern` and `space` | Yes |  | 836
374(i) | NAD | 28.4.7.4.2 [locale.moneypunct.members] | moneypunct::frac_digits returns int not unsigned | Yes |  |
325(i) | CD1 | 28.4.7.4.3 [locale.moneypunct.virtuals] | Misleading text in moneypunct<>::do_grouping | Yes |  |
666(i) | CD1 | 28.4.7.4.3 [locale.moneypunct.virtuals] | `moneypunct::do_curr_symbol()` | Yes |  |
326(i) | NAD | 28.4.7.5 [locale.moneypunct.byname] | Missing typedef in moneypunct_byname | Yes |  |
2028(i) | C++14 | 28.4.8.2 [locale.messages] | `messages_base::catalog` overspecified | Yes |  |

## Section 29 (299 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
423(i) | Open | 29 [input.output] | Effects of negative `streamsize` in iostreams | Yes | 3 |
3130(i) | C++20 | 29 [input.output] | §[input.output] needs many `addressof` | Yes | 0 |
44(i) | CD1 | 29 [input.output] | Iostreams use operator== on int_type values | Yes |  |
273(i) | CD1 | 29 [input.output] | Missing ios_base qualification on members of a dependent class | Yes |  |
308(i) | CD1 | 29 [input.output] | Table 82 mentions unrelated headers | Yes |  |
365(i) | CD1 | 29 [input.output] | Lack of const-qualification in clause 27 | Yes |  |
55(i) | TC1 | 29 [input.output] | Invalid stream position is undefined | Yes |  |
366(i) | NAD | 29 [input.output] | Excessive const-qualification | Yes |  |
1141(i) | NAD Concepts | 29 [input.output] | Input/Output library not concept enabled | Yes |  |
623(i) | CD1 | 29.2.1 [iostream.limits.imbue] | `pubimbue` forbidden to call `imbue` | Yes |  |
369(i) | CD1 | 29.4 [iostream.objects] | io stream objects and static ctors | Yes |  |
455(i) | CD1 | 29.4 [iostream.objects] | cerr::tie() and wcerr::tie() are overspecified | Yes |  |
574(i) | CD1 | 29.4 [iostream.objects] | DR 369 Contradicts Text | Yes |  |
155(i) | TC1 | 29.4 [iostream.objects] | Typo in naming the class defining the class `Init` | Yes |  |
29(i) | TC1 | 29.4.3 [narrow.stream.objects] | Ios_base::init doesn't exist | Yes |  |
178(i) | NAD | 29.4.3 [narrow.stream.objects] | Should clog and cerr initially be tied to cout? | Yes |  |
2087(i) | C++14 | 29.5 [iostreams.base] | `iostream_category()` and `noexcept` | Yes |  |
1257(i) | C++11 | 29.5 [iostreams.base] | Header <ios> still contains a `concept_map` | Yes |  |
35(i) | TC1 | 29.5 [iostreams.base] | No manipulator unitbuf in synopsis | Yes |  |
2462(i) | C++17 | 29.5.2 [ios.base] | `std::ios_base::failure` is overspecified | Yes | 3 |
2143(i) | C++14 | 29.5.2 [ios.base] | `ios_base::xalloc` should be thread-safe | Yes |  |
41(i) | TC1 | 29.5.2 [ios.base] | Ios_base needs clear(), exceptions() | Yes |  | 157
50(i) | TC1 | 29.5.2 [ios.base] | Copy constructor and assignment operator of ios_base | Yes |  |
78(i) | TC1 | 29.5.2 [ios.base] | Typo: event_call_back | Yes |  |
331(i) | CD1 | 29.5.2.2.1 [ios.failure] | bad declaration of destructor for ios_base::failure | Yes |  |
363(i) | CD1 | 29.5.2.2.1 [ios.failure] | Missing exception specification in 27.4.2.1.1 | Yes |  |
48(i) | TC1 | 29.5.2.2.1 [ios.failure] | Use of non-existent exception constructor | Yes |  |
2765(i) | C++17 | 29.5.2.2.6 [ios.init] | Did LWG 1123 go too far? | Yes | 0 |
1123(i) | C++11 | 29.5.2.2.6 [ios.init] | No requirement that standard streams be flushed | Yes |  |
418(i) | NAD | 29.5.2.2.6 [ios.init] | exceptions thrown during iostream cleanup | Yes |  |
189(i) | TC1 | 29.5.2.3 [fmtflags.state] | setprecision() not specified correctly | Yes |  |
287(i) | NAD | 29.5.2.3 [fmtflags.state] | conflicting ios_base fmtflags | Yes |  |
47(i) | TC1 | 29.5.2.4 [ios.base.locales] | Imbue() and getloc() Returns clauses swapped | Yes |  |
156(i) | TC1 | 29.5.2.4 [ios.base.locales] | Typo in `imbue()` description | Yes |  |
49(i) | CD1 | 29.5.2.5 [ios.members.static] | Underspecification of ios_base::sync_with_stdio | Yes |  |
3675(i) | New | 29.5.2.6 [ios.base.storage] | `std::ios_base::iword/pword` might be misspecified | Yes | 4 |
3083(i) | C++20 | 29.5.2.6 [ios.base.storage] | What should `ios::iword(-1)` do? | Yes | 0 |
36(i) | TC1 | 29.5.2.6 [ios.base.storage] | Iword & pword storage lifetime omitted | Yes |  |
2600(i) | NAD | 29.5.2.6 [ios.base.storage] | `ios_base` must store inaccessible iostate flags | Yes |  |
157(i) | Dup | 29.5.2.6 [ios.base.storage] | Meaningless error handling for `pword()` and `iword()` | Yes |  | 41
2675(i) | New | 29.5.2.7 [ios.base.callback] | `register_callback` can fail | No | 3 |
3434(i) | WP | 29.5.2.8 [ios.base.cons] | `ios_base` never reclaims memory for `iarray` and `parray` | Yes |  |
220(i) | TC1 | 29.5.2.8 [ios.base.cons] | ~ios_base() usage valid? | Yes |  |
441(i) | CD1 | 29.5.3 [fpos] | Is fpos::state const? | Yes |  |
6(i) | NAD | 29.5.3 [fpos] | File position not an offset unimplementable | Yes |  |
332(i) | NAD | 29.5.3 [fpos] | Consider adding increment and decrement operators to std::fpos< T > | Yes |  |
573(i) | NAD | 29.5.3 [fpos] | C++0x file positioning should handle modern file sizes | Yes |  |
3118(i) | New | 29.5.3.2 [fpos.operations] | `fpos` equality comparison unspecified | No | 4 |
52(i) | TC1 | 29.5.3.2 [fpos.operations] | Small I/O problems | Yes |  |
2808(i) | Resolved | 29.5.3.2 [fpos.operations] | Requirements for `fpos` and `stateT` | Yes | 4 |
2832(i) | Resolved | 29.5.3.2 [fpos.operations] | §[fpos.operations] strange requirement for `P(i)` | Yes | 3 |
1444(i) | Dup | 29.5.3.2 [fpos.operations] | `OFF_T` is not defined | Yes |  | 1414
194(i) | NAD | 29.5.4 [ios] | rdbuf() functions poorly specified | Yes |  |
2214(i) | Open | 29.5.4.2 [basic.ios.cons] | Clarify `basic_ios::init` call restrictions | Yes | 4 |
1249(i) | C++11 | 29.5.4.2 [basic.ios.cons] | `basic_ios` default ctor | Yes |  |
53(i) | TC1 | 29.5.4.2 [basic.ios.cons] | Basic_ios destructor unspecified | Yes |  |
145(i) | NAD | 29.5.4.2 [basic.ios.cons] | adjustfield lacks default value | Yes |  |
835(i) | C++11 | 29.5.4.3 [basic.ios.members] | Tying two streams together (correction to DR 581) | Yes |  |
1104(i) | C++11 | 29.5.4.3 [basic.ios.members] | `basic_ios::move` should accept lvalues | Yes |  |
1183(i) | C++11 | 29.5.4.3 [basic.ios.members] | `basic_ios::set_rdbuf` may break class invariants | Yes |  |
256(i) | CD1 | 29.5.4.3 [basic.ios.members] | typo in 27.4.4.2, p17: copy_event does not exist | Yes |  |
292(i) | CD1 | 29.5.4.3 [basic.ios.members] | effects of a.copyfmt (a) | Yes |  |
837(i) | NAD Editorial | 29.5.4.3 [basic.ios.members] | `basic_ios::copyfmt()` overly loosely specified | Yes |  |
1094(i) | C++11 | 29.5.4.4 [iostate.flags] | Replace "unspecified-bool-type" by "`explicit operator bool() const`" in I/O library | Yes |  |
272(i) | CD1 | 29.5.4.4 [iostate.flags] | Missing parentheses around subexpression | Yes |  | 569
412(i) | CD1 | 29.5.4.4 [iostate.flags] | Typo in 27.4.4.3 | Yes |  | 429
468(i) | CD1 | 29.5.4.4 [iostate.flags] | unexpected consequences of ios_base::operator void*() | Yes |  |
429(i) | Dup | 29.5.4.4 [iostate.flags] | typo in basic_ios::clear(iostate) | Yes |  | 412
569(i) | Dup | 29.5.4.4 [iostate.flags] | Postcondition for basic_ios::clear(iostate) incorrectly stated | Yes |  | 272
2504(i) | New | 29.6.3 [streambuf] | `basic_streambuf` is not an abstract class | No | 3 |
56(i) | TC1 | 29.6.3 [streambuf] | Showmanyc's return type | Yes |  |
122(i) | TC1 | 29.6.3 [streambuf] | streambuf/wstreambuf description should not say they are specializations | Yes |  |
255(i) | NAD | 29.6.3 [streambuf] | Why do `basic_streambuf<>::pbump()` and `gbump()` take an int? | Yes |  |
54(i) | TC1 | 29.6.3.2 [streambuf.cons] | Basic_streambuf's destructor | Yes |  |
421(i) | NAD | 29.6.3.2 [streambuf.cons] | is `basic_streambuf` copy-constructible? | Yes |  |
3658(i) | New | 29.6.3.3.5 [streambuf.pub.put] | `basic_streambuf::sputn` is both overspecified and underspecified | Yes | 3 |
59(i) | TC1 | 29.6.3.4.2 [streambuf.get.area] | Ambiguity in specification of gbump | Yes |  |
364(i) | CD1 | 29.6.3.5.2 [streambuf.virt.buffer] | Inconsistent wording in 27.5.2.4.2 | Yes |  |
158(i) | TC1 | 29.6.3.5.2 [streambuf.virt.buffer] | Underspecified semantics for `setbuf()` | Yes |  |
159(i) | TC1 | 29.6.3.5.3 [streambuf.virt.get] | Strange use of `underflow()` | Yes |  |
32(i) | TC1 | 29.6.3.5.4 [streambuf.virt.pback] | Pbackfail description inconsistent | Yes |  |
565(i) | C++11 | 29.6.3.5.5 [streambuf.virt.put] | `xsputn` inefficient | Yes |  |
567(i) | CD1 | 29.7 [iostream.format] | streambuf inserter and extractor should be unformatted | Yes |  |
1445(i) | Resolved | 29.7 [iostream.format] | Several iostreams member functions incorrectly specified | Yes |  |
1447(i) | Resolved | 29.7 [iostream.format] | Request to resolve issue LWG 1328 | Yes |  |
309(i) | NAD | 29.7 [iostream.format] | Does sentry catch exceptions? | Yes |  |
1148(i) | NAD | 29.7 [iostream.format] | Wrong argument type of I/O stream manipulators `setprecision()` and `setw()` | Yes |  |
1446(i) | NAD | 29.7 [iostream.format] | Move and swap for I/O streams | Yes |  |
911(i) | C++11 | 29.7.4 [input.streams] | I/O streams and `move/swap` semantic | Yes |  |
160(i) | TC1 | 29.7.4.2 [istream] | Typo: Use of non-existing function `exception()` | Yes |  |
113(i) | NAD | 29.7.4.2 [istream] | Missing/extra iostream sync semantics | Yes |  |
2036(i) | NAD | 29.7.4.2 [istream] | `istream >> char` and `eofbit` | Yes |  |
419(i) | C++11 | 29.7.4.2.4 [istream.sentry] | istream extractors not setting `failbit` if `eofbit` is already set | Yes |  |
26(i) | TC1 | 29.7.4.2.4 [istream.sentry] | Bad sentry example | Yes |  |
195(i) | TC1 | 29.7.4.2.4 [istream.sentry] | Should `basic_istream::sentry`'s constructor ever set eofbit? | Yes |  |
1328(i) | Resolved | 29.7.4.2.4 [istream.sentry] | istream extractors not setting `failbit` if `eofbit` is already set | Yes |  |
203(i) | NAD | 29.7.4.2.4 [istream.sentry] | basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type> | Yes |  |
2349(i) | Open | 29.7.4.3.1 [istream.formatted.reqmts] | Clarify input/output function rethrow behavior | Yes | 3 |
373(i) | CD1 | 29.7.4.3.1 [istream.formatted.reqmts] | Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ? | Yes |  |
60(i) | TC1 | 29.7.4.3.1 [istream.formatted.reqmts] | What is a formatted input function? | Yes |  | 162, 163, 166
696(i) | C++11 | 29.7.4.3.2 [istream.formatted.arithmetic] | `istream::operator>>(int&)` broken | Yes |  |
118(i) | CD1 | 29.7.4.3.2 [istream.formatted.arithmetic] | `basic_istream` uses nonexistent `num_get` member functions | Yes |  |
661(i) | CD1 | 29.7.4.3.2 [istream.formatted.arithmetic] | New 27.6.1.2.2 changes make special extractions useless | Yes |  |
161(i) | TC1 | 29.7.4.3.2 [istream.formatted.arithmetic] | Typo: `istream_iterator` vs. `istreambuf_iterator` | Yes |  |
413(i) | CD1 | 29.7.4.3.3 [istream.extractors] | Proposed resolution to LDR#64 still wrong | Yes |  |
13(i) | TC1 | 29.7.4.3.3 [istream.extractors] | Eos refuses to die | Yes |  |
64(i) | TC1 | 29.7.4.3.3 [istream.extractors] | Exception handling in `basic_istream::operator>>(basic_streambuf*)` | Yes |  |
68(i) | TC1 | 29.7.4.3.3 [istream.extractors] | Extractors for char* should store null at end | Yes |  |
2499(i) | Resolved | 29.7.4.3.3 [istream.extractors] | `operator>>(basic_istream&, CharT*)` makes it hard to avoid buffer overflows | Yes | 2 |
58(i) | NAD | 29.7.4.3.3 [istream.extractors] | Extracting a char from a wide-oriented stream | Yes |  |
639(i) | NAD | 29.7.4.3.3 [istream.extractors] | Still problems with exceptions during streambuf IO | Yes |  |
162(i) | Dup | 29.7.4.3.3 [istream.extractors] | Really "formatted input functions"? | Yes |  | 60
3464(i) | WP | 29.7.4.4 [istream.unformatted] | `istream::gcount()` can overflow | Yes | 0 |
2243(i) | C++20 | 29.7.4.4 [istream.unformatted] | `istream::putback` problem | Yes | 3 |
2244(i) | C++17 | 29.7.4.4 [istream.unformatted] | Issue on `basic_istream::seekg` | Yes | 3 |
2085(i) | C++14 | 29.7.4.4 [istream.unformatted] | Wrong description of effect 1 of `basic_istream::ignore` | Yes |  |
136(i) | CD1 | 29.7.4.4 [istream.unformatted] | seekp, seekg setting wrong streams? | Yes |  |
243(i) | CD1 | 29.7.4.4 [istream.unformatted] | `get` and `getline` when sentry reports failure | Yes |  |
370(i) | CD1 | 29.7.4.4 [istream.unformatted] | Minor error in basic_istream::get | Yes |  |
531(i) | CD1 | 29.7.4.4 [istream.unformatted] | array forms of unformatted input functions | Yes |  |
537(i) | CD1 | 29.7.4.4 [istream.unformatted] | Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4 | Yes |  |
566(i) | CD1 | 29.7.4.4 [istream.unformatted] | array forms of unformatted input function undefined for zero-element arrays | Yes |  |
61(i) | TC1 | 29.7.4.4 [istream.unformatted] | Ambiguity in iostreams exception policy | Yes |  |
62(i) | TC1 | 29.7.4.4 [istream.unformatted] | `Sync`'s return value | Yes |  |
129(i) | TC1 | 29.7.4.4 [istream.unformatted] | Need error indication from seekp() and seekg() | Yes |  |
172(i) | TC1 | 29.7.4.4 [istream.unformatted] | Inconsistent types for `basic_istream::ignore()` | Yes |  |
342(i) | NAD | 29.7.4.4 [istream.unformatted] | seek and eofbit | Yes |  |
399(i) | NAD | 29.7.4.4 [istream.unformatted] | volations of unformatted input function requirements | Yes |  |
2131(i) | NAD | 29.7.4.4 [istream.unformatted] | Member function getline taking a string as parameter | Yes |  |
163(i) | Dup | 29.7.4.4 [istream.unformatted] | Return of `gcount()` after a call to `gcount` | Yes |  | 60
415(i) | CD1 | 29.7.4.5 [istream.manip] | behavior of std::ws | Yes |  |
2328(i) | C++17 | 29.7.4.6 [istream.rvalue] | Rvalue stream extraction should use perfect forwarding | Yes | 3 |
2498(i) | Resolved | 29.7.4.6 [istream.rvalue] | `operator>>(basic_istream&&, T&&)` returns `basic_istream&`, but should probably return `basic_istream&&` | Yes | 3 |
271(i) | CD1 | 29.7.4.7 [iostreamclass] | basic_iostream missing typedefs | Yes |  |
135(i) | NAD | 29.7.4.7.2 [iostream.cons] | basic_iostream doubly initialized | Yes |  |
2221(i) | C++17 | 29.7.5 [output.streams] | No formatted output operator for `nullptr` | Yes | 3 |
2342(i) | New | 29.7.5.2 [ostream] | User conversion to `wchar_t const*` or to `wchar_t` not invoked for `operator<<` | Yes | 4 |
165(i) | CD1 | 29.7.5.2 [ostream] | `xsputn()`, `pubsync()` never called by `basic_ostream` members? | Yes |  |
311(i) | CD1 | 29.7.5.2 [ostream] | Incorrect wording in basic_ostream class synopsis | Yes |  |
2497(i) | New | 29.7.5.2.4 [ostream.sentry] | Use of `uncaught_exception()` | Yes | 3 |
442(i) | CD1 | 29.7.5.2.4 [ostream.sentry] | sentry::operator bool() inconsistent signature | Yes |  |
397(i) | NAD Editorial | 29.7.5.2.4 [ostream.sentry] | `ostream::sentry` dtor throws exceptions | Yes |  |
398(i) | NAD | 29.7.5.2.4 [ostream.sentry] | effects of end-of-file on unformatted input functions | Yes |  |
2341(i) | C++14 | 29.7.5.2.5 [ostream.seeks] | Inconsistency between `basic_ostream::seekp(pos)` and `basic_ostream::seekp(off, dir)` | Yes | 0 |
3667(i) | Tentatively NAD | 29.7.5.3 [ostream.formatted] | `std::cout << &X::f` prints `1` | Yes |  |
394(i) | NAD | 29.7.5.3.1 [ostream.formatted.reqmts] | behavior of formatted output on failure | Yes |  |
117(i) | CD1 | 29.7.5.3.2 [ostream.inserters.arithmetic] | `basic_ostream` uses nonexistent `num_put` member functions | Yes |  |
640(i) | CD1 | 29.7.5.3.2 [ostream.inserters.arithmetic] | 27.6.2.5.2 does not handle `(unsigned) long long` | Yes |  |
437(i) | NAD | 29.7.5.3.2 [ostream.inserters.arithmetic] | Formatted output of function pointers is confusing | Yes |  |
166(i) | Dup | 29.7.5.3.3 [ostream.inserters] | Really "formatted output functions"? | Yes |  | 60
167(i) | CD1 | 29.7.5.3.4 [ostream.inserters.character] | Improper use of `traits_type::length()` | Yes |  |
474(i) | CD1 | 29.7.5.3.4 [ostream.inserters.character] | confusing Footnote 297 | Yes |  |
581(i) | CD1 | 29.7.5.4 [ostream.unformatted] | `flush()` not unformatted function | Yes |  |
63(i) | TC1 | 29.7.5.4 [ostream.unformatted] | Exception-handling policy for unformatted output | Yes |  |
168(i) | TC1 | 29.7.5.4 [ostream.unformatted] | Typo: formatted vs. unformatted | Yes |  |
3501(i) | New | 29.7.5.5 [ostream.manip] | `basic_syncbuf`-related manipulators refer to some `Allocator` without defining it | Yes | 3 |
3571(i) | WP | 29.7.5.5 [ostream.manip] | `flush_emit` should set `badbit` if the `emit` call fails | Yes |  |
333(i) | CD1 | 29.7.5.5 [ostream.manip] | does endl imply synchronization with the device? | Yes |  |
1203(i) | C++20 | 29.7.5.6 [ostream.rvalue] | More useful rvalue stream insertion | Yes | 2 |
2534(i) | C++17 | 29.7.5.6 [ostream.rvalue] | Constrain rvalue stream operators | Yes | 3 |
183(i) | CD1 | 29.7.6 [std.manip] | I/O stream manipulators don't work for wide character streams | Yes |  |
216(i) | Dup | 29.7.6 [std.manip] | setbase manipulator description flawed | Yes |  | 193
2984(i) | New | 29.7.7 [ext.manip] | `put_money(99)` is unnecessarily undefined | Yes | 3 |
810(i) | C++11 | 29.7.7 [ext.manip] | Missing traits dependencies in operational semantics of extended manipulators | Yes |  |
1299(i) | C++11 | 29.7.7 [ext.manip] | Confusing typo in specification for `get_time` | Yes |  |
692(i) | CD1 | 29.7.7 [ext.manip] | `get_money` and `put_money` should be formatted I/O functions | Yes |  |
641(i) | NAD Editorial | 29.7.7 [ext.manip] | Editorial fix for 27.6.4 (N2134) | Yes |  |
2785(i) | C++17 | 29.7.8 [quoted.manip] | `quoted` should work with `basic_string_view` | Yes | 0 |
2272(i) | C++14 | 29.7.8 [quoted.manip] | `quoted` should use `char_traits::eq` for character comparison | Yes |  |
2344(i) | C++14 | 29.7.8 [quoted.manip] | `quoted()`'s interaction with padding is unclear | Yes | 1 |
3309(i) | New | 29.8 [string.streams] | Is `<ios>` implicitly `#include`d by `<sstream>`, `<fstream>` etc.? | No | 3 |
252(i) | CD1 | 29.8 [string.streams] | missing casts/C-style casts used in iostreams | Yes |  |
562(i) | CD1 | 29.8 [string.streams] | stringbuf ctor inefficient | Yes |  |
128(i) | NAD | 29.8 [string.streams] | Need open_mode() function for file stream, string streams, file buffers, and string buffers | Yes |  |
251(i) | CD1 | 29.8.2 [stringbuf] | basic_stringbuf missing allocator_type | Yes |  |
2995(i) | C++20 | 29.8.2.2 [stringbuf.cons] | `basic_stringbuf` default constructor forbids it from using SSO capacity | Yes | 3 |
238(i) | CD1 | 29.8.2.2 [stringbuf.cons] | Contradictory results of stringbuf initialization. | Yes |  |
3006(i) | Resolved | 29.8.2.2 [stringbuf.cons] | Constructing a `basic_stringbuf` from a `string` — where does the allocator come from? | Yes | 3 |
1251(i) | NAD | 29.8.2.2 [stringbuf.cons] | move constructing `basic_stringbuf` | Yes |  |
1448(i) | C++11 | 29.8.2.4 [stringbuf.members] | Concerns about `basic_stringbuf::str(basic_string)` postconditions | Yes |  |
3097(i) | New | 29.8.2.5 [stringbuf.virtuals] | `basic_stringbuf seekoff` effects trigger undefined behavior and have contradictory returns | No | 3 |
2286(i) | Open | 29.8.2.5 [stringbuf.virtuals] | `stringbuf::underflow()` underspecified | Yes | 4 |
564(i) | C++11 | 29.8.2.5 [stringbuf.virtuals] | `stringbuf` seekpos underspecified | Yes |  |
375(i) | CD1 | 29.8.2.5 [stringbuf.virtuals] | basic_ios should be ios_base in 27.7.1.3 | Yes |  |
376(i) | CD1 | 29.8.2.5 [stringbuf.virtuals] | basic_streambuf semantics | Yes |  |
432(i) | CD1 | 29.8.2.5 [stringbuf.virtuals] | stringbuf::overflow() makes only one write position available | Yes |  |
453(i) | CD1 | 29.8.2.5 [stringbuf.virtuals] | basic_stringbuf::seekoff need not always fail for an empty stream | Yes |  |
563(i) | CD1 | 29.8.2.5 [stringbuf.virtuals] | stringbuf seeking from end | Yes |  |
169(i) | TC1 | 29.8.2.5 [stringbuf.virtuals] | Bad efficiency of `overflow()` mandated | Yes |  |
1449(i) | C++11 | 29.8.3 [istringstream] | Incomplete specification of header `<cinttypes>` | Yes |  |
2429(i) | NAD | 29.8.4 [ostringstream] | `std::basic_ostringstream` is missing an allocator-extended constructor | Yes |  |
45(i) | NAD | 29.8.4 [ostringstream] | Stringstreams read/write pointers initial position unclear | Yes |  |
170(i) | TC1 | 29.8.5 [stringstream] | Inconsistent definition of `traits_type` | Yes |  |
2121(i) | NAD | 29.8.5.2 [stringstream.cons] | `app` for string streams | Yes | 3 |
2676(i) | C++17 | 29.10 [file.streams] | Provide `filesystem::path` overloads for File-based streams | Yes | 2 |
420(i) | CD1 | 29.10 [file.streams] | is std::FILE a complete type? | Yes |  |
444(i) | CD1 | 29.10 [file.streams] | Bad use of casts in fstream | Yes |  |
460(i) | CD1 | 29.10 [file.streams] | Default modes missing from basic_fstream member specifications | Yes |  |
73(i) | NAD | 29.10 [file.streams] | `is_open` should be const | Yes |  |
863(i) | NAD | 29.10 [file.streams] | What is the state of a stream after close() succeeds | Yes |  |
105(i) | Dup | 29.10 [file.streams] | fstream ctors argument types desired | Yes |  | 454
3430(i) | WP | 29.10.1 [fstream.syn] | `std::fstream` & co. should be constructible from `string_view` | Yes | 3 |
643(i) | CD1 | 29.10.2 [filebuf] | Impossible "as if" clauses | Yes |  |
2943(i) | C++20 | 29.10.2.4 [filebuf.members] | Problematic specification of the wide version of `basic_filebuf::open` | Yes | 2 |
443(i) | CD1 | 29.10.2.4 [filebuf.members] | filebuf::close() inconsistent use of EOF | Yes |  |
596(i) | CD1 | 29.10.2.4 [filebuf.members] | 27.8.1.3 Table 112 omits "a+" and "a+b" modes | Yes |  |
454(i) | NAD | 29.10.2.4 [filebuf.members] | `basic_filebuf::open` should accept `wchar_t` names | Yes |  | 105
2473(i) | C++17 | 29.10.2.5 [filebuf.virtuals] | `basic_filebuf`'s relation to C `FILE` semantics | Yes | 2 |
171(i) | CD1 | 29.10.2.5 [filebuf.virtuals] | Strange `seekpos()` semantics due to joint position | Yes |  |
173(i) | TC1 | 29.10.2.5 [filebuf.virtuals] | Inconsistent types for `basic_filebuf::setbuf()` | Yes |  |
285(i) | CD1 | 29.10.3.2 [ifstream.cons] | minor editorial errors in fstream ctors | Yes |  |
900(i) | C++11 | 29.10.3.3 [ifstream.assign] | Stream move-assignment | Yes |  |
409(i) | CD1 | 29.10.3.4 [ifstream.members] | Closing an fstream should clear error state | Yes |  |
22(i) | TC1 | 29.10.3.4 [ifstream.members] | Member open vs. flags | Yes |  |
592(i) | NAD Editorial | 29.10.3.4 [ifstream.members] | Incorrect treatment of rdbuf()->close() return type | Yes |  |
642(i) | NAD Editorial | 29.10.3.4 [ifstream.members] | Invalidated fstream footnotes in N2134 | Yes |  |
1150(i) | Resolved | 29.10.5 [fstream] | wchar_t, char16_t and char32_t filenames | Yes |  |
622(i) | CD1 | 29.10.5.4 [fstream.members] | behavior of `filebuf` dtor and `close` on error | Yes |  |
3498(i) | WP | 29.11.2.1 [syncstream.syncbuf.overview] | Inconsistent `noexcept`-specifiers for `basic_syncbuf` | Yes | 3 |
3253(i) | C++20 | 29.11.2.1 [syncstream.syncbuf.overview] | `basic_syncbuf::basic_syncbuf()` should not be explicit | Yes | 0 |
3399(i) | NAD | 29.11.2.1 [syncstream.syncbuf.overview] | `basic_syncbuf::emit()` + Qt's `#define emit` = Big Bada-Boom | Yes |  |
3496(i) | New | 29.11.2.4 [syncstream.syncbuf.members] | What does "uniquely associated" mean for `basic_syncbuf::emit()`? | No | 3 |
3497(i) | New | 29.11.2.4 [syncstream.syncbuf.members] | Postconditions for `basic_syncbuf::emit()` | No | 3 |
3616(i) | WP | 29.11.2.6 [syncstream.syncbuf.special] | LWG 3498 seems to miss the non-member `swap` for `basic_syncbuf` | Yes |  |
3334(i) | C++20 | 29.11.3 [syncstream.osyncstream] | `basic_osyncstream` move assignment and destruction calls `basic_syncbuf::emit()` twice | Yes | 3 |
3127(i) | C++20 | 29.11.3.1 [syncstream.osyncstream.overview] | `basic_osyncstream::rdbuf` needs a `const_cast` | Yes | 0 |
3570(i) | WP | 29.11.3.3 [syncstream.osyncstream.members] | `basic_osyncstream::emit` should be an unformatted output function | Yes |  |
2680(i) | C++17 | 29.12 [filesystems] | Add "Equivalent to" to filesystem | Yes | 2 |
2666(i) | NAD Editorial | 29.12 [filesystems] | Bitmask operations should use bitmask terms | Yes | 3 |
3657(i) | WP | 29.12.6 [fs.class.path] | `std::hash<std::filesystem::path>` is not enabled | Yes |  |
2707(i) | C++17 | 29.12.6 [fs.class.path] | `path` construction and assignment should have "`string_type&&`" overloads | Yes | 0 |
2798(i) | Resolved | 29.12.6 [fs.class.path] | Definition of path in terms of a string | Yes | 2 |
2668(i) | NAD | 29.12.6 [fs.class.path] | `path::operator+=` is defined, but not `operator+` | Yes | 3 |
3244(i) | C++20 | 29.12.6.4 [fs.path.req] | Constraints for `Source` in §[fs.path.req] insufficiently constrainty | Yes | 0 |
2711(i) | C++17 | 29.12.6.5.1 [fs.path.construct] | `path` is convertible from approximately everything under the sun | Yes | 1 |
2664(i) | C++17 | 29.12.6.5.3 [fs.path.append] | `operator/` (and other append) semantics not useful if argument has root | Yes | 2 |
2732(i) | C++17 | 29.12.6.5.3 [fs.path.append] | Questionable specification of `path::operator/=` and `path::append` | Yes | 2 |
3055(i) | C++20 | 29.12.6.5.4 [fs.path.concat] | `path::operator+=(single-character)` misspecified | Yes | 3 |
2734(i) | Resolved | 29.12.6.5.4 [fs.path.concat] | Questionable specification in [fs.path.concat] | Yes | 2 |
2665(i) | Resolved | 29.12.6.5.5 [fs.path.modifiers] | `remove_filename()` post condition is incorrect | Yes | 1 |
2966(i) | C++20 | 29.12.6.5.6 [fs.path.native.obs] | Incomplete resolution of US 74 | Yes |  |
2936(i) | C++20 | 29.12.6.5.8 [fs.path.compare] | Path comparison is defined in terms of the generic format | Yes | 2 |
3098(i) | New | 29.12.6.5.9 [fs.path.decompose] | Misleading example for `filesystem::path::filename()` | Yes | 3 |
2667(i) | C++17 | 29.12.6.5.9 [fs.path.decompose] | `path::root_directory()` description is confusing | Yes | 0 |
3070(i) | C++20 | 29.12.6.5.11 [fs.path.gen] | `path::lexically_relative` causes surprising results if a filename can also be a root-name | Yes | 2 |
3096(i) | C++20 | 29.12.6.5.11 [fs.path.gen] | `path::lexically_relative` is confused by trailing slashes | Yes | 2 |
2674(i) | C++17 | 29.12.6.6 [fs.path.itr] | Bidirectional iterator requirement on `path::iterator` is very expensive | Yes | 2 |
2989(i) | C++20 | 29.12.6.7 [fs.path.io] | `path`'s stream insertion operator lets you insert everything under the sun | Yes | 2 |
3065(i) | C++20 | 29.12.6.8 [fs.path.nonmember] | LWG 2989 missed that all `path`'s other operators should be hidden friends as well | Yes | 2 |
2965(i) | C++20 | 29.12.7.2 [fs.filesystem.error.members] | Non-existing `path::native_string()` in `filesystem_error::what()` specification | Yes | 0 |
3043(i) | C++20 | 29.12.7.2 [fs.filesystem.error.members] | Bogus postcondition for `filesystem_error` constructor | Yes | 0 |
2947(i) | New | 29.12.8.1 [fs.enum.path.format] | Clarify several filesystem terms | No | 3 |
2851(i) | C++20 | 29.12.8.2 [fs.enum.file.type] | `std::filesystem` enum classes are now underspecified | Yes | 2 |
2678(i) | C++17 | 29.12.8.2 [fs.enum.file.type] | `std::filesystem` enum classes overspecified | Yes | 3 |
2787(i) | C++17 | 29.12.9 [fs.class.file.status] | §[fs.file_status.cons] doesn't match class definition | Yes | 0 |
3078(i) | New | 29.12.10 [fs.class.directory.entry] | `directory_entry`, `directory_iterator` and `recursive_directory_iterator` perform needless path copies | No | 3 |
3171(i) | WP | 29.12.10 [fs.class.directory.entry] | LWG 2989 breaks `directory_entry` stream insertion | Yes | 2 |
2677(i) | Resolved | 29.12.10.4 [fs.dir.entry.obs] | `directory_entry::status` is not allowed to be cached as a quality-of-implementation issue | Yes | 2 |
2761(i) | NAD | 29.12.10.4 [fs.dir.entry.obs] | `directory_entry` comparisons are members | Yes | 2 |
3480(i) | WP | 29.12.11 [fs.class.directory.iterator] | `directory_iterator` and `recursive_directory_iterator` are not C++20 ranges | Yes | 3 |
2723(i) | C++17 | 29.12.11 [fs.class.directory.iterator] | Do `directory_iterator` and `recursive_directory_iterator` become the end iterator upon error? | Yes | 0 |
3668(i) | New | 29.12.11.2 [fs.dir.itr.members] | `[recursive_]directory_iterator` constructors refer to undefined `options` | No | 3 |
3013(i) | C++20 | 29.12.11.2 [fs.dir.itr.members] | `(recursive_)directory_iterator` construction and traversal should not be `noexcept` | Yes | 0 |
2726(i) | C++17 | 29.12.11.2 [fs.dir.itr.members] | `[recursive_]directory_iterator::increment(error_code&)` is underspecified | Yes | 0 |
2840(i) | Resolved | 29.12.11.2 [fs.dir.itr.members] | `directory_iterator::increment` is seemingly narrow-contract but marked `noexcept` | Yes | 2 |
2706(i) | C++17 | 29.12.12 [fs.class.rec.dir.itr] | Error reporting for `recursive_directory_iterator::pop()` is under-specified | Yes | 0 |
2708(i) | Open | 29.12.12.2 [fs.rec.dir.itr.members] | `recursive_directory_iterator::recursion_pending()` is incorrectly specified | Yes | 2 |
3067(i) | C++20 | 29.12.12.2 [fs.rec.dir.itr.members] | `recursive_directory_iterator::pop` must invalidate | Yes | 0 |
2669(i) | C++17 | 29.12.12.2 [fs.rec.dir.itr.members] | `recursive_directory_iterator` effects refers to non-existent functions | Yes | 0 |
2704(i) | C++17 | 29.12.12.2 [fs.rec.dir.itr.members] | `recursive_directory_iterator`'s members should require '`*this` is dereferenceable' | Yes | 1 |
2956(i) | C++17 | 29.12.13.3 [fs.op.canonical] | `filesystem::canonical()` still defined in terms of `absolute(p, base)` | Yes | 1 |
3057(i) | Open | 29.12.13.4 [fs.op.copy] | Correct `copy_options` handling | Yes | 2 |
2682(i) | C++20 | 29.12.13.4 [fs.op.copy] | `filesystem::copy()` won't create a symlink to a directory | Yes | 2 |
3015(i) | C++20 | 29.12.13.4 [fs.op.copy] | `copy_options::unspecified` underspecified | Yes | 3 |
2671(i) | C++17 | 29.12.13.4 [fs.op.copy] | Errors in Copy | Yes | 0 |
2681(i) | C++17 | 29.12.13.4 [fs.op.copy] | `filesystem::copy()` cannot copy symlinks | Yes | 2 |
2683(i) | C++17 | 29.12.13.4 [fs.op.copy] | `filesystem::copy()` says "no effects" | Yes | 3 |
3056(i) | New | 29.12.13.5 [fs.op.copy.file] | `copy_file()` copies which attributes? | Yes | 3 |
2849(i) | C++20 | 29.12.13.5 [fs.op.copy.file] | Why does `!is_regular_file(from)` cause `copy_file` to report a "file already exists" error? | Yes | 2 |
3014(i) | C++20 | 29.12.13.5 [fs.op.copy.file] | More `noexcept` issues with filesystem operations | Yes |  |
2712(i) | C++17 | 29.12.13.5 [fs.op.copy.file] | `copy_file(from, to, ...)` has a number of unspecified error conditions | Yes | 2 |
2935(i) | C++20 | 29.12.13.7 [fs.op.create.directories] | What should `create_directories` do when `p` already exists but is not a directory? | Yes | 0 |
3079(i) | C++20 | 29.12.13.8 [fs.op.create.directory] | LWG 2935 forgot to fix the `existing_p` overloads of `create_directory` | Yes | 0 |
2937(i) | C++20 | 29.12.13.13 [fs.op.equivalent] | Is `equivalent("existing_thing", "not_existing_thing")` an error? | Yes | 0 |
2722(i) | C++17 | 29.12.13.13 [fs.op.equivalent] | `equivalent` incorrectly specifies throws clause | Yes | 3 |
2725(i) | C++17 | 29.12.13.14 [fs.op.exists] | `filesystem::exists(const path&, error_code&)` error reporting | Yes | 1 |
2663(i) | Resolved | 29.12.13.15 [fs.op.file.size] | Enable efficient retrieval of file size from `directory_entry` | Yes | 2 |
2672(i) | C++17 | 29.12.13.20 [fs.op.is.empty] | Should is_empty use error_code in its specification? | Yes | 3 |
2719(i) | C++17 | 29.12.13.27 [fs.op.permissions] | `permissions` function should not be `noexcept` due to narrow contract | Yes | 0 |
2720(i) | C++17 | 29.12.13.27 [fs.op.permissions] | `permissions` function incorrectly specified for symlinks | Yes | 2 |
2721(i) | C++17 | 29.12.13.32 [fs.op.remove.all] | `remove_all` has incorrect post conditions | Yes | 3 |
2816(i) | C++20 | 29.12.13.34 [fs.op.resize.file] | `resize_file` has impossible postcondition | Yes | 3 |
2673(i) | C++17 | 29.12.13.36 [fs.op.status] | `status()` effects cannot be implemented as specified | Yes | 0 |
2728(i) | C++17 | 29.12.13.36 [fs.op.status] | `status(p).permissions()` and `symlink_status(p).permissions()` are not specified | Yes | 0 |
3026(i) | C++20 | 29.12.13.40 [fs.op.weakly.canonical] | `filesystem::weakly_canonical` still defined in terms of `canonical(p, base)` | Yes | 0 |
984(i) | C++11 | 29.13 [c.files] | Does `<cinttypes>` have macro guards? | Yes |  |
2548(i) | Resolved | 29.13 [c.files] | Missing `vfscanf` from `<cstdio>` | Yes | 3 |
2249(i) | Resolved | 29.13 [c.files] | [CD] Remove `gets` from `<cstdio>` | Yes |  |
2043(i) | NAD | 29.13 [c.files] | `std{in,out,err}` should be usable as field names | Yes |  |

## Section 30 (76 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2490(i) | New | 30 [re] | `<regex>` needs lots of `noexcept` | No | 3 |
523(i) | Open | 30 [re] | regex case-insensitive character ranges are unimplementable as specified | No | 4 |
524(i) | CD1 | 30 [re] | regex named character classes and case-insensitivity don't mix | Yes |  |
1142(i) | NAD Concepts | 30 [re] | Regular expressions library not concept enabled | Yes |  |
3606(i) | New | 30.2 [re.req] | Missing `regex_traits::locale_type` requirements | No | 3 |
2431(i) | New | 30.2 [re.req] | Missing regular expression traits requirements | No | 3 |
2329(i) | C++14 | 30.3 [re.syn] | `regex_match()/regex_search()` with `match_results` should forbid temporary strings | Yes | 2 |
1263(i) | NAD | 30.3 [re.syn] | missing `swap` overloads for `regex` | Yes |  |
2053(i) | C++14 | 30.4 [re.const] | Errors in `regex` bitmask types | Yes |  |
2331(i) | Open | 30.4.2 [re.synopt] | `regex_constants::collate`'s effects are inaccurately summarized | Yes | 3 |
2503(i) | C++17 | 30.4.2 [re.synopt] | multiline option should be added to `syntax_option_type` | Yes | 2 |
2359(i) | C++14 | 30.4.2 [re.synopt] | How does `regex_constants::nosubs` affect `basic_regex::mark_count()`? | Yes | 0 |
2330(i) | C++14 | 30.4.2 [re.synopt] | `regex("meow", regex::icase)` is technically forbidden but should be permitted | Yes | 0 |
3605(i) | New | 30.4.3 [re.matchflag] | `regex_constants::match_prev_avail` is underspecified | No | 3 |
1450(i) | C++14 | 30.4.3 [re.matchflag] | Contradiction in `regex_constants` | Yes | 3 |
2338(i) | Open | 30.6 [re.traits] | §[re.traits]/7 expects of locale facets something not guaranteed by [locale.facet]/4 | Yes | 3 |
2018(i) | C++14 | 30.6 [re.traits] | [CD] `regex_traits::isctype` Returns clause is wrong | Yes |  |
2271(i) | C++14 | 30.6 [re.traits] | `regex_traits::lookup_classname` specification unclear | Yes |  |
1337(i) | C++11 | 30.6 [re.traits] | Swapped arguments in `regex_traits::isctype` | Yes |  |
3261(i) | New | 30.7 [re.regex] | `regex` components' `noexcept` annotations appear broken for POCMA or throwing `BidirectionalIterator` | No | 3 |
3296(i) | C++20 | 30.7 [re.regex] | Inconsistent default argument for `basic_regex<>::assign` | Yes | 0 |
723(i) | C++11 | 30.7 [re.regex] | `basic_regex` should be moveable | Yes |  |
2029(i) | C++11 | 30.7 [re.regex] | Missing '`noexcept`' on `basic_regex` move-assignment operator | Yes |  |
628(i) | CD1 | 30.7 [re.regex] | Inconsistent definition of basic_regex constructor | Yes |  |
1396(i) | NAD | 30.7 [re.regex] | `regex` should support allocators | Yes |  | 1451
1451(i) | Dup | 30.7 [re.regex] | `regex` should support allocators | Yes |  | 1396
3630(i) | New | 30.7.2 [re.regex.construct] | Inconsistent `basic_regex` construction and assignment from iterator range | No | 4 |
3603(i) | New | 30.7.2 [re.regex.construct] | Matching of null characters by regular expressions is underspecified | No | 3 |
3604(i) | New | 30.7.2 [re.regex.construct] | What is the effect of an invalid value of type `syntax_option_type`? | No | 3 |
3341(i) | New | 30.7.2 [re.regex.construct] | `basic_regex` range constructor: Missing requirements for iterator types | No | 3 |
1014(i) | C++11 | 30.7.2 [re.regex.construct] | `basic_regex` should be created/assigned from initializer lists | Yes |  |
682(i) | CD1 | 30.7.2 [re.regex.construct] | basic_regex ctor takes InputIterator or ForwardIterator? | Yes |  |
2137(i) | Open | 30.7.3 [re.regex.assign] | Misleadingly constrained post-condition in the presence of exceptions | Yes | 3 |
2001(i) | C++11 | 30.7.3 [re.regex.assign] | Class template `basic_regex` uses non existent `string_type` | Yes |  |
3126(i) | New | 30.8 [re.submatch] | There's no `std::sub_match::compare(string_view)` overload | Yes | 3 |
3204(i) | New | 30.8 [re.submatch] | `sub_match::swap` only swaps the base class | Yes | 3 |
1180(i) | C++11 | 30.8.2 [re.submatch.members] | Missing `string_type` member typedef in class `sub_match` | Yes |  |
2217(i) | C++17 | 30.8.3 [re.submatch.op] | `operator==(sub_match, string)` slices on embedded `'\0'`s | Yes | 2 |
1181(i) | C++11 | 30.8.3 [re.submatch.op] | Invalid `sub_match` comparison operators | Yes |  |
681(i) | CD1 | 30.8.3 [re.submatch.op] | Operator functions impossible to compare are defined in [re.submatch.op] | Yes |  |
2195(i) | Open | 30.9 [re.results] | Missing constructors for `match_results` | Yes | 3 |
2589(i) | C++17 | 30.9 [re.results] | `match_results` can't satisfy the requirements of a container | Yes | 3 |
2306(i) | C++14 | 30.9 [re.results] | `match_results::reference` should be `value_type&`, not `const value_type&` | Yes | 4 |
645(i) | NAD Editorial | 30.9 [re.results] | Missing members in match_results | Yes |  |
684(i) | NAD Editorial | 30.9 [re.results] | Unclear which members of match_results should be used in comparison | Yes |  |
2191(i) | WP | 30.9.2 [re.results.const] | Incorrect specification of `match_results(match_results&&)` | Yes | 4 |
2183(i) | C++20 | 30.9.2 [re.results.const] | Muddled allocator requirements for `match_results` constructors | Yes | 3 |
2184(i) | C++20 | 30.9.2 [re.results.const] | Muddled allocator requirements for `match_results` assignments | Yes | 3 |
1209(i) | C++11 | 30.9.2 [re.results.const] | `match_results` should be moveable | Yes |  |
1453(i) | Resolved | 30.9.5 [re.results.acc] | Default constructed `match_results` behavior for certain operations | Yes |  |
1452(i) | NAD | 30.9.5 [re.results.acc] | "target sequence" is not defined | Yes |  |
646(i) | CD1 | 30.9.6 [re.results.form] | const incorrect match_result members | Yes |  |
2002(i) | Resolved | 30.9.9 [re.results.nonmember] | Class template `match_results` does not specify the semantics of `operator==` | Yes |  |
2273(i) | C++17 | 30.10.2 [re.alg.match] | `regex_match` ambiguity | Yes | 2 |
2205(i) | C++14 | 30.10.2 [re.alg.match] | Problematic postconditions of `regex_match` and `regex_search` | Yes | 0 |
647(i) | NAD Editorial | 30.10.3 [re.alg.search] | Inconsistent `regex_search` params | Yes |  |
2216(i) | New | 30.10.4 [re.alg.replace] | `regex_replace(basic_string)` allocator handling | No | 3 |
2213(i) | C++14 | 30.10.4 [re.alg.replace] | Return value of `std::regex_replace` | Yes | 0 |
727(i) | C++11 | 30.10.4 [re.alg.replace] | `regex_replace()` doesn't accept `basic_string`s with custom traits and allocators | Yes |  |
726(i) | NAD | 30.10.4 [re.alg.replace] | Missing `regex_replace()` overloads | Yes |  |
2332(i) | C++14 | 30.11 [re.iter] | `regex_iterator/regex_token_iterator` should forbid temporary regexes | Yes | 2 |
652(i) | CD1 | 30.11.1 [re.regiter] | regex_iterator and const correctness | Yes |  |
648(i) | NAD Editorial | 30.11.1.2 [re.regiter.cnstr] | regex_iterator c'tor needs clarification/editorial fix | Yes |  |
909(i) | C++11 | 30.11.2 [re.tokiter] | `regex_token_iterator` should use `initializer_list` | Yes |  |
650(i) | CD1 | 30.11.2 [re.tokiter] | regex_token_iterator and const correctness | Yes |  |
683(i) | NAD Editorial | 30.11.2 [re.tokiter] | regex_token_iterator summary error | Yes |  |
3129(i) | C++20 | 30.11.2.2 [re.tokiter.cnstr] | `regex_token_iterator` constructor uses wrong pointer arithmetic | Yes | 0 |
651(i) | CD1 | 30.11.2.2 [re.tokiter.cnstr] | Missing preconditions for regex_token_iterator c'tors | Yes |  |
649(i) | NAD Editorial | 30.11.2.2 [re.tokiter.cnstr] | Several typos in regex_token_iterator constructors | Yes |  |
2220(i) | Open | 30.11.2.3 [re.tokiter.comp] | Under-specification of `operator==` for `regex_token_iterator` | Yes | 3 |
2986(i) | New | 30.12 [re.grammar] | Handling of multi-character collating elements by the `regex` FSM is underspecified | No | 4 |
2987(i) | New | 30.12 [re.grammar] | Relationship between `traits_inst.lookup_collatename` and the `regex` FSM is underspecified with regards to `ClassAtomCollatingElement` | No | 3 |
2546(i) | New | 30.12 [re.grammar] | Implementability of locale-sensitive UnicodeEscapeSequence matching | No | 4 |
2584(i) | C++17 | 30.12 [re.grammar] | `<regex>` ECMAScript `IdentityEscape` is ambiguous | Yes | 2 |
716(i) | C++11 | 30.12 [re.grammar] | Production in [re.grammar] not actually modified | Yes |  |
2343(i) | Resolved | 30.12 [re.grammar] | Is the value of the ECMA-262 RegExp object's multiline property really false? | Yes | 2 |

## Section 31 (74 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3633(i) | New | 31 [atomics] | Atomics are copy constructible and copy assignable from `volatile` atomics | Yes | 3 |
880(i) | Resolved | 31 [atomics] | Missing atomic exchange parameter | Yes |  | 942
923(i) | Resolved | 31 [atomics] | atomics with floating-point | Yes |  |
924(i) | Resolved | 31 [atomics] | structs with internal padding | Yes |  |
1143(i) | Resolved | 31 [atomics] | Atomic operations library not concept enabled | Yes |  |
1145(i) | Resolved | 31 [atomics] | Inappropriate headers for atomics | Yes |  |
1455(i) | Resolved | 31 [atomics] | C language compatibility for atomics | Yes |  | 1454
1523(i) | Resolved | 31 [atomics] | `noexcept` for Clause 29 | Yes |  |
879(i) | NAD Editorial | 31 [atomics] | Atomic load const qualification | Yes |  |
937(i) | NAD Editorial | 31 [atomics] | Atomics for standard typedef types | Yes |  |
1456(i) | NAD | 31 [atomics] | Missing fixed-size `atomic_` typedefs | Yes |  |
1461(i) | NAD | 31 [atomics] | Rename all `ATOMIC_*` macros as `STD_ATOMIC_*` | Yes |  |
942(i) | Dup | 31 [atomics] | Atomics synopsis typo | Yes |  | 880
1454(i) | Dup | 31 [atomics] | Ensure C compatibility for atomics | Yes |  | 1455
3220(i) | New | 31.2 [atomics.syn] | P0558 broke conforming C++14 uses of atomic `shared_ptr` | Yes | 3 |
2236(i) | SG1 | 31.2 [atomics.syn] | `kill_dependency` unconditionally noexcept | No |  |
2988(i) | C++20 | 31.2 [atomics.syn] | Clause 32 cleanup missed one `typename` | Yes | 0 |
1457(i) | Resolved | 31.2 [atomics.syn] | Splitting lock-free properties | Yes |  |
2037(i) | Resolved | 31.2 [atomics.syn] | `atomic` free functions incorrectly specified | Yes |  |
3268(i) | New | 31.4 [atomics.order] | `memory_order::memory_order_foo` broken in C++20 | Yes | 4 |
2265(i) | Open | 31.4 [atomics.order] | 29.3p9 appears to rule out some acceptable executions | No | 4 |
1459(i) | LEWG | 31.4 [atomics.order] | Overlapping evaluations are allowed | No |  | 1458
2130(i) | C++14 | 31.4 [atomics.order] | Missing ordering constraints | Yes |  |
818(i) | CD1 | 31.4 [atomics.order] | wording for memory ordering | Yes |  |
2034(i) | Resolved | 31.4 [atomics.order] | Initialization of atomics is misspecified so that it doesn't preserve sequential consistency | Yes |  |
926(i) | NAD Editorial | 31.4 [atomics.order] | Sequentially consistent fences, relaxed operations and modification order | Yes |  |
1458(i) | Dup | 31.4 [atomics.order] | Overlapping evaluations are allowed | Yes |  | 1459
3249(i) | WP | 31.5 [atomics.lockfree] | There are no 'pointers' in §[atomics.lockfree] | Yes | 4 |
1146(i) | Resolved | 31.5 [atomics.lockfree] | "lockfree" does not say enough | Yes |  |
1460(i) | Resolved | 31.5 [atomics.lockfree] | Missing lock-free property for type `bool` should be added | Yes |  |
3263(i) | New | 31.6 [atomics.wait] | Atomic waiting function calls should only be unblocked once | Yes | 3 |
3288(i) | New | 31.6 [atomics.wait] | `atomic<T>::notify_one` is unimplementable | Yes | 2 |
3485(i) | SG1 | 31.7 [atomics.ref.generic] | `atomic_ref` safety should be based on operations that "potentially conflict" rather than lifetime | No | 3 |
3160(i) | C++20 | 31.7 [atomics.ref.generic] | `atomic_ref() = delete;` should be deleted | Yes | 0 |
3508(i) | New | 31.7.1 [atomics.ref.generic.general] | `atomic_ref<cv T>` is not well-specified | No | 2 |
3409(i) | New | 31.7.2 [atomics.ref.ops] | Too lax description of `atomic_ref<T>::required_alignment` | Yes | 3 |
3012(i) | C++20 | 31.8 [atomics.types.generic] | `atomic<T>` is unimplementable for non-`is_trivially_copy_constructible T` | Yes | 2 |
2441(i) | C++17 | 31.8 [atomics.types.generic] | Exact-width atomic typedefs should be provided | Yes | 0 |
768(i) | CD1 | 31.8 [atomics.types.generic] | Typos in [atomics]? | Yes |  |
845(i) | CD1 | 31.8 [atomics.types.generic] | atomics cannot support aggregate initialization | Yes |  |
908(i) | Resolved | 31.8 [atomics.types.generic] | Deleted assignment operators for atomic types must be volatile | Yes |  |
2715(i) | Resolved | 31.8 [atomics.types.generic] | What is 'aggregate initialization syntax'? | Yes | 3 |
2424(i) | Resolved | 31.8 [atomics.types.generic] | 29.5 should state that atomic types are not trivially copyable | Yes | 2 |
944(i) | Resolved | 31.8 [atomics.types.generic] | `atomic<bool>` derive from `atomic_bool`? | Yes |  |
1469(i) | Resolved | 31.8 [atomics.types.generic] | `atomic<T*>` inheritance from `atomic_address` breaks type safety | Yes |  |
2024(i) | Resolved | 31.8 [atomics.types.generic] | Inconsistent implementation requirements for `atomic<integral>` and `atomic<T*>` | Yes |  |
2165(i) | Resolved | 31.8 [atomics.types.generic] | `std::atomic<X>` requires `X` to be nothrow default constructible | Yes | 4 |
3611(i) | SG1 | 31.8.2 [atomics.types.operations] | Should `compare_exchange` be allowed to modify the `expected` value on success? | No | 2 |
3417(i) | SG1 | 31.8.2 [atomics.types.operations] | Missing `volatile` atomic deprecations | Yes | 3 |
2426(i) | C++17 | 31.8.2 [atomics.types.operations] | Issue about `compare_exchange` | Yes | 1 |
1474(i) | C++11 | 31.8.2 [atomics.types.operations] | weak compare-and-exchange confusion | Yes |  | 1470, 1475, 1476, 1477
1478(i) | C++11 | 31.8.2 [atomics.types.operations] | Clarify race conditions in atomics initialization | Yes |  |
777(i) | CD1 | 31.8.2 [atomics.types.operations] | Atomics Library Issue | Yes |  |
846(i) | CD1 | 31.8.2 [atomics.types.operations] | No definition for constructor | Yes |  |
2334(i) | Resolved | 31.8.2 [atomics.types.operations] | `atomic`'s default constructor requires "uninitialized" state even for types with non-trivial default-constructor | Yes |  |
1043(i) | Resolved | 31.8.2 [atomics.types.operations] | Clarify that `compare_exchange` is not a read-modify-write operation | Yes |  |
1147(i) | Resolved | 31.8.2 [atomics.types.operations] | Non-volatile atomic functions | Yes |  |
864(i) | NAD Editorial | 31.8.2 [atomics.types.operations] | Defect in atomic wording | Yes |  |
1471(i) | NAD Editorial | 31.8.2 [atomics.types.operations] | Default constructor of atomics needs specification | Yes |  |
1472(i) | NAD Editorial | 31.8.2 [atomics.types.operations] | Incorrect semantics of `atomic_init` | Yes |  |
1473(i) | NAD | 31.8.2 [atomics.types.operations] | Incomplete memory order specifications | Yes |  |
1470(i) | Dup | 31.8.2 [atomics.types.operations] | "Same-ness" curiosities | Yes |  | 1474
1475(i) | Dup | 31.8.2 [atomics.types.operations] | weak compare-and-exchange confusion II | Yes |  | 1474
1476(i) | Dup | 31.8.2 [atomics.types.operations] | Meaningless specification of spurious failure | Yes |  | 1474
1477(i) | Dup | 31.8.2 [atomics.types.operations] | weak compare-and-exchange confusion III | Yes |  | 1474
3047(i) | New | 31.8.3 [atomics.types.int] | `atomic` compound assignment operators can cause undefined behavior when corresponding `fetch_meow` members don't | Yes | 3 |
3045(i) | C++20 | 31.8.4 [atomics.types.float] | `atomic<floating-point>` doesn't have `value_type` or `difference_type` | Yes | 0 |
3661(i) | WP | 31.8.7.2 [util.smartptr.atomic.shared] | `constinit atomic<shared_ptr<T>> a(nullptr);` should work | Yes |  |
3418(i) | New | 31.9 [atomics.nonmembers] | Deprecated free functions in `<atomic>` | Yes | 3 |
2138(i) | C++14 | 31.10 [atomics.flag] | `atomic_flag::clear` should not accept `memory_order_consume` | Yes |  |
2159(i) | C++14 | 31.10 [atomics.flag] | `atomic_flag` initialization | Yes |  |
1479(i) | C++11 | 31.11 [atomics.fences] | Fence functions should be `extern "C"` | Yes |  |
1480(i) | C++11 | 31.11 [atomics.fences] | Atomic fences don't have synchronizes with relation | Yes |  |
3671(i) | Tentatively Ready | 31.12 [stdatomic.h.syn] | `atomic_fetch_xor` missing from `stdatomic.h` | Yes |  |

## Section 32 (183 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
1089(i) | C++11 | 32 [thread] | Unify "Throws: Nothing." specifications | Yes |  |
1442(i) | NAD Editorial | 32 [thread] | "happens-before" should be "synchronizes-with" | Yes |  | 1443
1443(i) | Dup | 32 [thread] | Imposed happens-before edges are not made transitive | Yes |  | 1442
1139(i) | NAD Concepts | 32 [thread] | Thread support library not concept enabled | Yes |  |
1481(i) | Resolved | 32.2 [thread.req] | Missing Lockable requirements | Yes |  |
1108(i) | C++11 | 32.2.2 [thread.req.exception] | thread.req.exception overly constrains implementations | Yes |  |
2379(i) | NAD | 32.2.3 [thread.req.native] | Obtaining native handle of the current thread | Yes |  |
2941(i) | C++20 | 32.2.4 [thread.req.timing] | §[thread.req.timing] wording should apply to both member and namespace-level functions | Yes | 0 |
1158(i) | C++11 | 32.2.4 [thread.req.timing] | Encouragement to use monotonic clock | Yes |  |
1482(i) | Resolved | 32.2.4 [thread.req.timing] | Timeout operations are under-specified | Yes |  |
2819(i) | New | 32.2.5 [thread.req.lockable] | Unspecified Return type: elements | Yes | 3 |
3499(i) | New | 32.2.5.4 [thread.req.lockable.timed] | Timed lockable and mutex requirements are imprecise about `duration` and `time_point` | No | 3 |
3254(i) | C++20 | 32.3.3 [stoptoken] | Strike `stop_token`'s `operator!=` | Yes | 0 |
3362(i) | C++20 | 32.3.4 [stopsource] | Strike `stop_source`'s `operator!=` | Yes | 0 |
1483(i) | NAD Editorial | 32.4 [thread.threads] | `__STDCPP_THREADS spelling` | Yes |  |
1484(i) | LEWG | 32.4.3 [thread.thread.class] | Need a way to join a thread with a timeout | No |  |
3516(i) | New | 32.4.3.2 [thread.thread.id] | `thread::id` spaceship may be inconsistent with equality | Yes | 3 |
1277(i) | C++11 | 32.4.3.2 [thread.thread.id] | `std::thread::id` should be trivially copyable | Yes |  |
783(i) | CD1 | 32.4.3.2 [thread.thread.id] | `thread::id` reuse | Yes |  |
889(i) | Resolved | 32.4.3.2 [thread.thread.id] | `thread::id` comparisons | Yes |  |
1485(i) | NAD | 32.4.3.2 [thread.thread.id] | Unclear `thread::id` specification | Yes |  |
3475(i) | New | 32.4.3.3 [thread.thread.constr] | `std::thread`'s constructor needs to be able to report general memory allocation failures | Yes | 3 |
3476(i) | WP | 32.4.3.3 [thread.thread.constr] | `thread` and `jthread` constructors require that the parameters be move-constructible but never move construct the parameters | Yes | 0 |
3039(i) | C++20 | 32.4.3.3 [thread.thread.constr] | Unnecessary `decay` in `thread` and `packaged_task` | Yes | 0 |
891(i) | C++11 | 32.4.3.3 [thread.thread.constr] | `std::thread`, `std::call_once` issue | Yes |  |
929(i) | C++11 | 32.4.3.3 [thread.thread.constr] | Thread constructor | Yes |  |
967(i) | C++11 | 32.4.3.3 [thread.thread.constr] | Various threading bugs #17 | Yes |  |
1176(i) | NAD | 32.4.3.3 [thread.thread.constr] | Make `thread` constructor non-variadic | Yes |  |
963(i) | C++11 | 32.4.3.6 [thread.thread.member] | Various threading bugs #13 | Yes |  |
1033(i) | C++11 | 32.4.3.6 [thread.thread.member] | `thread::join()` effects? | Yes |  |
888(i) | C++11 | 32.4.5 [thread.thread.this] | `this_thread::yield` too strong | Yes |  |
1487(i) | C++11 | 32.4.5 [thread.thread.this] | Clock related operations exception specifications conflict | Yes |  |
1486(i) | NAD | 32.4.5 [thread.thread.this] | Value of `this_thread::get_id()` underspecified for detached thread | Yes |  |
1488(i) | LEWG | 32.5 [thread.mutex] | Improve interoperability between the C++0x and C1x threads APIs | No |  |
1044(i) | C++11 | 32.5 [thread.mutex] | Empty tag types should be `constexpr` literals | Yes |  |
1268(i) | Resolved | 32.5 [thread.mutex] | The Mutex requirements in 30.4.1 and 30.4.2 are wrong | Yes |  |
1489(i) | NAD Editorial | 32.5 [thread.mutex] | `unlock` functions and unlock mutex requirements are inconsistent | Yes |  |
936(i) | LEWG | 32.5.4 [thread.mutex.requirements] | Mutex type overspecified | No |  | 961
961(i) | LEWG | 32.5.4 [thread.mutex.requirements] | Various threading bugs #11 | No |  | 936
1493(i) | LEWG | 32.5.4 [thread.mutex.requirements] | Add `mutex`, `recursive_mutex`, `is_locked` function | No |  |
2126(i) | Pending NAD Editorial | 32.5.4 [thread.mutex.requirements] | Several specification problems in regard to mutex requirements | Yes |  |
960(i) | C++11 | 32.5.4 [thread.mutex.requirements] | Various threading bugs #10 | Yes |  |
968(i) | C++11 | 32.5.4 [thread.mutex.requirements] | Various threading bugs #18 | Yes |  |
1218(i) | C++11 | 32.5.4 [thread.mutex.requirements] | mutex destructor synchronization | Yes |  |
1490(i) | Resolved | 32.5.4 [thread.mutex.requirements] | Mutex requirements too stringent | Yes |  |
1491(i) | Resolved | 32.5.4 [thread.mutex.requirements] | `try_lock` does not guarantee forward progress | Yes |  |
1492(i) | Resolved | 32.5.4 [thread.mutex.requirements] | Mutex requirements should not be bound to threads | Yes |  |
980(i) | NAD | 32.5.4 [thread.mutex.requirements] | `mutex lock()` missing error conditions | Yes |  |
2134(i) | Pending NAD Editorial | 32.5.4.2 [thread.mutex.requirements.mutex] | Redundant Mutex requirement? | Yes |  |
2309(i) | C++17 | 32.5.4.2 [thread.mutex.requirements.mutex] | `mutex::lock()` should not throw `device_or_resource_busy` | Yes | 0 |
2090(i) | NAD | 32.5.4.2 [thread.mutex.requirements.mutex] | Minor Overconstraint in Mutex Types | Yes |  |
893(i) | C++11 | 32.5.4.2.2 [thread.mutex.class] | `std::mutex` issue | Yes |  | 905
828(i) | Resolved | 32.5.4.2.2 [thread.mutex.class] | Static initialization for `std::mutex`? | Yes |  |
905(i) | Dup | 32.5.4.2.2 [thread.mutex.class] | Mutex specification questions | Yes |  | 893
2125(i) | Pending NAD Editorial | 32.5.4.3 [thread.timedmutex.requirements] | `TimedMutex` specification problem | Yes |  |
2091(i) | C++14 | 32.5.4.3 [thread.timedmutex.requirements] | Misplaced effect in `m.try_lock_for()` | Yes |  |
2288(i) | C++14 | 32.5.4.4 [thread.sharedmutex.requirements] | Inconsistent requirements for shared mutexes | Yes |  |
2363(i) | Resolved | 32.5.4.5.2 [thread.sharedtimedmutex.class] | Defect in 30.4.1.4.1 [thread.sharedtimedmutex.class] | Yes | 2 |
2731(i) | WP | 32.5.5.2 [thread.lock.guard] | Existence of `lock_guard<MutexTypes...>::mutex_type` typedef unclear | Yes | 3 |
2887(i) | Resolved | 32.5.5.2 [thread.lock.guard] | Revert the changes from P0156R0: variadic `lock_guard` | Yes |  |
2023(i) | Resolved | 32.5.5.2 [thread.lock.guard] | Incorrect requirements for `lock_guard` and `unique_lock` | Yes |  |
2104(i) | C++14 | 32.5.5.4 [thread.lock.unique] | `unique_lock` move-assignment should not be `noexcept` | Yes |  |
2577(i) | C++17 | 32.5.5.4.2 [thread.lock.unique.cons] | `{shared,unique}_lock` should use `std::addressof` | Yes | 0 |
1045(i) | C++11 | 32.5.5.4.2 [thread.lock.unique.cons] | Remove unnecessary preconditions from `unique_lock` constructor | Yes |  |
962(i) | C++11 | 32.5.5.4.3 [thread.lock.unique.locking] | Various threading bugs #12 | Yes |  |
1159(i) | C++11 | 32.5.5.4.3 [thread.lock.unique.locking] | Unclear spec for `resource_deadlock_would_occur` | Yes |  | 1219
1219(i) | Dup | 32.5.5.4.3 [thread.lock.unique.locking] | unique_lock::lock and resource_deadlock_would_occur | Yes |  | 1159
784(i) | NAD | 32.5.5.4.4 [thread.lock.unique.mod] | unique_lock::release | Yes |  |
3030(i) | C++20 | 32.5.6 [thread.lock.algorithm] | Who shall meet the requirements of `try_lock`? | Yes | 0 |
986(i) | C++11 | 32.5.6 [thread.lock.algorithm] | Generic `try_lock` contradiction | Yes |  |
2080(i) | C++14 | 32.5.7 [thread.once] | Specify when `once_flag` becomes invalid | Yes |  |
2442(i) | C++17 | 32.5.7.2 [thread.once.callonce] | `call_once()` shouldn't `DECAY_COPY()` | Yes |  |
1494(i) | C++11 | 32.5.7.2 [thread.once.callonce] | Term "are serialized" not defined | Yes |  |
2140(i) | C++14 | 32.6 [thread.condition] | Meaning of `notify_all_at_thread_exit` synchronization requirement? | Yes |  |
2190(i) | C++14 | 32.6 [thread.condition] | Condition variable specification | Yes |  |
859(i) | C++11 | 32.6 [thread.condition] | Monotonic Clock is Conditionally Supported? | Yes |  |
1220(i) | C++11 | 32.6 [thread.condition] | What does `condition_variable` wait on? | Yes |  |
1222(i) | C++11 | 32.6 [thread.condition] | condition_variable incorrect effects for exception safety | Yes |  |
1497(i) | C++11 | 32.6 [thread.condition] | `lock()` postcondition can not be generally achieved | Yes |  |
1498(i) | Resolved | 32.6 [thread.condition] | Unclear specification for [thread.condition] | Yes |  |
1495(i) | NAD Editorial | 32.6 [thread.condition] | Condition variable `wait_for` return value insufficient | Yes |  |
1499(i) | NAD | 32.6 [thread.condition] | Condition variables preclude wakeup optimization | Yes |  |
3343(i) | New | 32.6.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(i) | New | 32.6.4 [thread.condition.condvar] | `condition_variable::wait_for` is overspecified | No | 3 |
2093(i) | C++14 | 32.6.4 [thread.condition.condvar] | Throws clause of `condition_variable::wait` with predicate | Yes |  |
2135(i) | C++14 | 32.6.4 [thread.condition.condvar] | Unclear requirement for exceptions thrown in `condition_variable::wait()` | Yes |  |
857(i) | C++11 | 32.6.4 [thread.condition.condvar] | `condition_variable::time_wait` return `bool` error prone | Yes |  |
965(i) | C++11 | 32.6.4 [thread.condition.condvar] | Various threading bugs #15 | Yes |  |
1221(i) | C++11 | 32.6.4 [thread.condition.condvar] | `condition_variable` wording | Yes |  |
958(i) | Resolved | 32.6.4 [thread.condition.condvar] | Various threading bugs #8 | Yes |  |
966(i) | Resolved | 32.6.4 [thread.condition.condvar] | Various threading bugs #16 | Yes |  |
2240(i) | Resolved | 32.6.4 [thread.condition.condvar] | Probable misuse of term "function scope" in [thread.condition] | Yes |  |
1496(i) | NAD Editorial | 32.6.4 [thread.condition.condvar] | `condition_variable` not implementable | Yes |  |
887(i) | NAD | 32.6.4 [thread.condition.condvar] | issue with condition::wait_... | Yes |  |
959(i) | NAD | 32.6.4 [thread.condition.condvar] | Various threading bugs #9 | Yes |  |
3425(i) | WP | 32.6.5 [thread.condition.condvarany] | `condition_variable_any` fails to constrain its `Lock` parameters | Yes | 0 |
2092(i) | C++14 | 32.6.5 [thread.condition.condvarany] | Vague Wording for `condition_variable_any` | Yes |  |
1267(i) | C++11 | 32.6.5 [thread.condition.condvarany] | Incorrect wording for `condition_variable_any::wait_for` | Yes |  |
964(i) | Resolved | 32.6.5 [thread.condition.condvarany] | Various threading bugs #14 | Yes |  |
1500(i) | NAD Editorial | 32.6.5 [thread.condition.condvarany] | Consider removal of `native_handle()` | Yes |  |
1223(i) | NAD | 32.6.5 [thread.condition.condvarany] | condition_variable_any lock matching? | Yes |  |
1224(i) | NAD | 32.6.5 [thread.condition.condvarany] | condition_variable_any support for recursive mutexes? | Yes |  |
2276(i) | C++17 | 32.9 [futures] | Missing requirement on `std::promise::set_exception` | Yes |  |
1518(i) | C++11 | 32.9 [futures] | Waiting for deferred functions | Yes |  |
1046(i) | Resolved | 32.9 [futures] | Provide simple facility to start asynchronous operations | Yes |  |
1244(i) | Resolved | 32.9 [futures] | `wait_*()` in `*future` for synchronous functions | Yes |  |
1275(i) | Resolved | 32.9 [futures] | Creating and setting futures | Yes |  |
1501(i) | Resolved | 32.9 [futures] | Specification for managing associated asynchronous state has problems | Yes |  |
1513(i) | Resolved | 32.9 [futures] | 'launch' enum too restrictive | Yes |  |
2056(i) | C++14 | 32.9.1 [futures.overview] | `future_errc` enums start with value 0 (invalid value for `broken_promise`) | Yes |  |
2102(i) | C++14 | 32.9.1 [futures.overview] | Why is `std::launch` an implementation-defined type? | Yes |  |
1226(i) | Resolved | 32.9.3 [futures.errors] | Incomplete changes of #890 | Yes |  |
1160(i) | Resolved | 32.9.4 [futures.future.error] | `future_error` public constructor is 'exposition only' | Yes |  |
2530(i) | Open | 32.9.5 [futures.state] | Clarify observable side effects of releasing a shared state | No | 3 |
1269(i) | Resolved | 32.9.5 [futures.state] | Associated state doesn't account for `async` | Yes |  |
1502(i) | Resolved | 32.9.5 [futures.state] | Specification of [futures.state] unclear | Yes |  |
1503(i) | NAD Editorial | 32.9.5 [futures.state] | "associated asynchronous state" must go | Yes |  |
3003(i) | Open | 32.9.6 [futures.promise] | `<future>` still has type-erased allocators in `promise` | Yes | 2 |
2532(i) | Open | 32.9.6 [futures.promise] | Satisfying a `promise` at thread exit | Yes | 3 |
2095(i) | LEWG | 32.9.6 [futures.promise] | `promise` and `packaged_task` missing constructors needed for uses-allocator construction | Yes | 4 |
3466(i) | WP | 32.9.6 [futures.promise] | Specify the requirements for `promise`/`future`/`shared_future` consistently | Yes | 3 |
2412(i) | C++20 | 32.9.6 [futures.promise] | `promise::set_value()` and `promise::get_future()` should not race | Yes | 3 |
2523(i) | C++17 | 32.9.6 [futures.promise] | `std::promise` synopsis shows two `set_value_at_thread_exit()`'s for no apparent reason | Yes | 0 |
2098(i) | C++14 | 32.9.6 [futures.promise] | Minor Inconsistency between `promise::set_value` and `promise::set_value_at_thread_exit` | Yes |  |
1049(i) | Resolved | 32.9.6 [futures.promise] | Move assignment of `promise` inverted | Yes |  |
1050(i) | Resolved | 32.9.6 [futures.promise] | Clarify postconditions for `get_future()` | Yes |  |
1088(i) | Resolved | 32.9.6 [futures.promise] | `std::promise` should provide non-member `swap` overload | Yes |  |
1165(i) | Resolved | 32.9.6 [futures.promise] | Unneeded `promise` move constructor | Yes |  |
1272(i) | Resolved | 32.9.6 [futures.promise] | confusing declarations of `promise::set_value` | Yes |  |
1291(i) | Resolved | 32.9.6 [futures.promise] | Exceptions thrown during `promise::set_value` | Yes |  |
1300(i) | Resolved | 32.9.6 [futures.promise] | Circular definition of `promise::swap` | Yes |  |
1504(i) | Resolved | 32.9.6 [futures.promise] | Term "are serialized" is not defined | Yes |  |
1505(i) | Resolved | 32.9.6 [futures.promise] | Synchronization between `promise::set_value` and `future::get` | Yes |  |
1507(i) | Resolved | 32.9.6 [futures.promise] | `promise::XXX_at_thread_exit` functions have no synchronization requirements | Yes |  |
1506(i) | NAD Editorial | 32.9.6 [futures.promise] | `set_exception` with a null pointer | Yes |  |
1164(i) | NAD | 32.9.6 [futures.promise] | `promise::swap` should pass by rvalue reference | Yes |  |
2531(i) | C++17 | 32.9.7 [futures.unique.future] | `future::get` should explicitly state that the shared state is released | Yes | 3 |
2556(i) | C++17 | 32.9.7 [futures.unique.future] | Wide contract for `future::share()` | Yes | 3 |
2096(i) | C++14 | 32.9.7 [futures.unique.future] | Incorrect constraints of `future::get` in regard to `MoveAssignable` | Yes |  |
2185(i) | C++14 | 32.9.7 [futures.unique.future] | Missing throws clause for `future/shared_future::wait_for/wait_until` | Yes |  |
2031(i) | C++11 | 32.9.7 [futures.unique.future] | `std::future<>::share()` only applies to rvalues | Yes |  |
1047(i) | Resolved | 32.9.7 [futures.unique.future] | Ensure that future's `get()` blocks when not ready | Yes |  |
1048(i) | Resolved | 32.9.7 [futures.unique.future] | Provide empty-state inspection for `std::unique_future` | Yes |  |
1161(i) | Resolved | 32.9.7 [futures.unique.future] | Unnecessary `unique_future` limitations | Yes |  |
1273(i) | Resolved | 32.9.7 [futures.unique.future] | `future::valid` should be callable on an invalid future | Yes |  |
3458(i) | Resolved | 32.9.7 [futures.unique.future] | Is `shared_future` intended to work with arrays or function types? | Yes | 0 |
1106(i) | Resolved | 32.9.8 [futures.shared.future] | Multiple exceptions from connected `shared_future::get()`? | Yes |  |
1162(i) | Resolved | 32.9.8 [futures.shared.future] | `shared_future` should support an efficient move constructor | Yes |  |
1163(i) | Resolved | 32.9.8 [futures.shared.future] | `shared_future` is inconsistent with `shared_ptr` | Yes |  |
1266(i) | Resolved | 32.9.8 [futures.shared.future] | `shared_future::get` and deferred `async` functions | Yes |  |
1304(i) | Resolved | 32.9.8 [futures.shared.future] | Missing preconditions for `shared_future` | Yes |  |
2799(i) | Resolved | 32.9.8 [futures.shared.future] | `noexcept`-specifications in `shared_future` | Yes | 2 |
2920(i) | Resolved | 32.9.8 [futures.shared.future] | Add a deduction guide for creating a `shared_future` from a `future` rvalue | Yes |  |
1107(i) | NAD Editorial | 32.9.8 [futures.shared.future] | constructor `shared_future(unique_future)` by value? | Yes |  |
2046(i) | NAD | 32.9.8 [futures.shared.future] | `shared_future(future<R>&&)` should be allowed to throw | Yes |  |
3582(i) | New | 32.9.9 [futures.async] | Unclear where `std::async` exceptions are handled | Yes | 3 |
2202(i) | Deferred | 32.9.9 [futures.async] | Missing allocator support by `async` | No | 4 |
2752(i) | C++17 | 32.9.9 [futures.async] | "Throws:" clauses of `async` and `packaged_task` are unimplementable | Yes | 3 |
2186(i) | C++14 | 32.9.9 [futures.async] | Incomplete action on `async/launch::deferred` | Yes |  |
2078(i) | C++14 | 32.9.9 [futures.async] | Throw specification of `async()` incomplete | Yes |  |
2100(i) | C++14 | 32.9.9 [futures.async] | timed waiting functions cannot timeout if `launch::async` policy used | Yes |  |
2120(i) | C++14 | 32.9.9 [futures.async] | What should `async` do if neither '`async`' nor '`deferred`' is set in policy? | Yes |  |
2032(i) | C++11 | 32.9.9 [futures.async] | Incorrect synchronization clause of `async` function | Yes |  |
2856(i) | Resolved | 32.9.9 [futures.async] | `std::async` should be marked as `[[nodiscard]]` | Yes | 2 |
1315(i) | NAD Editorial | 32.9.9 [futures.async] | return type of `async` | Yes |  |
1512(i) | NAD Editorial | 32.9.9 [futures.async] | Conflict in specification: block or join? | Yes |  |
3117(i) | WP | 32.9.10 [futures.task] | Missing `packaged_task` deduction guides | Yes | 3 |
2976(i) | C++20 | 32.9.10 [futures.task] | Dangling `uses_allocator` specialization for `packaged_task` | Yes | 3 |
2921(i) | C++17 | 32.9.10 [futures.task] | `packaged_task` and type-erased allocators | Yes |  |
2067(i) | C++14 | 32.9.10 [futures.task] | `packaged_task` should have deleted copy c'tor with const parameter | Yes |  |
2030(i) | C++11 | 32.9.10 [futures.task] | `packaged_task::result_type` should be removed | Yes |  |
1090(i) | Resolved | 32.9.10 [futures.task] | Missing description of `packaged_task` member `swap`, missing non-member `swap` | Yes |  |
1508(i) | Resolved | 32.9.10 [futures.task] | Rename `packaged_task::operator bool()` | Yes |  |
2407(i) | C++17 | 32.9.10.2 [futures.task.members] | `packaged_task(allocator_arg_t, const Allocator&, F&&)` should neither be constrained nor `explicit` | Yes |  |
2097(i) | C++14 | 32.9.10.2 [futures.task.members] | `packaged_task` constructors should be constrained | Yes |  |
2142(i) | C++14 | 32.9.10.2 [futures.task.members] | `packaged_task::operator()` synchronization too broad? | Yes |  |
1514(i) | C++11 | 32.9.10.2 [futures.task.members] | `packaged_task` constructors need review | Yes |  |
2008(i) | C++11 | 32.9.10.2 [futures.task.members] | Conflicting Error Conditions for `packaged_task::operator()` | Yes |  |
2027(i) | C++11 | 32.9.10.2 [futures.task.members] | Initialization of the stored task of a `packaged_task` | Yes |  |
2245(i) | Resolved | 32.9.10.2 [futures.task.members] | `packaged_task::reset()` memory allocation | Yes | 3 |
1515(i) | Resolved | 32.9.10.2 [futures.task.members] | `packaged_task::make_ready_at_thread_exit` has no synchronization requirements | Yes |  |
2025(i) | Resolved | 32.9.10.2 [futures.task.members] | Incorrect semantics of move assignment operator of `packaged_task` | Yes |  |
2000(i) | C++11 | 32.9.10.3 [futures.task.nonmembers] | Missing definition of `packaged_task` specialization of `uses_allocator` | Yes |  |

## Section 99 (116 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
927(i) | NAD Concepts | 99 [allocator.concepts] | `Dereferenceable` should be `HasDereference` | Yes |  |
1172(i) | Resolved | 99 [allocator.concepts.members] | `select_on_container_(copy|move)_construction` over-constrained | Yes |  |
1074(i) | NAD Concepts | 99 [allocator.element.concepts] | concept map broken by N2840 | Yes |  |
1166(i) | Resolved | 99 [allocator.propagation] | Allocator-specific move/copy break model of move-constructor and move-assignment | Yes |  |
943(i) | C++11 | 99 [atomics.types.address] | `ssize_t` undefined | Yes |  |
1465(i) | Resolved | 99 [atomics.types.address] | Missing arithmetic operators for `atomic_address` | Yes |  |
1466(i) | Resolved | 99 [atomics.types.address] | Silent `const` breakage by `compare_exchange_*` member functions | Yes |  |
1467(i) | Resolved | 99 [atomics.types.address] | Deriving `atomic<T*>` from `atomic_address` breaks type safety | Yes |  |
1468(i) | Resolved | 99 [atomics.types.address] | `atomic_address::compare_exchange_*` member functions should match `atomic_compare_exchange_*` free functions | Yes |  |
1462(i) | Resolved | 99 [atomics.types.integral] | Ambiguous value assignment to `atomic_bool` | Yes |  | 1463
1464(i) | Resolved | 99 [atomics.types.integral] | Underspecified typedefs for atomic integral types | Yes |  |
1463(i) | Dup | 99 [atomics.types.integral] | Inconsistent value assignment for `atomic_bool` | Yes |  | 1462
1247(i) | C++11 | 99 [auto.ptr] | `auto_ptr` is overspecified | Yes |  |
127(i) | TC1 | 99 [auto.ptr] | auto_ptr<> conversion issues | Yes |  |
973(i) | NAD Editorial | 99 [auto.ptr] | auto_ptr characteristics | Yes |  |
249(i) | NAD | 99 [auto.ptr] | Return Type of `auto_ptr::operator=` | Yes |  |
463(i) | NAD | 99 [auto.ptr] | `auto_ptr` usability issues | Yes |  |
2505(i) | Resolved | 99 [auto.ptr.conv] | `auto_ptr_ref` creation requirements underspecified | Yes | 4 |
2(i) | NAD | 99 [auto.ptr.conv] | Auto_ptr conversions effects incorrect | Yes |  |
1080(i) | NAD Concepts | 99 [concept.arithmetic] | Concept ArithmeticLike should provide explicit boolean conversion | Yes |  |
988(i) | NAD | 99 [concept.comparison] | `Reflexivity` meaningless? | Yes |  |
1016(i) | NAD Concepts | 99 [concept.comparison] | Provide `LessThanComparable` and `EqualityComparable` for `FloatingPointType` | Yes |  |
1017(i) | NAD Concepts | 99 [concept.regular] | Floating-point types should not satisfy `Regular` | Yes |  |
1015(i) | NAD Concepts | 99 [concept.transform] | C++ programs - but not users - need to provide support `concept_map`s | Yes |  |
1124(i) | NAD Concepts | 99 [concept.transform] | Invalid definition of concept RvalueOf | Yes |  |
3395(i) | C++20 | 99 [defns.comparison] | Definition for three-way comparison needs to be updated (US 152) | Yes | 1 |
1355(i) | Resolved | 99 [defns.move.assign.op] | The definition of move-assignment operator is redundant | Yes |  |
1356(i) | Resolved | 99 [defns.move.ctor] | The definition of move-constructor is redundant | Yes |  |
2890(i) | C++17 | 99 [defns.obj.state] | The definition of 'object state' applies only to class types | Yes |  |
1064(i) | NAD | 99 [defns.obj.state] | Term "object state" should not refer to classes | Yes |  |
1516(i) | C++11 | 99 [depr.auto.ptr] | No specification for which header contains `auto_ptr` | Yes |  |
1279(i) | C++11 | 99 [depr.base] | forbid `[u|bi]nary_function` specialization | Yes |  |
257(i) | NAD | 99 [depr.base] | STL functional object and iterator inheritance. | Yes |  |
480(i) | NAD | 99 [depr.base] | unary_function and binary_function should have protected nonvirtual destructors | Yes |  |
501(i) | NAD | 99 [depr.base] | Proposal: strengthen guarantees of lib.comparisons | Yes |  |
2835(i) | C++17 | 99 [depr.c.headers] | LWG 2536 seems to misspecify `<tgmath.h>` | Yes | 0 |
2536(i) | C++17 | 99 [depr.c.headers] | What should `<complex.h>` do? | Yes | 2 |
551(i) | CD1 | 99 [depr.c.headers] | <ccomplex> | Yes |  |
143(i) | NAD | 99 [depr.c.headers] | C .h header wording unclear | Yes |  |
3484(i) | New | 99 [depr.c.headers.other] | Should `<stddef.h>` declare `::nullptr_t`? | Yes | 3 |
174(i) | TC1 | 99 [depr.ios.members] | Typo: `OFF_T` vs. `POS_T` | Yes |  |
175(i) | TC1 | 99 [depr.ios.members] | Ambiguity for `basic_streambuf::pubseekpos()` and a few other functions. | Yes |  |
176(i) | TC1 | 99 [depr.ios.members] | `exceptions()` in `ios_base`...? | Yes |  |
2438(i) | C++17 | 99 [depr.iterator.basic] | `std::iterator` inheritance shouldn't be mandated | Yes | 3 |
109(i) | CD1 | 99 [depr.lib.binders] | Missing binders for non-const sequence elements | Yes |  |
362(i) | CD1 | 99 [depr.lib.binders] | bind1st/bind2nd type safety | Yes |  |
798(i) | CD1 | 99 [depr.lib.binders] | Refactoring of binders lead to interface breakage | Yes |  |
1076(i) | NAD Concepts | 99 [depr.negators] | unary/binary_negate need constraining and move support | Yes |  |
2127(i) | C++17 | 99 [depr.storage.iterator] | Move-construction with `raw_storage_iterator` | Yes | 3 |
2454(i) | C++17 | 99 [depr.storage.iterator] | Add `raw_storage_iterator::base()` member | Yes | 0 |
1028(i) | NAD Concepts | 99 [depr.storage.iterator] | `raw_storage_iterator` needs to be a concept-constrained template | Yes |  |
2072(i) | C++17 | 99 [depr.temporary.buffer] | Unclear wording about capacity of temporary buffers | Yes | 3 |
425(i) | CD1 | 99 [depr.temporary.buffer] | return value of std::get_temporary_buffer | Yes |  |
1368(i) | C++11 | 99 [depr.uncaught] | Thread safety of `std::uncaught_exception()` | Yes |  |
1367(i) | C++11 | 99 [exception.unexpected] | Deprecate library support for checking dynamic exception specifications | Yes |  |
40(i) | TC1 | 99 [facets.examples] | Meaningless normative paragraph in examples | Yes |  |
148(i) | TC1 | 99 [facets.examples] | Functions in the example facet BoolNames should be const | Yes |  |
217(i) | TC1 | 99 [facets.examples] | Facets example (Classifying Japanese characters) contains errors | Yes |  |
878(i) | C++11 | 99 [forwardlist] | `forward_list` preconditions | Yes |  |
1276(i) | C++11 | 99 [forwardlist] | `forwardlist` missing allocator constructors | Yes |  |
1419(i) | NAD Editorial | 99 [forwardlist] | `forward_list::erase_after` should return an iterator | Yes |  |
2042(i) | C++11 | 99 [forwardlist.iter] | Comparing `forward_list::before_begin()` to `forward_list::end()` | Yes |  |
2585(i) | C++17 | 99 [forwardlist.modifiers] | `forward_list::resize(size_type, const value_type&)` effects incorrect | Yes | 0 |
1278(i) | C++11 | 99 [forwardlist.modifiers] | Inconsistent return values for `forward_list::insert_after` | Yes |  |
1340(i) | C++11 | 99 [forwardlist.modifiers] | Why does `forward_list::resize` take the object to be copied by value? | Yes |  |
897(i) | Resolved | 99 [forwardlist.modifiers] | Forward_list issues... Part 2 | Yes |  |
3017(i) | C++20 | 99 [forwardlist.ops] | `list splice` functions should use `addressof` | Yes | 0 |
2045(i) | C++14 | 99 [forwardlist.ops] | `forward_list::merge` and `forward_list::splice_after` with unequal allocators | Yes |  |
2123(i) | C++14 | 99 [forwardlist.ops] | `merge()` allocator requirements for lists versus forward lists | Yes |  |
2222(i) | C++14 | 99 [forwardlist.ops] | Inconsistency in description of `forward_list::splice_after` single-element overload | Yes |  |
898(i) | C++11 | 99 [forwardlist.ops] | Small contradiction in n2723 to forward to committee | Yes |  |
1133(i) | C++11 | 99 [forwardlist.ops] | Does N2844 break current specification of list::splice? | Yes |  |
1310(i) | C++11 | 99 [forwardlist.ops] | `forward_list splice_after` from lvalues | Yes |  |
892(i) | NAD Editorial | 99 [forwardlist.ops] | Forward_list issues... | Yes |  |
919(i) | NAD | 99 [forwardlist.ops] | (`forward_`)`list` specialized remove algorithms are over constrained | Yes |  |
2670(i) | C++17 | 99 [fs.op.system_complete] | `system_complete` refers to undefined variable 'base' | Yes | 0 |
2863(i) | Resolved | 99 [func.default.traits] | Undo `default_order` changes of maps and sets | Yes |  |
843(i) | CD1 | 99 [func.referenceclosure.cons] | Reference Closure | Yes |  |
904(i) | C++11 | 99 [func.ret] | `result_of` argument types | Yes |  |
1270(i) | C++11 | 99 [func.ret] | `result_of` should be moved to `<type_traits>` | Yes |  |
1225(i) | Resolved | 99 [func.ret] | C++0x `result_of` issue | Yes |  |
1274(i) | Resolved | 99 [futures.atomic_future] | `atomic_future` constructor | Yes |  |
1305(i) | Resolved | 99 [futures.atomic_future] | preconditions for `atomic_future` | Yes |  |
1509(i) | NAD Editorial | 99 [futures.atomic_future] | No restriction on calling `future::get` more than once | Yes |  |
1510(i) | NAD Editorial | 99 [futures.atomic_future] | Should be undefined behaviour to call `atomic_future` operations unless `valid()` | Yes |  |
1511(i) | NAD Editorial | 99 [futures.atomic_future] | Synchronize the move-constructor for `atomic_future` | Yes |  |
1063(i) | NAD Concepts | 99 [iterator.backward] | 03 iterator compatibilty | Yes |  |
1105(i) | NAD Concepts | 99 [iterator.concepts.range] | Shouldn't `Range` be an `auto concept` | Yes |  |
1381(i) | C++11 | 99 [pair.range] | Replace `pair`'s range support by proper range facility | Yes |  |
789(i) | CD1 | 99 [rand.adapt.xor] | `xor_combine_engine(result_type)` should be explicit | Yes |  |
790(i) | NAD | 99 [rand.adapt.xor] | `xor_combine::seed` not specified | Yes |  |
1149(i) | NAD Concepts | 99 [rand.concept.urng] | Reformulating NonemptyRange axiom | Yes |  |
732(i) | Resolved | 99 [rand.dist.samp.genpdf] | Defect in [rand.dist.samp.genpdf] | Yes |  | 795
795(i) | Dup | 99 [rand.dist.samp.genpdf] | `general_pdf_distribution` should be dropped | Yes |  | 732
3477(i) | WP | 99 [range.semi.wrap] | Simplify constraints for `semiregular-box` | Yes | 0 |
3479(i) | Resolved | 99 [range.semi.wrap] | `semiregular-box` mishandles self-assignment | Yes | 3 |
3532(i) | WP | 99 [range.split.inner] | `split_view<V, P>::inner-iterator<true>::operator++(int)` should depend on `Base` | Yes |  |
3505(i) | WP | 99 [range.split.outer] | `split_view::outer-iterator::operator++` misspecified | Yes | 2 |
3181(i) | NAD | 99 [range.split.outer] | `split_view::outer_iterator` converting constructor is misconstrained | Yes |  |
3553(i) | WP | 99 [range.split.outer.value] | Useless constraint in `split_view::outer-iterator::value_type::begin()` | Yes |  |
3276(i) | C++20 | 99 [range.split.outer.value] | Class `split_view::outer_iterator::value_type` should inherit from `view_interface` | Yes | 0 |
529(i) | NAD Editorial | 99 [res.on.required] | The standard encourages redundant and confusing preconditions | Yes |  |
3212(i) | Resolved | 99 [span.tuple] | `tuple_element_t<1, const span<int, 42>>` is `const int` | Yes | 2 |
3138(i) | NAD | 99 [support.contract.cviol] | There is no such thing as assertion-level | Yes | 2 |
3139(i) | NAD | 99 [support.contract.cviol] | `contract_violation`'s special member functions | Yes | 1 |
990(i) | C++11 | 99 [time.clock.monotonic] | `monotonic_clock::is_monotonic` must be `true` | Yes |  |
1409(i) | Resolved | 99 [time.clock.monotonic] | Specify whether `monotonic_clock` is a distinct type or a typedef | Yes |  |
1410(i) | Resolved | 99 [time.clock.monotonic] | Add a feature-detect macro for `monotonic_clock` | Yes |  | 1411
1412(i) | Resolved | 99 [time.clock.monotonic] | Make monotonic clocks mandatory | Yes |  |
1411(i) | Dup | 99 [time.clock.monotonic] | Add a compile-time flag to detect `monotonic_clock` | Yes |  | 1410
1387(i) | C++11 | 99 [tuple.range] | Range support by `tuple` should be removed | Yes |  |
433(i) | NAD | 99 [unexpected] | Contradiction in specification of unexpected() | Yes |  |
1098(i) | C++11 | 99 [util.dynamic.safety] | definition of `get_pointer_safety()` | Yes |  |
1408(i) | C++11 | 99 [util.dynamic.safety] | Allow recycling of pointers after `undeclare_no_pointers` | Yes |  |
858(i) | CD1 | 99 [util.dynamic.safety] | Wording for Minimal Support for Garbage Collection | Yes |  |
1022(i) | NAD Editorial | 99 [util.dynamic.safety] | Pointer-safety API has nothing to do with smart pointers | Yes |  |

## Section B (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
922(i) | C++11 | B [implimits] | §[func.bind.place] Number of placeholders | Yes |  |

## Section C (5 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2786(i) | C++17 | C.3.9 [diff.cpp14.utilities] | Annex C should mention `shared_ptr` changes for array support | Yes | 0 |
2201(i) | NAD Editorial | C.7 [diff.library] | Missing macro entries from C standard library | Yes | 2 |
544(i) | NAD Editorial | C.7 [diff.library] | minor NULL problems in C.2 | Yes |  |
1115(i) | NAD Editorial | C.7 [diff.library] | `va_copy` missing from Standard macros table | Yes |  |
1155(i) | NAD Editorial | C.7 [diff.library] | Reference should be to C99 | Yes |  |

## Section D (34 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
46(i) | TC1 | D.12 [depr.str.strstreams] | Minor Annex D errors | Yes |  |
3109(i) | New | D.12.2 [depr.strstreambuf] | `strstreambuf` is copyable | No | 4 |
3095(i) | New | D.12.2.4 [depr.strstreambuf.virtuals] | `strstreambuf` refers to nonexistent member of `fpos`, `fpos::offset` | Yes | 4 |
66(i) | TC1 | D.12.2.4 [depr.strstreambuf.virtuals] | Strstreambuf::setbuf | Yes |  |
65(i) | NAD | D.12.2.4 [depr.strstreambuf.virtuals] | Underspecification of strstreambuf::seekoff | Yes |  |
267(i) | NAD | D.12.2.4 [depr.strstreambuf.virtuals] | interaction of strstreambuf::overflow() and seekoff() | Yes |  |
587(i) | NAD Editorial | D.12.3.2 [depr.istrstream.cons] | iststream ctor missing description | Yes |  |
115(i) | TC1 | D.12.5.2 [depr.strstream.cons] | Typo in strstream constructors | Yes |  |
3128(i) | C++20 | D.12.5.4 [depr.strstream.oper] | `strstream::rdbuf` needs a `const_cast` | Yes | 0 |
2940(i) | C++20 | D.15 [depr.meta.types] | `result_of` specification also needs a little cleanup | Yes | 3 |
3042(i) | C++20 | D.15 [depr.meta.types] | `is_literal_type_v` should be inline | Yes | 0 |
2838(i) | C++17 | D.15 [depr.meta.types] | `is_literal_type` specification needs a little cleanup | Yes | 0 |
2980(i) | C++20 | D.20 [depr.util.smartptr.shared.atomic] | Cannot `compare_exchange` empty pointers | Yes |  |
2172(i) | C++14 | D.20 [depr.util.smartptr.shared.atomic] | Does `atomic_compare_exchange_*` accept `v == nullptr` arguments? | Yes |  |
1030(i) | C++11 | D.20 [depr.util.smartptr.shared.atomic] | Missing requirements for smart-pointer safety API | Yes |  |
2445(i) | Resolved | D.20 [depr.util.smartptr.shared.atomic] | "Stronger" memory ordering | Yes |  |
2507(i) | New | D.22 [depr.locale.stdcvt] | `codecvt_mode` should be a bitmask type | No | 3 |
2229(i) | C++14 | D.22 [depr.locale.stdcvt] | Standard code conversion facets underspecified | Yes |  |
2869(i) | Resolved | D.22 [depr.locale.stdcvt] | Deprecate sub-clause [locale.stdcvt] | Yes |  |
2896(i) | Dup | D.22 [depr.locale.stdcvt] | The contents of `<codecvt>` are underspecified | Yes |  |
2478(i) | New | D.23.2 [depr.conversions.string] | Unclear how `wstring_convert` uses `cvtstate` | No | 4 |
2481(i) | New | D.23.2 [depr.conversions.string] | `wstring_convert` should be more precise regarding "byte-error string" etc. | No | 4 |
2175(i) | C++14 | D.23.2 [depr.conversions.string] | `wstring_convert` and `wbuffer_convert` validity | Yes |  |
2176(i) | C++14 | D.23.2 [depr.conversions.string] | Special members for `wstring_convert` and `wbuffer_convert` | Yes |  |
2174(i) | C++14 | D.23.2 [depr.conversions.string] | `wstring_convert::converted()` should be `noexcept` | Yes |  |
991(i) | C++11 | D.23.2 [depr.conversions.string] | Provide allocator for `wstring_convert` | Yes |  |
2226(i) | NAD | D.23.2 [depr.conversions.string] | `wstring_convert` methods do not take allocator instance | Yes |  |
2854(i) | NAD | D.23.2 [depr.conversions.string] | `wstring_convert` provides no indication of incomplete input or output | Yes | 3 |
721(i) | NAD | D.23.2 [depr.conversions.string] | `wstring_convert` inconsistensies | Yes |  |
2479(i) | New | D.23.3 [depr.conversions.buffer] | Unclear how `wbuffer_convert` uses `cvtstate` | No | 4 |
2480(i) | New | D.23.3 [depr.conversions.buffer] | Error handling of `wbuffer_convert` unclear | No | 4 |
1252(i) | C++11 | D.23.3 [depr.conversions.buffer] | `wbuffer_convert::state_type` inconsistency | Yes |  |
3328(i) | C++20 | D.25 [depr.fs.path.factory] | Clarify that `std::string` is not good for UTF-8 | Yes | 0 |
3659(i) | SG1 | D.26.5 [depr.atomics.flag] | Consider `ATOMIC_FLAG_INIT` undeprecation | No | 3 |

## Section arrays.ts 99 (5 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2254(i) | NAD Arrays | 99 [arrays.ts::container.requirements.general] | [arrays.ts] Is `dynarray` an allocator-aware container? | Yes | 3 |
2264(i) | NAD Arrays | 99 [arrays.ts::dynarray] | [arrays.ts] `std::dynarray` defines its initializer-list constructor in terms of a non-existent constructor | Yes | 1 |
2255(i) | NAD Arrays | 99 [arrays.ts::dynarray.cons] | [arrays.ts] `dynarray` constructor ambiguity | Yes | 0 |
2253(i) | NAD Arrays | 99 [arrays.ts::dynarray.overview] | [arrays.ts] `dynarray` should state which container requirements aren't met | Yes | 0 |
2277(i) | NAD Arrays | 99 [arrays.ts::iterator.range] | [arrays.ts] `<dynarray>` is missing in 24.7/1 | Yes | 3 |

## Section concurr.ts 99 (2 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2533(i) | SG1 | 99 [concurr.ts::futures.unique.future] | [concurr.ts] Constrain threads where `future::then` can run a continuation | No |  |
2697(i) | WP | 99 [concurr.ts::futures.unique_future] | [concurr.ts] Behavior of `future/shared_future` unwrapping constructor when given an invalid `future` | Yes | 2 |

## Section dec.tr 3 (10 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
602(i) | TRDec | 3 [dec.tr::trdec.types] | [dec.tr] "generic floating type" not defined. | Yes |  |
603(i) | TRDec | 3 [dec.tr::trdec.types] | [dec.tr] Trivially simplifying decimal classes. | Yes |  |
604(i) | TRDec | 3 [dec.tr::trdec.types] | [dec.tr] Storing a reference to a facet unsafe. | Yes |  |
599(i) | TRDec | 3.1 [dec.tr::trdec.types.encodings] | [dec.tr] Say "octets" instead of "bytes." | Yes |  |
598(i) | TRDec | 3.2 [dec.tr::trdec.types.types] | [dec.tr] Conversion to integral should truncate, not round. | Yes |  |
597(i) | NAD | 3.2 [dec.tr::trdec.types.types] | [dec.tr] The notion of 'promotion' cannot be emulated by user-defined types. | Yes |  |
606(i) | NAD | 3.2 [dec.tr::trdec.types.types] | [dec.tr] allow narrowing conversions | Yes |  |
601(i) | TRDec | 3.3 [dec.tr::trdec.types.limits] | [dec.tr] numeric_limits typos | Yes |  |
605(i) | TRDec | 3.4 [dec.tr::trdec.types.cdecfloat] | [dec.tr] <decfloat.h> doesn't live here anymore. | Yes |  |
600(i) | TRDec | 3.9 [dec.tr::trdec.types.cwchar] | [dec.tr] Wrong parameters for wcstod* functions | Yes |  |

## Section filesys.ts 1 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2654(i) | NAD Future | 1 [filesys.ts::fs.scope] | [filesys.ts] [PDTS] Concerns with security and testability | Yes |  |
2601(i) | TS | 1 [filesys.ts::fs.scope] | [filesys.ts] [PDTS] Make namespaces consistent with Library TS policy | Yes |  |

## Section filesys.ts 2 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2602(i) | TS | 2.1 [filesys.ts::fs.conform.9945] | [filesys.ts] [PDTS] Tighten specification when there is no reasonable behavior | Yes |  |
2657(i) | TS | 2.1 [filesys.ts::fs.conform.9945] | [filesys.ts] [PDTS] Inappropriate use of "No diagnostic is required" | Yes |  |

## Section filesys.ts 4 (3 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2603(i) | TS | 4.7 [filesys.ts::fs.def.filename] | [filesys.ts] [PDTS] Filename length needs bullet item | Yes |  |
2604(i) | NAD | 4.14 [filesys.ts::fs.def.parent] | [filesys.ts] [PDTS] Need definition of dot and dot-dot | Yes |  |
2606(i) | TS | 4.15 [filesys.ts::fs.def.path] | [filesys.ts] [PDTS] Path depth is underspecified | Yes |  |

## Section filesys.ts 5 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2656(i) | TS | 5 [filesys.ts::fs.req] | [filesys.ts] [PDTS] Feature test macro for TS version | Yes |  |
2662(i) | TS | 5 [filesys.ts::fs.req] | [filesys.ts] Allocator requirements unspecified | Yes |  |

## Section filesys.ts 6 (10 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2611(i) | NAD Future | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] Lack of `relative()` operation function | Yes |  |
2612(i) | NAD Future | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] `uintmax_t` too small for large file sizes | Yes |  |
2639(i) | NAD Editorial | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] `permissions()` is missing from synopsis | Yes |  |
2661(i) | NAD | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] Surprising `equivalent()` behavior if neither file exists | Yes |  |
2610(i) | NAD | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] Apparently inconsistent return types from several functions | Yes |  |
2607(i) | TS | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] Unhelpful comment for `struct space_info` | Yes |  |
2608(i) | TS | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] `file_time_type` underspecified | Yes |  |
2609(i) | TS | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] Unclear why range-based-for functions return different types | Yes |  |
2634(i) | TS | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] `enum class directory_options` has no summary | Yes |  |
2635(i) | TS | 6 [filesys.ts::fs.filesystem.synopsis] | [filesys.ts] [PDTS] `directory_options::skip_permission_denied` is not used | Yes |  |

## Section filesys.ts 7 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2613(i) | NAD | 7 [filesys.ts::fs.err.report] | [filesys.ts] [PDTS] Missing actual error conditions thrown | Yes |  |
2655(i) | TS | 7 [filesys.ts::fs.err.report] | [filesys.ts] [PDTS] Clarify Error reporting | Yes |  |

## Section filesys.ts 8 (13 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2642(i) | NAD | 8 [filesys.ts::class.path] | [filesys.ts] [PDTS] `class path` should have defaulted constructors/destructor/assignments. | Yes |  |
2643(i) | Dup | 8 [filesys.ts::class.path] | [filesys.ts] [PDTS] `path::compare(const string&)` should be `path::compare(const string_type&)` | Yes |  |
2650(i) | TS | 8 [filesys.ts::class.path] | [filesys.ts] [PDTS] `path::compare(const string& s)` wrong argument type | Yes |  |
2605(i) | TS | 8.1 [filesys.ts::path.generic] | [filesys.ts] [PDTS] Parent of root directory unspecified | Yes |  |
2615(i) | TS | 8.2.2 [filesys.ts::path.type.cvt] | [filesys.ts] [PDTS] Missing behavior for characters with no representation | Yes |  |
2614(i) | TS | 8.4.1 [filesys.ts::path.construct] | [filesys.ts] [PDTS] Incorrect postconditions for `path` copy/move constructor | Yes |  |
2649(i) | TS | 8.4.1 [filesys.ts::path.construct] | [filesys.ts] [PDTS] `path` and `directory_entry` move ctors should not be `noexcept` | Yes |  |
2616(i) | TS | 8.4.3 [filesys.ts::path.append] | [filesys.ts] [PDTS] Append behavior underspecified if target is empty | Yes |  |
2617(i) | NAD | 8.4.5 [filesys.ts::path.modifiers] | [filesys.ts] [PDTS] `path` member `swap()` unnecessary | Yes |  |
2648(i) | TS | 8.4.6 [filesys.ts::path.native.obs] | [filesys.ts] [PDTS] `path::template<class charT>string()` conversion rules | Yes |  |
2646(i) | NAD | 8.4.7 [filesys.ts::path.generic.obs] | [filesys.ts] [PDTS] Do we really need `generic*`? | Yes |  |
2618(i) | TS | 8.4.10 [filesys.ts::path.query] | [filesys.ts] [PDTS] `is_absolute()` return clause confusing | Yes |  |
2619(i) | TS | 8.6.1 [filesys.ts::path.io] | [filesys.ts] [PDTS] Consider using quoted manipulators | Yes |  |

## Section filesys.ts 10 (3 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2659(i) | NAD Editorial | 10 [filesys.ts::fs.enum] | [filesys.ts] [PDTS] Invalid expressions for bitmask types | Yes |  |
2636(i) | TS | 10.2 [filesys.ts::enum.copy_options] | [filesys.ts] [PDTS] `copy_options::copy_symlinks` is not used | Yes |  |
2644(i) | TS | 10.2 [filesys.ts::enum.copy_options] | [filesys.ts] [PDTS] enum classes `copy_options` and `perms` should be bitmask types | Yes |  |

## Section filesys.ts 12 (4 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2640(i) | TS | 12 [filesys.ts::class.directory_entry] | [filesys.ts] [PDTS] `class directory_entry` should retain `operator const path&()` from V2 | Yes |  |
2653(i) | TS | 12 [filesys.ts::class.directory_entry] | [filesys.ts] [PDTS] `directory_entry` multithreading concerns | Yes |  |
2638(i) | NAD | 12.3 [filesys.ts::directory_entry.obs] | [filesys.ts] [PDTS] Make certain functions `noexcept` and drop `error_code` version | Yes |  |
2621(i) | TS | 12.3 [filesys.ts::directory_entry.obs] | [filesys.ts] [PDTS] `directory_entry operator==` needs clarification | Yes |  |

## Section filesys.ts 13 (4 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2651(i) | Dup | 13 [filesys.ts::class.directory_iterator] | [filesys.ts] [PDTS] `directory_iterator`, `recursive_directory_iterator`, `pointer`/`reference` typedefs wrong | Yes |  |
2641(i) | TS | 13 [filesys.ts::class.directory_iterator] | [filesys.ts] [PDTS] `directory_iterator`, `recursive_directory_iterator`, move construct/assign should be `noexcept` | Yes |  |
2652(i) | TS | 13 [filesys.ts::class.directory_iterator] | [filesys.ts] [PDTS] Better to avoid deriving from `std::iterator` | Yes |  |
2622(i) | TS | 13.1 [filesys.ts::directory_iterator.members] | [filesys.ts] [PDTS] `directory_iterator` underspecified | Yes |  |

## Section filesys.ts 15 (16 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2623(i) | NAD | 15 [filesys.ts::fs.op.funcs] | [filesys.ts] [PDTS] Request for `create_regular_file()` and/or `touch()` | Yes |  |
2633(i) | TS | 15 [filesys.ts::fs.op.funcs] | [filesys.ts] [PDTS] `unique_path()` is a security vulnerability | Yes |  |
2660(i) | TS | 15.1 [filesys.ts::fs.op.absolute] | [filesys.ts] [PDTS] Incorrect Throws specification for `absolute()` | Yes |  |
2637(i) | TS | 15.2 [filesys.ts::fs.op.canonical] | [filesys.ts] [PDTS] All functions with `error_code` arguments should be `noexcept` | Yes |  |
2624(i) | TS | 15.3 [filesys.ts::fs.op.copy] | [filesys.ts] [PDTS] Incorrect effects clause for path `copy` | Yes |  |
2625(i) | TS | 15.4 [filesys.ts::fs.op.copy_file] | [filesys.ts] [PDTS] Copying equivalent paths effects not specified | Yes |  |
2645(i) | TS | 15.7 [filesys.ts::fs.op.create_directory] | [filesys.ts] [PDTS] `create_directory` should refer to `perms::all` instead of Posix `S_IRWXU|S_IRWXG|S_IRWXO` | Yes |  |
2626(i) | NAD | 15.13 [filesys.ts::fs.op.equivalent] | [filesys.ts] [PDTS] Equivalence is a volatile property | Yes |  |
2627(i) | TS | 15.14 [filesys.ts::fs.op.file_size] | [filesys.ts] [PDTS] Return value of `uintmax_t` on error? | Yes |  |
2628(i) | NAD | 15.25 [filesys.ts::fs.op.last_write_time] | [filesys.ts] [PDTS] Possible `last_write_time()` postcondition? | Yes |  |
2647(i) | TS | 15.25 [filesys.ts::fs.op.last_write_time] | [filesys.ts] [PDTS] `last_write_time()` uses ill-formed cast | Yes |  |
2658(i) | TS | 15.25 [filesys.ts::fs.op.last_write_time] | [filesys.ts] [PDTS] POSIX `utime()` is obsolescent | Yes |  |
2629(i) | TS | 15.27 [filesys.ts::fs.op.read_symlink] | [filesys.ts] [PDTS] Unclear semantics of `read_symlink` on error | Yes |  |
2630(i) | NAD | 15.28 [filesys.ts::fs.op.remove] | [filesys.ts] [PDTS] `remove()` must avoid race | Yes |  |
2631(i) | NAD | 15.30 [filesys.ts::fs.op.rename] | [filesys.ts] [PDTS] POSIX guarantees atomicity for `rename()` | Yes |  |
2632(i) | TS | 15.36 [filesys.ts::fs.op.system_complete] | [filesys.ts] [PDTS] `system_complete()` example needs clarification | Yes |  |

## Section fund.ts 3 (4 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2418(i) | TS | 3.2.2 [fund.ts::tuple.apply] | [fund.ts] `apply` does not work with member pointers | Yes | 0 |
2371(i) | TS | 3.3.1 [fund.ts::meta.type.synop] | [fund.ts] No template aliases defined for new type traits | Yes | 0 |
2390(i) | TS | 3.3.2 [fund.ts::meta.trans.other] | [fund.ts] Invocation types and rvalues | Yes |  |
2409(i) | TS | 3.3.2 [fund.ts::meta.trans.other] | [fund.ts] SFINAE-friendly `common_type/iterator_traits` should be removed from the fundamental-ts | Yes |  |

## Section fund.ts 4 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2395(i) | TS | 4.2 [fund.ts::func.wrap.func] | [fund.ts] Preconditions: is defined nowhere | Yes | 2 |
2389(i) | TS | 4.2.1 [fund.ts::func.wrap.func.con] | [fund.ts] `function::operator=` is over-specified and handles allocators incorrectly | Yes | 2 |

## Section fund.ts 5 (6 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2305(i) | NAD | 5.3.1 [fund.ts::optional.object.ctor] | [fund.ts] `optional` forwarding construction/assignment | Yes | 4 |
2282(i) | Resolved | 5.3.3 [fund.ts::optional.object.assign] | [fund.ts] Incorrect `is_assignable` constraint in `optional::op=(U&&)` | Yes |  |
2287(i) | Resolved | 5.3.3 [fund.ts::optional.object.assign] | [fund.ts] Incorrect exception safety for `optional` copy assignment operator | Yes |  |
2374(i) | TS | 5.3.5 [fund.ts::optional.object.observe] | [fund.ts] Remarks for `optional::to_value` are too restrictive | Yes | 0 |
2283(i) | Resolved | 5.9 [fund.ts::optional.comp_with_t] | [fund.ts] `optional` declares and then does not define an `operator<()` | Yes |  |
2333(i) | Resolved | 5.11 [fund.ts::optional.hash] | [fund.ts] Hashing disengaged `optional<T>` objects | Yes |  |

## Section fund.ts 6 (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2416(i) | Resolved | 6.3 [fund.ts::any.class] | [fund.ts] `std::experimental::any allocator` support is unimplementable | Yes |  |

## Section fund.ts 8 (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2410(i) | TS | 8.2.1.1 [fund.ts::memory.smartptr.shared.const] | [fund.ts] `shared_ptr<array>`'s constructor from `unique_ptr` should be constrained | Yes | 0 |

## Section fund.ts 10 (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2463(i) | TS | 10.3 [fund.ts::alg.random.sample] | [fund.ts] Incorrect complexity for `sample()` algorithm | Yes | 0 |

## Section fund.ts.v2 3 (7 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2539(i) | TS | 3.3.2 [fund.ts.v2::meta.trans.other] | [fund.ts.v2] `invocation_trait` definition definition doesn't work for surrogate call functions | Yes |  |
2568(i) | TS | 3.3.3 [fund.ts.v2::meta.logical] | [fund.ts.v2] Specification of logical operator traits uses `BaseCharacteristic`, which is defined only for `UnaryTypeTraits` and `BinaryTypeTraits` | Yes | 2 |
2558(i) | TS | 3.3.3 [fund.ts.v2::meta.logical] | [fund.ts.v2] Logical operator traits are broken in the zero-argument case | Yes | 0 |
2570(i) | TS | 3.3.3 [fund.ts.v2::meta.logical] | [fund.ts.v2] `conjunction` and `disjunction` requirements are too strict | Yes | 2 |
2588(i) | TS | 3.3.3 [fund.ts.v2::meta.logical] | [fund.ts.v2] "Convertible to `bool`" requirement in `conjunction` and `disjunction` | Yes | 3 |
2517(i) | TS | 3.7.5 [fund.ts.v2::propagate_const.assignment] | [fund.ts.v2] Two `propagate_const` assignment operators have incorrect return type | Yes | 0 |
2518(i) | TS | 3.7.10 [fund.ts.v2::propagate_const.algorithms] | [fund.ts.v2] Non-member `swap` for `propagate_const` should call member `swap` | Yes | 3 |

## Section fund.ts.v2 4 (7 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2564(i) | New | 4.2 [fund.ts.v2::func.wrap.func] | [fund.ts.v2] `std::experimental::function` constructors taking allocator arguments may throw exceptions | Yes | 3 |
2525(i) | TS | 4.2 [fund.ts.v2::func.wrap.func] | [fund.ts.v2] `get_memory_resource` should be `const` and `noexcept` | Yes | 3 |
2575(i) | TS | 4.2 [fund.ts.v2::func.wrap.func] | [fund.ts.v2] `experimental::function::assign` should be removed | Yes | 0 |
2814(i) | Resolved | 4.2.1 [fund.ts.v2::func.wrap.func.con] | [fund.ts.v2] `to_array` should take rvalue reference as well | Yes | 3 |
2527(i) | TS | 4.2.1 [fund.ts.v2::func.wrap.func.con] | [fund.ts.v2] `ALLOCATOR_OF` for `function::operator=` has incorrect default | Yes | 3 |
2574(i) | TS | 4.2.1 [fund.ts.v2::func.wrap.func.con] | [fund.ts.v2] `std::experimental::function::operator=(F&&)` should be constrained | Yes | 0 |
2526(i) | TS | 4.2.2 [fund.ts.v2::func.wrap.func.mod] | [fund.ts.v2] Incorrect precondition for `experimental::function::swap` | Yes | 0 |

## Section fund.ts.v2 5 (6 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2451(i) | TS | 5.3 [fund.ts.v2::optional.object] | [fund.ts.v2] `optional<T>` should 'forward' `T`'s implicit conversions | Yes |  |
2555(i) | TS | 5.3 [fund.ts.v2::optional.object] | [fund.ts.v2] No handling for over-aligned types in `optional` | Yes | 0 |
2745(i) | TS | 5.3 [fund.ts.v2::optional.object] | [fund.ts.v2] Implementability of LWG 2451 | Yes | 0 |
2750(i) | TS | 5.3.1 [fund.ts.v2::optional.object.ctor] | [fund.ts.v2] LWG 2451 conversion constructor constraint | Yes | 0 |
2561(i) | New | 5.3.4 [fund.ts.v2::optional.object.swap] | [fund.ts.v2] Incorrect exception specifications for 'swap' in C++ Extensions for Library Fundamentals | No | 3 |
2417(i) | NAD | 5.7 [fund.ts.v2::optional.relops] | [fund.ts.v2] `std::experimental::optional::operator<` and `LessThanComparable` requirement | Yes |  |

## Section fund.ts.v2 6 (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2509(i) | TS | 6.4 [fund.ts.v2::any.nonmembers] | [fund.ts.v2] `any_cast` doesn't work with rvalue reference targets and cannot move with a value target | Yes | 2 |

## Section fund.ts.v2 7 (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2553(i) | NAD | 7.3 [fund.ts.v2::string.view.cons] | [fund.ts.v2] `basic_string_view` substring constructor | Yes |  |

## Section fund.ts.v2 8 (7 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2573(i) | TS | 8.2.1 [fund.ts.v2::memory.smartptr.shared] | [fund.ts.v2] `std::hash<std::experimental::shared_ptr<T>>` does not work for arrays | Yes | 0 |
2551(i) | TS | 8.2.1.1 [fund.ts.v2::memory.smartptr.shared.const] | [fund.ts.v2] "Exception safety" cleanup in library fundamentals required | Yes | 0 |
2500(i) | TS | 8.2.1.2 [fund.ts.v2::memory.smartptr.shared.obs] | [fund.ts.v2] fundts.memory.smartptr.shared.obs/6 should apply to cv-unqualified `void` | Yes | 0 |
2521(i) | TS | 8.2.2.1 [fund.ts.v2::memory.smartptr.weak.const] | [fund.ts.v2] `weak_ptr`'s converting move constructor should be modified as well for array support | Yes | 2 |
2522(i) | TS | 8.8 [fund.ts.v2::memory.resource.global] | [fund.ts.v2] Contradiction in `set_default_resource` specification | Yes | 2 |
2516(i) | TS | 8.12.1 [fund.ts.v2::memory.observer.ptr.overview] | [fund.ts.v2] Public "exposition only" members in `observer_ptr` | Yes | 2 |
2515(i) | TS | 8.12.6 [fund.ts.v2::memory.observer.ptr.special] | [fund.ts.v2] Certain comparison operators of `observer_ptr` do not match synopsis | Yes | 0 |

## Section fund.ts.v2 10 (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2494(i) | TS | 10.2 [fund.ts.v2::iterator.ostream.joiner] | [fund.ts.v2] `ostream_joiner` needs `noexcept` | Yes | 0 |

## Section fund.ts.v2 13 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2792(i) | TS | 13.1.2 [fund.ts.v2::numeric.ops.gcd] | [fund.ts.v2] `gcd` and `lcm` should support a wider range of input values | Yes |  |
2733(i) | TS | 13.1.2 [fund.ts.v2::numeric.ops.gcd] | [fund.ts.v2] `gcd` / `lcm` and `bool` | Yes | 4 |

## Section fund.ts.v3 1 (1 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3649(i) | Tentatively Ready | 1.5 [fund.ts.v3::general.feature.test] | [fund.ts.v3] Reinstate and bump `__cpp_lib_experimental_memory_resource` feature test macro | Yes |  |

## Section fund.ts.v3 3 (3 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3136(i) | New | 3.2.2.2.1 [fund.ts.v3::propagate_const.class_type_requirements] | [fund.ts.v3] LFTSv3 awkward wording in `propagate_const` requirements | Yes | 3 |
3413(i) | WP | 3.2.2.7 [fund.ts.v3::propagate_const.modifiers] | [fund.ts.v3] `propagate_const`'s `swap`'s `noexcept` specification needs to be constrained and use a trait | Yes | 0 |
2960(i) | WP | 3.4 [fund.ts.v3::meta] | [fund.ts.v3] `nonesuch` is insufficiently useless | Yes | 2 |

## Section fund.ts.v3 5 (2 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3167(i) | New | 5.2 [fund.ts.v3::memory.observer.ptr] | [fund.ts.v3] Does `observer_ptr` support function types? | No | 3 |
3411(i) | New | 5.4 [fund.ts.v3::memory.resource.syn] | [fund.ts.v3] Contradictory namespace rules in the Library Fundamentals TS | Yes | 3 |

## Section fund.ts.v3 99 (3 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3134(i) | Resolved | 99 [fund.ts.v3::meta.type.synop] | [fund.ts.v3] LFTSv3 contains extraneous [meta] variable templates that should have been deleted by P09961 | Yes | 0 |
3135(i) | Resolved | 99 [fund.ts.v3::meta.type.synop] | [fund.ts.v3] LFTSv3 contains two redundant alias templates | Yes | 3 |
3357(i) | 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 (3 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3414(i) | WP | 13.7 [networking.ts::async.exec.ctx] | [networking.ts] `service_already_exists` has no usable constructors | Yes | 0 |
3124(i) | New | 13.7.5 [networking.ts::async.exec.ctx.globals] | [networking.ts] Unclear how `execution_context` is intended to store services | Yes | 3 |
3010(i) | WP | 13.11.1 [networking.ts::async.uses.executor.trait] | [networking.ts] `uses_executor` says "if a type `T::executor_type` exists" | Yes | 0 |

## Section networking.ts 16 (7 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3114(i) | LEWG | 16 [networking.ts::buffer] | [networking.ts] Permit efficient composition when using `DynamicBuffer` | Yes |  |
3020(i) | WP | 16.2 [networking.ts::buffer.reqmts] | [networking.ts] Remove spurious nested `value_type` buffer sequence requirement | Yes | 0 |
3163(i) | NAD | 16.2 [networking.ts::buffer.reqmts] | [networking.ts] Buffer sequence iterator equivalency | Yes |  |
2779(i) | WP | 16.2.1 [networking.ts::buffer.reqmts.mutablebuffersequence] | [networking.ts] Relax requirements on buffer sequence iterators | Yes |  |
3021(i) | New | 16.2.2 [networking.ts::buffer.reqmts.constbuffersequence] | [networking.ts] Relax pointer equivalence requirement for `ConstBufferSequence` | Yes | 3 |
3027(i) | New | 16.2.4 [networking.ts::buffer.reqmts.dynamicbuffer] | [networking.ts] `DynamicBuffer` `prepare` exception specification | Yes | 3 |
3072(i) | New | 16.2.4 [networking.ts::buffer.reqmts.dynamicbuffer] | [networking.ts] `DynamicBuffer` object lifetimes underspecified | Yes | 3 |

## Section networking.ts 17 (2 issues)

(view only non-Ready open issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3073(i) | New | 17 [networking.ts::buffer.stream] | [networking.ts] (`async_`)`read` and (`async_`)`write` don't support `DynamicBuffer` lvalues | Yes | 3 |
3071(i) | WP | 17.9 [networking.ts::buffer.read.until] | [networking.ts] `read_until` still refers to "input sequence" | Yes | 0 |

## Section networking.ts 18 (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
3002(i) | WP | 18.9.4 [networking.ts::socket.acceptor.ops] | [networking.ts] `basic_socket_acceptor::is_open()` isn't `noexcept` | Yes | 0 |

## Section networking.ts 19 (3 issues)

(view only non-Ready open issues)

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

## Section parallel.ts 99 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
2538(i) | NAD | 99 [parallel.ts::parallel.alg.general.exec] | [parallel.ts] Requirements on data race behavior of iterators and swap should be clarified | Yes |  |
2541(i) | Resolved | 99 [parallel.ts::parallel.alg.overloads] | [parallel.ts] Headers for `ExecutionPolicy` algorithm overloads | Yes | 1 |

## Section tr1 5 (4 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
546(i) | NAD | 5.1.1 [tr1::tr.rand.req] | [tr1] _Longlong and _ULonglong are integer types | Yes |  |
785(i) | NAD | 5.1.4.5 [tr1::tr.rand.eng.disc] | [tr1] Random Number Requirements in TR1 | Yes |  |
701(i) | NAD | 5.2.1.1 [tr1::tr.num.sf.Lnm] | [tr1] assoc laguerre poly's | Yes |  |
702(i) | NAD | 5.2.1.2 [tr1::tr.num.sf.Plm] | [tr1] Restriction in associated Legendre functions | Yes |  |

## Section tr1 8 (2 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
568(i) | NAD | 8.16.4 [tr1::tr.c99.cmath.over] | [tr1] `log2` overloads missing | Yes |  |
555(i) | NAD Editorial | 8.21 [tr1::tr.c99.boolh] | [tr1] 8.21/1: typo | Yes |  |

## Section tr1 99 (1 issues)

Issue | Status | Section | Title | Proposed Resolution | Priority | Duplicates
799(i) | NAD | 99 [tr1::rand.eng.mers] | [tr1] [tr.rand.eng.mers] and [rand.eng.mers] | Yes |  |