› N5044 Brno June 2026 Venue (2nd revision) H. Dusíková
Abstract
[WG21](mailto:WG21 (YOU-NEED-JAVASCRIPT-ENABLED) #V0cyMSA8YWxsQGxpc3RzLmlzb2NwcC5vcmc+P3N1YmplY3Q9TjUwNDQ6IEJybm8gSnVuZSAyMDI2IFZlbnVlICgybmQgcmV2aXNpb24p)
› N5045 WG21 agenda: 8-13 June 2026, Brno, Czechia N. Ranns
› N5046 Working Draft, Programming Languages -- C++ T. Köppe
› N5047 Editors' Report, Programming Languages -- C++ T. Köppe
› P0876R23 fiber_context - fibers without scheduler O. Kowalke , N. Goodspeed
Abstract
This paper proposes a minimal API that enables stackful context switching **without** the need for a scheduler. The API is suitable to act as building-block for high-level constructs such as stackful coroutines as well as cooperative multitasking (aka user-land/green threads that incorporate a **scheduling** facility).
› P1040R10 std::embed and #depend J. Meneide
Abstract
> I’m very keen on std::embed. I’ve been hand-embedding data in executables for NEARLY FORTY YEARS now. — Guy "Hatcat" Davidson, June 15, 2018
› P2583R4 Info: Symmetric Transfer and Sender Composition M. Gill , V. Falco
› P2728R12 Unicode in the Library, Part 1: UTF Transcoding E. Nolan
› P2826R3 Expression Aliases G. Ažman
Abstract
This paper introduces a way to rewrite a function call to a different expression without a forwarding layer.
› P2906R1 Structured bindings for std::extents B. Gruber , Y. Wang , M. Hoemmen
Abstract
[[P0009R18]](https://wg21.link/p0009r18) proposed `std::mdspan` , which was approved for C++23. It comes with the utility class template `std::extents` to describe the integral extents of a multidimensional index space. Practically, `std::extents` models an array of integrals, where some of the values can be specified at compile-time. However, `std::extents` behaves very little like an array. A no
› P2929R4 chunked_invoke D. Towner , R. Arutyunyan
Abstract
ISO/IEC 19570:2018 introduced data-parallel types to the C++ Extensions for Parallelism TS [P1928R15]. That paper, and several ancillary papers, do an excellent job of setting out the main features of an extension to C++ which allows generic data parallel programming on arbitrary targets. However, it is inevitable that the programmer will want to make some use of target-specific intrinsics, or cal
› P2964R4 Allowing user-defined types in std::simd D. Towner , R. Arutyunyan
Abstract
The C++ standard library includes data-parallel types in the `<simd>` header, currently restricting element types to a closed list of *built-in vectorizable* types: arithmetic types and `std::complex` specializations. This paper proposes a minimal change to the specification in which this list is extended. Firstly, `std::byte` is added to the closed list as a standard library type with fixed seman
› P3045R8 Quantities and units library M. Pusz , D. Berner , J. Peña , C. Hogg , N. Holthaus , R. Michaels , V. Reverdy
Abstract
Several groups in the ISO C++ Committee reviewed the “P1935: A C++ Approach to Physical Units” [[P1935R2]](https://wg21.link/p1935r2) proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potential standardization of such a library and encouraged further work. The authors also got valuable initial feedback that highly influenced the design of the V2 version of the [[
› P3097R2 Contracts for C++: Virtual functions T. Doumler , J. Berne
Abstract
We propose to allow specifying precondition and postcondition assertions on virtual functions, in the same way they can already be specified on non-virtual functions:
› P3098R2 Contracts for C++: Postcondition captures T. Doumler , G. Ažman , J. Berne
Abstract
We propose to add a new, optional syntactic construct to postcondition assertions, called *postcondition* captures. Postcondition captures are spelled in the same fashion as lambda captures. They are placed immediately after the `post` contextual keyword and before the predicate: `post [``captures``] (``predicate``)` Postcondition captures are variables constructed when the function is called. The
› P3099R2 Contracts for C++: User-defined diagnostic messages T. Doumler , P. Bindels , J. Berne
Abstract
A user-defined diagnostic message can provide additional information that can help developers more quickly understand why a particular assertion failed and how to resolve the issue. The ability to optionally provide such a message is valuable for any assertion facility, including contract assertions. The C `assert` macro does not directly support an associated diagnostic message. However, the idio
› P3100R6 A framework for systematically addressing undefined behaviour in the C++ Standard T. Doumler , J. Berne
Abstract
In this paper, we enumerate all cases of core language undefined behaviour explicitly specified in the C++ Standard, group them into ten categories, and classify them along a number of relevant criteria.
› P3104R5 Bit permutations J. Schultke
Abstract
The C++ bit manipulation library in `<bit>` is an invaluable abstraction from hardware operations. Functions like `countl_zero` help the programmer avoid use of intrinsic functions or inline assembly.
› P3125R5 constexpr pointer tagging H. Dusíková
Abstract
Pointer tagging is widely known and used technique ([Glasgow Haskell Compiler](https://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf), LLVM's `[PointerIntPair](https://github.com/llvm/llvm-project/blob/8e5aa538caccef167e8096b2173fdaf2be9cc129/llvm/include/llvm/ADT/PointerIntPair.h#L80)`, `[PointerUnion](https://github.com/llvm/llvm-project/blob/8e5aa538caccef167e8096b2173fdaf2be9cc12
› P3290R4 Integrating Existing Assertions With Contracts J. Berne , T. Doumler , J. Lakos
Abstract
**–** Specified use of `source_location::current()` and discussed implementation choices
› P3351R4 views::scan Y. Li
Abstract
The motivation for this view is given in [P2760R1] and quoted below for convenience:
› P3377R0 constexpr `reinterpret_cast` partial replacements H. Dusíková , G. Ažman
Abstract
| functionality | runtime only (current status) | runtime & constexpr compatible replacement | status | | --- | --- | --- | --- | | pointer ↔︎ integer | `intptr_t * iptr = reinterpret_cast<intptr_t>(ptr); auto * optr = reinterpret_cast<pointer>(iptr);` | — | not proposed | | pointer tagging | `auto tptr = reinterpret_cast<pointer>( reinterpret_cast<intptr_t>(ptr) \| 0b1u); auto tag = static_cast<b
› P3400R3 Controlling Contract-Assertion Properties J. Berne
Abstract
— Major restructuring: new Introduction, Design, Glossary, expanded Standard Library Additions sections
› P3411R6 `any_view` H. Xie , S. Yilmaz , L. Dionne , P. Roberts
Abstract
This paper proposes a new type-erased view: `std::ranges::any_view`. That type-erased view allows customizing the traversal category of the view, its value type and a few other properties. For example:
› P3427R4 Hazard Pointer Synchronous Reclamation M. Michael , M. Wong , P. McKenney , M. Wever
Abstract
This paper proposes extending the C++26 hazard pointer interface to support synchronous reclamation. This revision, P3427R4, revises R3 by following LEWG Croydon 2026 feedback.
› P3428R3 Hazard Pointer Batches M. Michael , M. Wong , P. McKenney
Abstract
This paper proposes extending the C++26 hazard pointer interface to support creation and destruction of batches of nonempty hazard pointers. This revision P3428R3 revises R2 by following LEWG Croydon 2026 feedback. It is ready for review by LWG in Brno 2026.
› P3568R2 break label; and continue label; J. Schultke
Abstract
While C++ already has a broad selection of control flow constructs, one construct commonly found in other languages is notably absent: the ability to apply `break` or `continue` to a loop or `switch` when this isn’t the innermost enclosing statement. This feature is popular, simple, and quite useful:
› P3596R2 Undefined Behavior and IFNDR Annexes J. Berne , T. Doumler , J. Maurer , S. Yaghmour
› P3642R5 Carry-less product: std::clmul J. Schultke
Abstract
[Carry-less multiplication](https://en.wikipedia.org/wiki/Carry-less_product) is a simple numerical operation on unsigned integers. It can be a seen as a regular multiplication where `xor` is being used as a reduction instead of `+`.
› P3666R4 Bit-precise integers J. Schultke
Abstract
In distant history, there have been various attempts at standardizing multi-precision integers in C++, such as [[N1692]](https://wg21%2elink/n1692) "A Proposal to add the Infinite Precision Integer to the C++ Standard Library", [[N1744]](https://wg21%2elink/n1744) "Big Integer Library Proposal for C++0x", and [[N4038]](https://wg21%2elink/n4038) "Proposal for Unbounded-Precision Integer Types", al
› P3668R3 Defaulting Postfix Increment and Decrement Operations M. Taylor , A. (Waffl3x)
Abstract
Postfix increment and decrement operators have a default behaviour which already exists in the mind of every C++ developer - make a copy, increment/decrement the original, and return the copy. The canonical implementation of this default can always be expressed entirely in terms of other operations (prefix increment/decrement and copy-construction), in a manner which is entirely agnostic to any ot
› P3724R4 Integer division J. Schultke
Abstract
C++ currently only offers truncating integer division in the form of the `/` operator. However, other rounding modes have various use cases too, and implementing these as the user can be surprisingly hard, especially when integer overflow needs to be avoided, and negative inputs are accepted.
› P3729R1 Aligning span and string_view M. Hava
Abstract
```cpp template<typename T, size_type E = dynamic_extent> struct span { … //runtime subsetting: constexpr span subspan(size_type pos = 0, size_type n = dynamic_extent) const; constexpr span first(size_type count) const; constexpr span last(size_type count) const; … }; template<typename charT, typename traits = char_traits<charT>> struct basic_string_view { … //in place shrinking: constexpr void re
› P3737R4 std::array is a wrapper for an array! J. Schultke
Abstract
The `std::array` class template has established itself as a de-facto replacement for "builtin arrays" or "C-style arrays" in many code bases. This also means that it is frequently taught to novice programmers, with an explanation along the lines of:
› P3738R1 Make std::make_from_tuple SFINAE friendly Y. Wang
Abstract
This paper introduce constraints for `std::make_from_tuple` to make it SFINAE friendly.
› P3816R3 Hashing meta::info M. Cummins , V. Yukhymenko
Abstract
This paper proposes a new standard library template, `consteval_hash<T>`, with a single specialization for `meta::info`. The purpose of this facility is to provide a standard interface for compile-time hashing, thereby allowing unordered containers such as `unordered_map` and `unordered_set` to be used with `meta::info` keys, and potentially with other types in future.
› P3818R2 constexpr exception library which is unsurprising in potentially constant initialization H. Dusíková
Abstract
To make `constexpr` exception support complete, and allow all functionality withing constant evaluation. This paper was seen in previous revision by LEWG. It didn't get consensus and most of the group prefered the conservative approach of removing `constexpr` from `std::uncaught_exception()` and `std::current_exception()`. The group asked me to revisit this again for C++29.
› P3850R0 A proposed plan for extending Contracts in C++29 T. Doumler , J. Berne
› P3852R1 constexpr `is_pointer_within` memory area H. Dusíková
Abstract
At first maybe this does seem as somehow arcane or esoteric. But this is a problem worth solving and it will make C++ a bit more expressive.
› P3876R2 Extending <charconv> support to more character types J. Schultke , P. Bindels
Abstract
Support for `char8_t` and other Unicode character types in `std::to_chars` and `std::from_chars` is clearly useful. File formats such as JSON require the use of Unicode character encodings, so an application that deals with JSON may want to use `char8_t` in its APIs and internally. However, when attempting to use `char8_t` for this purpose, one quickly runs into problems:
› P3891R1 Improve readability of the C++ grammar by adding a syntax for groups and repetitions J. Schultke
Abstract
The current C++ syntax notation as specified in [[syntax]](https://eel.is/c++draft/syntax) and summarized in [[gram]](https://eel.is/c++draft/gram) has only a handful of features:
› P3933R1 constexpr `std::hive` H. Dusíková , NylteJ
Abstract
C++ users are often surprised by missing functionality available during constant evaluation, sometimes there is no real reason in the language, it's just no one wrote a paper making the thing `constexpr`. Anecdotally this is often surprise to Jason Turner's students when they start experimenting with `constexpr` code.
› P3935R1 Rebasing <cmath> on C23 J. Schultke
Abstract
[[P3348R4]](https://wg21%2elink/p3348r4) rebased the C++26 standard on C23; it previously referred to C17. However, this process was deliberately left incomplete: some of the new C23 `<math.h>` features are only used by decimal floating-point types, or they require core language changes, etc.
› P3969R1 Fixing std::bit_cast of types with padding bits J. Schultke
Abstract
> The following use of `std::bit_cast` has undefined behavior at compile time: > > ```cpp > constexpr auto x = std::bit_cast<__int128>(0.0L); // GCC accepts (x = 0), Clang rejects > ``` > > That is because an 80-bit x87 `long double` has 6 bytes of padding, and it is undefined behavior to map those padding bits onto non-padding bits in the destination type via `std::bit_cast`. [[bit.cast]](https:/
› P3971R1 Generalised type rebinding for structures of uniform elements D. Towner
Abstract
Modern C++ provides powerful facilities for generic programming, but lacks a uniform way to change the element type of containers and container-like types. Consider a simple requirement: convert a container of `float` into the corresponding container of `double`, without the caller having to know what kind of container it is.
› P3973R1 bit_cast_as: Element type reinterpretation for std::simd D. Towner
Abstract
SIMD programming frequently requires reinterpreting vector data at different element granularities—converting packed bytes to shorts, accessing the bit representation of floats, or regrouping data for different operations. While platform intrinsics have long supported this pattern naturally, with `std::simd` programmers must use `std::bit_cast` with fully-specified target types, manually computing
› P3983R2 simd object representation D. Towner , R. Arutyunyan
Abstract
The Working Draft makes `simd` types *trivially copyable types*, which allows `std::bit_cast` operations. However, the object representation is unspecified, making the results similarly unspecified.
› P4003R3 Ask: A Minimal Coroutine Execution Model V. Falco , M. Gill , S. Gerbino
Intent
Ask
Abstract
This paper asks the committee to advance the *IoAwaitable* protocol as a standard coroutine execution model.
› P4007R3 Info: Open Issues in `std::execution::task` V. Falco , M. Gill
Intent
Info
Abstract
`std::execution::task` ([P3552R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3552r3.html) [1]) had open issues identified by national ballot comments, LWG issues, and published papers. Croydon resolved several. This paper classifies each issue by whether it can be resolved after C++26 ships or whether shipping forecloses the fix, and notes which classified issues were addressed at C
› P4013R0 constexpr `any` of all the things H. Dusíková
Abstract
Often you just need to pass a value around, but not interact with it, for that in C++ you have multiple options: template (and keep the type information intact), inheritance (and being force to use intrusive inheritance in your types), passing allocated `(const) void *` pointer (and managing its lifetime), alternatively use `std::unique_ptr` or `std::shared_ptr` with custom deleters, or use a poly
› P4014R2 Info: The Sender Sub-Language For Beginners V. Falco , M. Gill
Intent
Info
Abstract
Every sender algorithm in C++26 - all thirty - explained, demonstrated, and mapped to its plain-C++ equivalent.
› P4025R2 The SG19 Priority List for C++29/32 M. Wong , P. Ratzloff
› P4035R1 Info: The Need for Escape Hatches V. Falco
Intent
Info
Abstract
C++ should make the safe thing easy, and the unsafe thing possible.
› P4036R0 Info: Why Span Is Not Enough V. Falco
Intent
Info
Abstract
C++ has bytes. A contiguous region of bytes needs a type. A sequence of such regions needs another. This paper examines the types that predictably come to mind, and their consequences.
› P4041R0 Info: Is `std::execution` a Universal Async Model? V. Falco
Intent
Info
Abstract
C++20 standardized coroutines. C++26 adds `std::execution`. Both are asynchronous models. The question is whether the
› P4046R0 Info: SAGE: Saving All Gathered Expertise V. Falco
Intent
Info
Abstract
We interviewed five experts, had AI distill their wisdom into 11 principles, built a scoring rubric, and graded our own paper first.
› P4047R0 Info: CRYSTAL BALL: Checking Predictions Against the Record V. Falco
Intent
Info
Abstract
This paper collects dated, public, falsifiable predictions about `std::execution` from proponents and critics alike, and checks each against the record.
› P4048R0 Info: Networking for C++29: A Call to Action V. Falco
› P4088R1 Info: What C++20 Coroutines Already Buy The Standard V. Falco
Intent
Info
Abstract
C++ already got an asynchronous model: regular C++20 coroutines.
› P4089R1 Info: On the Diversity of Coroutine Task Types V. Falco
Intent
Info
Abstract
The Environment parameter in `std::execution::task` makes cross-library coroutine interoperability structurally impossible without knowing every query by name.
› P4090R1 Info: Sender I/O: A Constructed Comparison V. Falco
Intent
Info
Abstract
The sender composition algebra does not apply to compound I/O results without losing data, and the construction that preserves all data produces code identical to the coroutine version.
› P4091R1 Info: Error Models of Regular C++ and the Sender Sub-Language V. Falco
Intent
Info
Abstract
Both coroutines and senders destroy compound data at an abstraction floor - the difference is that the sender floor sits below the composition algebra, and the coroutine floor is opt-in.
› P4092R1 Info: Consuming Senders from Coroutine-Native Code V. Falco , S. Gerbino
Intent
Info
Abstract
A single class template bridges sender-based code into coroutine-native I/O with inline operation state, correct stop propagation, and automatic dispatch-back.
› P4093R1 Info: Producing Senders from Coroutine-Native Code V. Falco , S. Gerbino
Intent
Info
Abstract
Coroutine-native awaitables can be wrapped as senders, but compound I/O results must be reduced to an error code before crossing the bridge.
› P4094R1 Info: The Unification of Executors and P0443 V. Falco
Intent
Info
Abstract
The unification of three working executor models had unanticipated downstream consequences.
› P4095R1 Info: The Basis Operation and P1525 V. Falco
Intent
Info
Abstract
Of the four deficiencies that [P1525R0](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1525r0.pdf) [1] identified in `execute(F&&)`, three do not arise under the original framing of the callable as a continuation, and the fourth addresses a different question.
› P4096R1 Info: Coroutine Executors and P2464R0 V. Falco
Intent
Info
Abstract
The committee set aside the Networking TS in 2021. The process had no mechanism to verify that the analysis examined every applicable framing, and no mechanism to revisit the outcome against evidence.
› P4097R1 Info: The Networking Claim and P2453R0 V. Falco
Intent
Info
Abstract
The committee expressed consensus that sender/receiver is a good basis for networking. The published evidence behind that word is documented here.
› P4098R1 Info: Async Claims and Evidence V. Falco
Intent
Info
Abstract
Published claims about executors, networking, and unification shaped a decade of committee decisions. The published evidence behind those claims is documented here.
› P4099R1 Info: The Twenty-One Year Networking Arc V. Falco
Intent
Info
Abstract
Four decisions, each locally reasonable, each under-evidenced, produced a decade without networking in the C++ standard.
› P4100R1 Info: Coroutine-Native I/O for C++29 (The Network Endeavor) V. Falco , S. Gerbino , M. Vandeberg , M. Gill , M. Nejati
Intent
Info
Abstract
C++ coroutines have five language mechanisms that combine into the ideal substrate for coroutine-native I/O.
› P4123R0 Info: The Cost of Senders for Coroutine I/O V. Falco
Intent
Info
Abstract
Every concession granted. The gap remains. I/O users pay for what they do not need.
› P4124R0 Info: Combinators and Compound Results from I/O V. Falco
Intent
Info
Abstract
`std::execution::when_all` dispatches on channels. I/O errors arrive on the value channel. The combinator does not see them.
› P4125R1 Info: Coroutine-Native I/O at a Derivatives Exchange M. Gill
Intent
Info
Abstract
A derivatives exchange is porting from Asio callbacks to coroutine-native I/O. Early results: it works.
› P4126R1 Info: A Universal Continuation Model V. Falco , K. Morgenstern
Intent
Info
Abstract
Senders pay a frame allocation to enter the awaitable protocol. They do not have to.
› P4127R0 Info: The Coroutine Frame Allocator Timing Problem V. Falco
Intent
Info
Abstract
The coroutine frame allocator must arrive before the coroutine frame exists. Exactly two mechanisms can deliver it.
› P4136R2 #line is not in line with existing practices C. Jabot
Disposition Date
2026-03Adopted
Abstract
line-directive: # line pp-tokens new-line The string-literal of a #line directive, if present, shall be a character string literal. The line number of the current source line is the line number of the current physical source line, i.e., it is one greater than the number of new-line characters read or introduced in translation phase 1[lex.phases] while processing the source file to the current prep
› P4139R2 Better Name for Better Lookups in P3091 N. Myers , P. Halpern
Abstract
[[P3091R5]](https://wg21.link/p3091r5), forwarded to LWG for C++29, adds member functions `get` to associative containers in the Standard Library. These member functions work like `operator[]` or `at`, but return an `optional<T&>` value instead of a simple reference; when lookup fails, they return the empty object. While the feature was strongly favored, support for the name `get` yielded only a w
› P4147R0 constexpr => runtime bridge H. Dusíková
Abstract
This paper introduces a customization point which is called when a constant-evaluated value is moving outside of its constant-evaluation (like initialization of `constexpr` variable, or `consteval` function emitting a value to an expression / function evaluated at runtime).
› P4148R1 protocol: Structural Subtyping for C++ J. Coe , H. Dusikova , A. Peacock , P. Craig , N. Banglawala
Abstract
We propose `protocol<T,` `A>` and `protocol_view<T>`, standard library vocabulary types for structural subtyping in C++. Interfaces are specified as plain structs; any type whose member functions satisfy the interface is accepted without requiring explicit inheritance.
› P4166R0 Info: Benefits of Frame-Visible Coroutines for Senders V. Falco
Intent
Info
Abstract
Frame-visible coroutines would eliminate `std::execution::task`'s heap allocation and give sender-based coroutine algorithms full optimizer visibility.
› P4167R0 reflection annotations to control ADL H. Dusíková
Abstract
This papers provides a customization for ADL via a annotation to add an entity to be associated with a type. It adds a new `<meta>` type to represent the annotation, and it modifies [`[basic.lookup.argdep]`](https://eel.is/c++draft/basic.lookup.argdep)
› P4170R0 Info: A Reader's Guide to the May 2026 Mailing V. Falco
Intent
Info
Abstract
Thirty-four papers audit two decades of async decisions, deploy coroutine-native I/O at a derivatives exchange with zero per-operation allocations, bridge the result to std::execution, and deliver open-source AI evaluation tools for WG21 proposals.
› P4172R1 Info: IoAwaitable for Coroutine-Native Byte-Oriented I/O V. Falco , S. Gerbino
Intent
Info
Abstract
This paper documents the design rationale for the *IoAwaitable* protocol.
› P4176R1 Grammar non-terminals for postfix-expressions V. Serebrennikov
Abstract
7.6.1 [[expr.post]](https://wg21.link/expr.post) lists all the grammar at the top, while the rest of the subclause resorts to either quoting the grammar or describing it with words. This paper aims to improve the situation, introducing new non-terminals and putting their definitions in the respective subclauses.
› P4178R0 Info: Trade-offs in Asynchronous Abstraction Design V. Falco
Intent
Info
Abstract
Sections of P2300R10 are compared to other sections of P2300R10 and entered into the historical record.
› P4182R1 Info: A Citable Inventory of Platforms, Operating Systems, and Compiler Toolchains M. Gill
Intent
Info
Abstract
Every mailing repeats the same deployment background. This paper puts one citeable inventory in the record.
› P4185R0 Completing the Mathematical Model for C++ Quantities and Units M. Pusz
Abstract
[[P3045R7]](https://wg21.link/p3045r7) proposes a C++ quantities and units framework built on two core abstractions: `quantity` (displacement vectors) and `quantity_point` (points in an affine space). Real-world experience with the **[[mp-units]](https://mpusz.github.io/mp-units)** reference implementation, together with feedback from SG6, BSI, ANSI, and the broader C++ community, shows that this
› P4189R0 get()ing the pointer from optional N. Liber
Abstract
There is no easy, obvious way to retrieve the pointer stored in an `optional<T&>` , nor a pointer to the object in an `optional<T>` This proposal rectifies that by proposing a `.get_ptr()` method.
› P4198R0 Runtime Indexed Tuples A. Muneem
Abstract
Special thanks to Simon Schröder for professional feedback and technical inquiries. Additional credits to Sebastian Wittmeier, Bjorn Reese, Thiago Macieira, Marcin Jaczewski, Andre Kostur, Weinrich Steve, Jason McKesson, Adrian Johnston, and David Brown.
› P4205R0 Range-Based Searchers Y. Li
Abstract
Current inconsistency in the `std::ranges::search` API forces users to exit the Ranges world to use searchers and resort to using traditional STL algorithms instead, which is undesirable.
› P4206R0 Revert string support in std::constant_wrapper B. Revzin , Z. Laine , M. Kretz , J. Wakely , T. Kamiński
Abstract
Originally, the design of `std::constant_wrapper` [[P2781R4]](https://wg21.link/p2781r4) was :
› P4207R0 Info: Prosecute Your Paper To Improve It V. Falco
Intent
Info
Abstract
For less than a dollar, every paper in the mailing can know its own weaknesses before the committee does.
› P4208R0 Info: C++ Contracts on Trial - Does P2900 Survive Cross-Examination? V. Falco
Intent
Info
Abstract
An AI examines [P2900R14](https://wg21.link/p2900r14) "Contracts for C++" by applying the Advocatus Diaboli from [P4207R0](https://isocpp.org/files/papers/P4207R0.pdf) "Prosecute Your Paper To
› P4209R0 numeric_limits for std::simd D. Towner
Abstract
The SIMD working draft introduces `std::simd::basic_vec<T, Abi>` as an element-wise parallel extension of an element type `T`. A central goal is to allow the same generic numeric code to operate on scalar `T` and on `basic_vec<T, Abi>` interchangeably. Most non-trivial numeric code that aims for that behaviour would require `std::numeric_limits<V>` somewhere. For example:
› P4210R0 copy_on_write: A Vocabulary Type for Lazily- Copied Values D. Pfeifer
Abstract
We propose the addition of a new class template `copy_on_write<T>` to the C++ Standard Library.
› P4211R0 Adaptors For Closed Ranges Y. Li
Abstract
This proposal introduces a family of adaptors that convert closed ranges into half-open ranges, as expected by most other standard library facilities in C++, thus providing direct support for a range model that has been fundamentally incompatible with the C++ iterator model until now.
› P4212R0 ISO/IEC 60559 Floating-Point Support Annex for C++ G. Davidson
Abstract
This proposal introduces a new Annex specifying ISO/IEC 60559 conformance. There are nine clauses that need to be considered from ISO/IEC 60559:2020, clauses 3 to 11. [559] offers binary and decimal floating-point arithmetic features. This proposal will only introduce binary floating-point feature support.
› P4213R0 Minimal SI: Defining the International System of Units for the C++ Standard Library M. Pusz
Abstract
[[P3045R8]](https://wg21.link/p3045r8) supplies the type system. It does not supply the SI. A user who includes the framework gets `quantity` , `unit` , `quantity_spec` , `prefix` — but no `metre` , no `kilogram` , no `second` . The framework is deliberately content-agnostic: it supports arbitrary systems of quantities and units. Shipping the framework without SI content would be like shipping `<a
› P4214R0 Composable Correctness and Progress Guarantees L. Teodorescu
Abstract
Correctness is usually harder to discuss than the individual properties from which it is built. Following Lamport’s division of correctness into safety and liveness [[Lamport77]](https://lamport.azurewebsites.net/pubs/proving.pdf), this paper argues that C++ standardization should treat progress guarantees as part of the correctness contract of concurrency facilities.
› P4215R0 Primitives for Non-Local Concurrency L. Teodorescu
Abstract
C++26 senders provide a vocabulary for composing asynchronous work, but they do not by themselves provide sender-native equivalents of synchronization primitives that impose non-local concurrency constraints. Programs still need to serialize unrelated operations, bound concurrency across independently submitted work, wait for readiness, and coordinate completion or phase boundaries.
› P4216R0 Comparisons for span M. Hava
Abstract
**Design Space** **Deep value comparisons** All existing *reference types* use the same comparison model: they compare the referenced values (if any), not their identity. This model has always been in place for `string_view` and was adopted
› P4217R0 when_all() is just just() R. Leahy
Abstract
The standard currently specifies, by fiat, that `std::execution::when_all()` is ill-formed (§33.9.12.12 [exec.when.all]):
› P4220R0 Design goals for zstring_view A. Krzemieński
Abstract
During the 2025 Sofia meeting, LEWG declared consensus to spend more time on `zstring_view` ([[P3655R4]](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3655r4.html)). This paper follows the direction. We want to make sure that the design goals for `zstring_view` are clearly understood before the decision whether to even have it or not are made.
› P4221R0 Atomic Compare M. Michael , P. McKenney , M. Wong
Abstract
This paper proposes adding `compare` and `compare_load` member functions to `std::atomic<T>`. These functions perform an atomic comparison of the atomic object's value with an expected value, following the same bitwise comparison semantics as `compare_exchange_strong`, but without writing a new value to the atomic object. The `compare_load` variant also updates the expected argument on failure. Th
› P4222R0 An initialization profile B. Stroustrup
Abstract
The initialization profile should be the easiest to define, but there can be no profile that everybody can agree on without discussion and alternative choices. Also, the rules for initialization and uninitialized memory are far more complex than most people are willing to believe. The initialization profile is foundational to just about every profile, so the initialization profile must isolate tho
› P4223R0 Towards senders in interfaces I. Petersen
Abstract
* **Separation of interface and** implementation; the primary need identified in this paper is the ability to separate *what* an async function does (its interface) from *how* it does it (its implementation). The problem with the existing senders is that their types reflect the fully composed computation they represent so it is impossible to achieve this separation with the status quo.
› P4225R0 2026-05 Library Evolution Polls I. Levi , F. Fracassi , A. Weis , C. Jabot
Abstract
This paper contains the decision polls that the C++ Library Evolution group will take in May 2026.
› P4227R0 What's in a cstring_view? A. Weis
Abstract
In C, a `’\0’` in a char array marks the end of the string. A C string is not just a string that has a `’\0’` at the end. It’s a string that *ends* *at* *the* *first* `’\0’` *character*.
› P4228R0 try_*_back For Other Sequence Containers N. Liber
Abstract
Now that we have `try_*_back` in `inplace_vector`, we should add it to `vector` and explore adding it to other sequence containers that provide `push_back` and `emplace_back`.
› P4229R0 Canonical Parallel Scan: Expression and Observation Contracts for Reproducible Parallel Algorithms A. Drakeford
Abstract
Blelloch [Blelloch1990] identifies `reduce`, `scan`, and `transform` as core parallel primitives. P4016R0 demonstrated that efficient, reproducible reduction is achievable using a tree-based abstract expression.
› P4230R0 Implementability of P0943's C++ stdatomic.h H. Boehm
Abstract
There has been a lot of discussion arguing that the C++23 spec essentially forces ODR violations. by implementing atomics as both a struct/class (in C++) and a scalar (in C) IMO, that depends on your perspective. If you view C code as also C++ code, then ODR violations in a combined C with C++ program make sense. This is the common view of C types in C++.
› P4231R0 Unified floating point rounding proposal H. Boehm , G. Davidson , J. Schultke
Abstract
We propose the addition of the following struct. Actual wording is still left as future work (some of which can be taken from p3864). This is basically identical to P2746, except that we constrain operations to be IEEE conformant whenever is_iec_559 is `true`.
› P4233R0 More minor additions to standard library hardening K. Varlamov
Abstract
This paper is a small followup to [P3471R4 “Standard Library Hardening”](https://wg21.link/P3471R4) and [P3697R1 “Minor additions to C++26 standard library hardening”](https://wg21.link/P3697) that proposes adding several hardened preconditions across the Library. The unifying theme is in fact a lack of a unifying theme; these are “miscellaneous” checks that don’t fit into a larger category. This
› P4234R0 $identifiers M. Wippich , M. Çağrı
Abstract
One of the oldest and most widely supported extensions to C++ is allowing `$` in identifiers. This feature's origins predate both standard C++ and standard C. As GCC notes in its [documentation](https://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html):
› P5000R1 Direction for ISO C++29 D. Vandevoorde , J. Garland , P. McKenney , R. Orr , B. Stroustrup , M. Wong
Abstract
The above suggests priorities for standardization goals. However, we believe WG21’s work could also benefit from topical studies to gather data that will hopefully bring better understanding of the reality of C++. Examples include:
