› N5048 2026-06 WG21 Admin telecon G. Davidson
› N5049 WG21 2026-06 Brno Admin Telecon Minutes B. Ganetsky
Abstract
Hosting us in Mendel University. We have great facilities available. All study group chairs should register their interest for their room usage at their earliest convenience. We will have a Sunday evening 6:00 PM introductory meeting, as usual. We will have a collective walk from the preferred hotel to the university at 5:30 PM. The usual pre-meeting “read all the papers” email, as soon as the min
› N5050 Working Draft, Programming Languages -- C++ T. Köppe
› N5051 Editors' Report, Programming Languages -- C++ T. Köppe
› N5053 WG21 2026-06 Brno Hybrid Meeting Minutes B. Ganetsky
Abstract
Nina Ranns presents. Every participant is responsible for understanding and abiding by the following:
› N5054 Working Draft, Programming Languages -- C++ T. Köppe
› N5055 Editors' Report, Programming Languages -- C++ T. Köppe
› P0260R20 C++ Concurrent Queues D. Vollmann , L. Crowl , C. Mysen , G. Nishanov
Abstract
Queues provide a mechanism for communicating data between components of a system.
› P0870R8 A proposal for a type trait to detect narrowing conversions G. D'Angelo
› P0876R24 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).
› P1040R11 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
› P1974R1 Persistent constexpr allocation J. Snyder
› P2019R9 Thread attributes C. Jabot
Disposition Date
2026-06
Abstract
Most operating systems, including real-time operating systems for embedded platforms, provide a way to name threads.
› P2034R8 Partially Mutable Lambda Captures R. McDougall , L. Garg
› P2287R6 Designated-initializers for base classes B. Revzin
Disposition Date
2026-06
Abstract
[[P0017R1]](https://wg21.link/p0017r1) extended aggregates to allow an aggregate to have a base class. [[P0329R4]](https://wg21.link/p0329r4) gave us designated initializers, which allow for much more expressive and functional initialization of aggregates. However, the two do not mix: a designated initializer can currently only refer to a direct non-static data members. This means that if I have a
› P2414R12 Pointer lifetime-end zap proposed solutions P. McKenney , M. Michael , J. Maurer , P. Sewell , M. Uecker , H. Boehm , H. Tong , N. Douglas , T. Rodgers , W. Deacon , M. Wong , D. Goldblatt , K. Serebryany , A. Williams , T. Scogland , J. Bastien , D. Krügler , D. Tenty
Author(s)
Paul E. McKenney , Maged Michael , Jens Maurer , Peter Sewell , Martin Uecker , Hans Boehm , Hubert Tong , Niall Douglas , Thomas Rodgers , Will Deacon , Michael Wong , David Goldblatt , Kostya Serebryany , Anthony Williams , Tom Scogland , JF Bastien , Daniel Krügler , David Tenty
Disposition Date
2026-06
Abstract
The C++ standard currently specifies that all pointers to an object become invalid at the end of its lifetime [basic.life]. Although this permits additional diagnostics and optimizations which might be of some value, it is not consistent with long-standing usage, especially for a range of concurrent and sequential algorithms that rely on loads, stores, equality comparisons, and even dereferencing
› P2434R5 Nondeterministic pointer provenance S. Herring
Disposition Date
2026-06
Abstract
[P2318R1](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2318r1.pdf) describes a variety of plausible models of pointer provenance that differ principally in how they handle conversions between pointers and integers (including the integer values of the storage bytes for a pointer). (See its §A.4 for discussion of the variants in terms of examples.) It proposes the variant called PNVI-ae-
› P2719R7 Type-aware allocation and deallocation functions L. Dionne , O. Hunt , V. Serebrennikov
Abstract
C++ currently provides two ways of customizing the creation of objects in new expressions. First, `operator new` can be provided as a static member function of a class, like `void* T::operator new`. If such a declaration is provided, an expression like `new T(...)` will use that allocation function. Otherwise, the global version of `operator new` can be replaced by users in a type-agnostic way, by
› P2721R1 Deprecating function in C++29 M. Hava
Abstract
**Poll:** Forward “P2721R0: Deprecating function” to LWG for C++26 (to be confirmed by an electronic poll).
› P2728R14 Unicode in the Library, Part 1: UTF Transcoding E. Nolan
› P2806R4 do expressions B. Revzin , B. Lopez , Z. Laine , M. Park
Abstract
C++ is a language built on statements. `if` is not an expression, loops aren’t expressions, statements aren’t expressions (except maybe in the specific case of `*expression*;`).
› P2826R4 Expression Aliases G. Ažman
Abstract
This paper introduces a way to rewrite a function call to a different expression without a forwarding layer.
› P2828R3 Copy elision for direct-initialization with a conversion function (Core issue 2327) B. Bi , N. Nguyen
› P2906R2 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 not
› P2953R5 Adding restrictions to defaulted assignment operator functions M. Taylor , A. O'Dwyer
Disposition Date
2026-06
Abstract
Currently, [[dcl.fct.def.default]/2.5](https://eel.is/c++draft/dcl.fct.def.default#2.5) permits an explicitly defaulted special member function to differ from the implicit one by adding *ref-qualifiers*, but not *cv-qualifiers*.
› P2956R3 Add saturating library support to std::simd D. Towner , R. Arutyunyan
Abstract
The Working Draft of C++26 includes data parallel types. It mostly provides operators which work on or with `std::simd` types, but it also includes overloads of useful functions from other parts of C++ (e.g., sin, cos, abs). In [P0543R3] a proposal was made to provide saturating operation support for some basic arithmetic operations and casts. In particular, `saturating_add`, `saturating_sub`, `sa
› P2964R5 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
› P3045R9 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 [[
› P3049R2 node-handles for lists M. Hava
Abstract
Node handles are an over-specified solution to the relatively simple problem of moving nodes between associative containers, which can be done with a more conservative interface similar to std::list::splice. There is a lack of consistency with std::list, where splicing and merging can be done but there is no node handle-based interface, yet lists are indeed node based, too. P00832 acknowledges the
› P3091R6 Better lookups for `map` , `unordered_map`, and `flat_map` P. Halpern
Disposition Date
2026-06
Abstract
The most convenient way to look up an element of a `map` -like container is to use the index operator, i.e., `theMap[key]` . This operator cannot be used, however, when 1) the container is `const` , 2) the mapped type is not default constructible, 3) the default-constructed value is inappropriate for the context, or 4) the container should not be modified. These limitations often force the user to
› P3097R3 Contracts for C++: Virtual functions T. Doumler , J. Berne , G. Ažman
Disposition Date
2026-06
Abstract
```cpp 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:
› P3099R3 Contracts for C++: User-defined diagnostic messages T. Doumler , P. Bindels , J. Berne
Abstract
* Updated Section 2.6 “Constant evaluation”; specified behaviour for unevaluated contexts, discarded contexts, SFINAE, and trial evaluation
› P3100R7 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.
› P3104R6 Bit permutations J. Schultke
Disposition Date
2026-06
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.
› P3125R6 constexpr pointer tagging H. Dusíková
Disposition Date
2026-06
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
› P3126R4 Graph Library: Overview P. Ratzloff , A. Lumsdaine
› P3127R2 Graph Library: Background and Terminology P. Ratzloff , A. Lumsdaine
› P3128R4 Graph Library: Algorithms P. Ratzloff , A. Lumsdaine
› P3129R2 Graph Library: Views P. Ratzloff , A. Lumsdaine
› P3130R4 Graph Library: Graph Container Interface P. Ratzloff , A. Lumsdaine
› P3154R3 Deprecating signed character types in iostreams E. Kosunen
› P3155R1 noexcept policy for SD-9 (The Lakos Rule) T. Doumler , J. Lakos
› P3161R6 Unified integer overflow arithmetic T. Freire
Abstract
Addition and uniformization of integer arithmetic functions with overflow behavior
› P3211R2 views::flat_map H. Kang
Abstract
We propose `views::flat_map`, a range adaptor that applies a function returning a range for each element, then flattens the result. This pattern, commonly known as *flat mapping*, is widespread in functional programming and data processing. Providing it as a dedicated view improves readability and expressiveness, and also opens opportunities for optimization in lazy evaluation contexts.
› P3216R3 views::slice H. Kang
Abstract
This paper proposes the Tier 1 adaptor `views::slice` (as described in [P2760](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2760r1.html)) to enhance the C++29 ranges library. Notably, this is the first standard range adaptor that accepts two arguments — `start` and `end` — to specify the interval [`start`, `end`) for slicing a range.
› P3220R3 views::take_before H. Kang
Abstract
This paper proposes the Tier 1 adaptor in [P2760](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2760r1.html): `views::delimit`, which is renamed into `views::take_before` along with its corresponding view class to improve the C++29 ranges facilities.
› P3230R3 views::unchecked_(take|drop) H. Kang
Abstract
This paper proposes two Tier 1 adaptors in [P2760](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2760r1.html): `views::unchecked_drop` and `views::unchecked_take`, cousins of `drop` and `take`, to improve the C++26 ranges facilities, which were renamed to `views::unchecked_take` and `views::unchecked_drop` after Tokyo WG21, as "unchecked" better describes the utility's nature than "exa
› P3242R4 Copy and fill for mdspan N. Morales , C. Trott , M. Hoemmen , D. Lebrun-Grandie
Disposition Date
2026-06
Abstract
C++23 introduced `mdspan` ([P0009R18]), a non-owning multidimensional array abstraction that has a customizable layout. Layout customization was originally motivated in [P0009R18] with considerations for interoperability and performance, particularly on different architectures. Moreover, [P2630R4] introduced `submdspan`, a slicing function that can yield arbitrarily strided layouts. However, witho
› P3248R5 Require [u]intptr_t G. Gadeschi
Disposition Date
2026-06
Abstract
Proposals like [P2835](https://wg21.link/p2835) and [P3125](https://wg21.link/P3125) use `[u]intptr_t` as an integer type capable of holding a pointer value in their APIs<sup>[1]</sup>. However, `[u]intptr_t` being *optional* forces sub-optimal design choices such as making APIs optional or introducing workarounds.
› P3290R6 Integrating Existing Assertions With Contracts J. Berne , T. Doumler , J. Lakos
Abstract
* Presenting feedback from SG22 on the `assert` macro choices, including new subsections on implementation-defined integration and throwing violation handlers
› P3296R6 let_async_scope A. Williams
› P3319R6 Add an iota object for simd (and more) M. Kretz
Disposition Date
2026-06
Abstract
There is one important constant in SIMD programming: `0,` `1,` `2,` `3,` `...`. In the standard library we have an algorithm called `iota` that can initialize a range with such values. For `simd` we want to have simple to spell constants that scale with the SIMD width. This paper proposes a simple facility that can be generalized.
› P3347R6 Invalid/Prospective Pointer Operations P. McKenney , M. Michael , J. Maurer , P. Sewell , M. Uecker , H. Boehm , H. Tong , N. Douglas , T. Rodgers , W. Deacon , M. Wong , D. Goldblatt , K. Serebryany , A. Williams , T. Scogland , J. Bastien , J. McGuiness , D. Tenty
Author(s)
Paul E. McKenney , Maged Michael , Jens Maurer , Peter Sewell , Martin Uecker , Hans Boehm , Hubert Tong , Niall Douglas , Thomas Rodgers , Will Deacon , Michael Wong , David Goldblatt , Kostya Serebryany , Anthony Williams , Tom Scogland , JF Bastien , Jason McGuiness , David Tenty
Disposition Date
2026-06
Abstract
The C++ standard currently specifies that all pointers to an object become invalid at the end of its lifetime [basic.life]. This is a software-engineering nightmare because **all** operations on invalid pointers are implementation-defined, even loads and stores. This means that concurrent algorithms such as LIFO Push that knowingly use invalid pointers must have (for example) converted such pointe
› P3367R5 constexpr coroutines H. Dusíková
Abstract
Currently C++'s [doesn't allow coroutines to be `constexpr`](https://eel.is/c++draft/dcl.constexpr#3.1). This limitation forces users to choose between having `constexpr` compatible library or (maybe) simpler coroutine interface. As a library author I do prefer `constexpr` but I do not want to make this decision.
› P3385R8 Attributes reflection A. Cassagnes
Abstract
Attributes are used to a great extent, and there is new attributes being added to the language somewhat regularly. As reflection makes its way into our standard, we are missing a way for generic code to look into the attributes appertaining to an entity. That is what this proposal aims to tackle by introducing the building blocks.
› P3395R6 Fix encoding issues and add a formatter for std::error_code V. Zverovich
Disposition Date
2026-06
Abstract
This paper proposes making `std::error_code` formattable using the formatting facility introduced in C++20 (`std::format`) and fixes encoding issues in the underlying API ([LWG4156]).
› P3400R4 Controlling Contract-Assertion Properties J. Berne
Abstract
* Major restructuring: new Introduction, Design, Glossary, expanded Standard Library Additions sections
› P3427R6 Hazard Pointer Synchronous Reclamation M. Michael , M. Wong , P. McKenney , M. Wever
Abstract
Hazard pointer interface from P2530R3 merged into the working draft (N5008):
› P3428R4 Hazard Pointer Batches M. Michael , M. Wong , P. McKenney
Disposition Date
2026-06
Abstract
This paper proposes extending the C++26 hazard pointer interface to support creation and destruction of batches of nonempty hazard pointers. This revision P3428R4 revises R3 by following LWG Brno 2026 feedback.
› P3505R4 Fix the default floating-point representation in std::format V. Zverovich , J. Jeon
Disposition Date
2026-06
Abstract
When `std::format` was proposed for standardization, floating-point formatting was defined in terms of `std::to_chars` to simplify specification. While being a positive change overall, this introduced a small but undesirable change compared to the design and reference implementation in [FMT], resulting in surprising behavior to users, performance regression and an inconsistency with other mainstre
› P3540R3 #embed Parameter offset J. Meneide
Disposition Date
2026-06
Abstract
The goal is to add the extremely-popular and already-implemented `gnu::offset` and `clang::offset` parameters as standard parameters. That is the only motivation of this proposal; to standardize existing practice.
› P3595R0 Configuration of Contract Evaluation Semantics J. Berne , I. Sandoe
› P3596R3 Undefined Behavior and IFNDR Annexes J. Berne , T. Doumler , J. Maurer , S. Yaghmour
Disposition Date
2026-06
Abstract
* Removed deep dive into organization possibilities, organized by clause, made UB and IFNDR descriptions subsection-like
› P3642R6 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 `+`.
› P3655R5 cstring_view P. Bindels , H. Dusikova , J. Rifkin , M. Foco , A. Shevlyakov
Abstract
We propose a standard string view type that guarantees null-termination.
› P3668R4 Defaulting Postfix Increment and Decrement Operations M. Taylor , A. (Waffl3x)
Disposition Date
2026-06
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
› P3669R4 Non-Blocking Support for `std::execution` D. Vollmann
Abstract
Some execution environments want to make sure that specific operations are non-blocking. These can not signal an event using the facilities of `std::execution` as currently specified as it doesn’t provide operations that are guaranteed to be non-blocking.
› P3670R4 Pack Indexing for Template Names C. Jabot
Disposition Date
2026-06
Abstract
We added the ability to index packs of types and expressions in C++26 through [P2662R3](https://wg21.link/P2662R3) [4]. ([P2662R3](https://wg21.link/P2662R3) [4] is now implemented in Clang and GCC, and we got very positive feedback).
› P3716R1 Subsetting P. Bindels
Abstract
As part of [Profiles](https://wg21.link/P4300) we should have the ability to express a particular feature to be removed from the language or library in a given environment, under a particular profile.
› P3741R1 views::set_operations H. Kang
Abstract
This paper proposes four range adaptors for set operations rated as Tier 3 in [P2760](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2760r1.html), namely `views::set_difference`, `views::set_intersection`, `views::set_union`, and `views::set_symmetric_difference`, to extend the breadth of Ranges.
› P3771R1 constexpr mutex, locks, and condition variable H. Dusíková
Abstract
It's really hard to conditionally avoid non-`constexpr` types in a code which is supposed to be `constexpr` compatible. This paper fixes it by making these types (and algorithms) `constexpr` compatible. There is no semantical change for updated types and algorithms.
› P3772R2 std::simd overloads for bit permutations J. Schultke
Disposition Date
2026-06
Abstract
[[P3104R4]](https://wg21%2elink/p3104r4) has been been design-approved by LEWG for C++29. During the discussion of the paper, it was *not* mentioned that [[P2933R4]](https://wg21%2elink/p2933r4) adds `std::simd` overloads for almost all functions in the `<bit>` header.
› P3785R1 Library Wording Changes for Defaulted Postfix Increment and Decrement Operators M. Taylor , A. (Waffl3x)
› P3790R2 Pointer lifetime-end zap proposed solutions: Bag-of-bits pointer class P. McKenney , M. Michael , J. Maurer , P. Sewell , H. Boehm , H. Tong , N. Douglas , T. Rodgers , W. Deacon , M. Wong , D. Goldblatt , K. Serebryany , A. Williams , T. Scogland , J. Bastien , D. Krügler , D. Tenty
Author(s)
Paul E. McKenney , Maged Michael , Jens Maurer , Peter Sewell , Hans Boehm , Hubert Tong , Niall Douglas , Thomas Rodgers , Will Deacon , Michael Wong , David Goldblatt , Kostya Serebryany , Anthony Williams , Tom Scogland , JF Bastien , Daniel Krügler , David Tenty
Abstract
The C++ standard currently specifies that all pointers to an object become invalid at the end of its lifetime [basic.life]. Although this permits additional diagnostics and optimizations which might be of some value, it is not consistent with long-standing usage, especially for a range of concurrent and sequential algorithms that rely on loads, stores, equality comparisons, and even dereferencing
› P3791R1 constexpr deterministic random H. Dusíková
Abstract
Algorithms `shuffle`, `sample` are useful even in compile time, same applies to random distribution types which are fully deterministic.
› P3793R2 Better shifting B. Bi , J. Schultke
Disposition Date
2026-06
Abstract
C++ has built-in shift operators, `<<` and `>>`, inherited from C with semantics essentially unchanged, including the following two inconvenient properties:
› P3806R1 views::cycle H. Kang
Abstract
This paper proposes adding `views::cycle`, a Tier 1 range adaptor as described in [P2760](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2760r1.html), to enhance the C++29 Ranges library by enabling infinite repetition of a range's elements.
› P3812R1 const and & in default member functions J. Waterloo
Abstract
Allow compilers to be able to generate the default copy assignment operator for classes that have `const` and `&` members by making the class `transparently replaceable` if it has a default copy constructor. Allow compilers to be able to generate the default move assignment operator for classes that have `const` and `&` members by making the class `transparently replaceable` if it has a default mo
› P3822R2 Conditional noexcept specifiers in compound requirements V. Luchkin , G. Ažman
Disposition Date
2026-06
Abstract
This paper extends compound requirements to allow noexcept specifiers to be applied conditionally. The proposed syntax for this is `requires { { *expression* } noexcept(*constant-expression*) -> *return-type-constraint*; }`.
› P3832R3 Timed lock algorithms for multiple lockables T. Lyngmo
Abstract
C++11 introduced `std::lock` and `std::try_lock` (and C++17 introduced `std::scoped_lock`) to simplify deadlock-free acquisition of multiple lockables. These algorithms support *BasicLockable* and *Lockable* objects, but there is currently no facility for timed acquisition of multiple *TimedLockable* objects.
› P3833R3 std::unique_multilock T. Lyngmo
Abstract
This paper proposes `std::multi_lock`, a RAII class template that combines the functionality of `std::unique_lock` and `std::scoped_lock`. Unlike `std::scoped_lock`, which provides only basic RAII semantics, `std::multi_lock` offers the full flexibility of `std::unique_lock` (deferred locking, try-lock operations, timed locking, and ownership transfer) while supporting multiple mutexes simultaneou
› P3847R1 Lexical order for lambdas S. Herring
› P3850R1 A proposed plan for extending Contracts in C++29 T. Doumler , J. Berne
Abstract
At the March 2026 WG21 meeting in Croydon, the ISO C++ committee completed the C++26 Standard, including the addition of *contract* assertions. This milestone is the result of a sustained effort by the authors of [[P2900R14](https://wg21.link/p2900r14)] and the WG21 subgroups responsible for evaluating the proposal: SG21, EWG, and CWG. This success was made possible in part by the existence of a c
› P3899R3 Clarify the behavior of floating-point overflow J. Schultke , M. Kretz
Disposition Date
2026-06
Abstract
The current specification of floating-point overflow is unclear. Floating-point overflow occurs when finite operands are used as operands, and the result cannot be represented as a finite value. For [[ISO/IEC 60559:2020]](https://www%2eiso%2eorg/standard/80985%2ehtml) floating-point numbers, this results in infinity.
› P3928R1 static_sized_range H. Kang
Abstract
This paper introduces `static_sized_range`, a refinement of `sized_range` for ranges whose sizes are known at compile time.
› P3935R2 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.
› P3950R1 return_value & return_void Are Not Mutually Exclusive R. Leahy
Disposition Date
2026-06
Abstract
The standard specifies the effect of `co_return` statements in terms of equivalent statements within the context of a *replacement body* (§9.6.4 [dcl.fct.def.coroutine]). Like a regular `return` statement `co_return` statements have two distinct forms: Those that return `void` and those that return some value. These are specified as follows (§8.8.5 [stmt.return.coroutine]):
› P3969R2 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:/
› P4030R1 Endian Views E. Nolan
Abstract
The main reason for adding these views is to assist users of the UTF transcoding range adaptors (see [[P2728R11]](https://wg21.link/p2728r11)). That paper introduces the adaptors `to_utf8`, `to_utf16`, and `to_utf32`, which take as input ranges of `char8_t`, `char16_t`, and `char32_t`. The input and output of these views use native endianness. But users often need to convert to and from UTF encodi
› P4033R1 Synthesizing enum at compile time with define_enum A. Cassagnes
Abstract
The generative capability of reflection as they were introduced in C++26 are limited to `define_aggregate`, with no quick paths to more powerful facilities (See [p3294r2] for example). We can already leverage `define_aggregate` to impressive effects (See a JSON parser [here](https://brevzin.github.io/c++/2025/06/26/json-reflection/)), here we introduce another basic and lightweight building block:
› P4040R1 Case ranges J. Schultke
Abstract
In 2024, [[N3370]](https://www%2eopen-std%2eorg/jtc1/sc22/wg14/www/docs/n3370%2ehtm) added support for `case` ranges to C2y. For example, the following two `switch` statements are equivalent:
› P4101R1 Consteval-only Values for C++26 B. Revzin , P. Dimov , D. Vandevoorde , D. Katz
Disposition Date
2026-06
Abstract
The Reflection design from [[P2996R13]](https://wg21.link/p2996r13) was based on a model of having consteval-only types to prevent reflections from leaking to runtime. But we’ve run into issues and limitations with that approach, so we propose that, for C++26, we change instead to a consteval-only value model. This solves the same problems, but has additional benefits.
› P4133R0 Should WG21 Even See This Paper? Admission Gates for Library and Language Proposals V. Falco
Intent
Inform
Abstract
The committee has never established a criterion for what belongs in the standard library. This paper supplies one.
› P4139R3 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
› P4148R2 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.
› P4157R1 LEWG Slides for P3666R4 J. Schultke
Abstract
C23 now has `_BitInt` type for N-bit integers (WG14 N2763, N2775):
› P4185R1 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
› P4188R1 Extensible Math Functions for C++ S. Gros-Lemesre
› P4217R1 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]):
› P4220R1 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 any decisions whether to even have it, or in what form, are made.
› P4221R3 Atomic Compare M. Michael , P. McKenney , M. Wong
Abstract
This paper proposes adding a `compare_load` member function to `std::atomic<T>` and `std::atomic_ref<T>`, alongside corresponding free functions. This function performs an atomic comparison of the atomic object's value with an expected value, following the same value representation comparison semantics as `compare_exchange_strong`. It updates the expected argument on failure, operating entirely as
› P4222R1 An initialization profile (R2) 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
› P4226R0 2026-05 Library Evolution Poll Outcomes I. Levi , F. Fracassi , A. Weis , C. Jabot
Abstract
In 2026-05, the C++ Library Evolution group conducted an electronic poll [[P4225R0]](https://wg21.link/P4225R0). This paper provides the results of this poll and summarizes the responses.
› P4234R2 $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):
› P4243R0 `zip()` Should Be Ill-formed H. Xie , T. Melen
Abstract
This paper proposes a fix that makes the `views::zip()` ill-formed instead of the current `views::empty<tuple<>>`.
› P4254R0 Throwing Violation Handlers Are Post Hoc Library Design R. Leahy
Abstract
The Lakos Rule [1] has long been treated as a trump card in LEWG: A proposal contains a function with a precondition which is declared `noexcept`, someone in the room invokes “the Lakos Rule,” and the function must presumptively be redesigned to remove the `noexcept`. This has impeded the adoption of `noexcept` in the library, and has led to arguably-ridiculous consequences (e.g. `std::vector::ope
› P4257R0 Marking wide contract non-throwing functions noexcept is not controversial N. Liber
Abstract
For C++11, LWG (there was no LEWG) was being very arbitrary about which non-throwing functions to mark `noexcept`.
› P4258R0 C++ Standard Library Ready Issues to be moved in Brno, Jun. 2026 J. Wakely
Disposition Date
2026-06
Abstract
- Ready Issues - 3417. Missing volatile atomic deprecations - 4125. move_iterator 's default constructor should be constrained - 4158. `packaged_task::operator=` should abandon its shared state - 4182. Definition of `NULL` is too broad - 4218. Constraint recursion in `basic_const_iterator`'s relational operators due to ADL + CWG 2369 - 4249. The past end issue for `lazy_split_view` - 4267. Uses-al
› P4259R0 The name of the floor division function should probably have floor in it B. Revzin
Abstract
In 1962, Kenneth Iverson introduced the names “floor” and “ceiling”, and the syntax `⌊x⌋` and `⌈x⌉`, for operations that return the greatest integer less than or equal to `x` and the smallest integer greater than or equal to `x`, respectively. Since then, these names have become broadly used in math and programming.
› P4261R0 Presentation for P4189 get()ing the pointer from optional N. Liber
› P4262R0 Design Considerations for Class Invariants J. Berne
› P4265R0 Presentation for P3655 in Brno P. Bindels
› P4266R0 Presentation for P3655 in Croydon P. Bindels
› P4268R0 Implementation considerations of library constexpr-ification L. Dionne
Abstract
A wave of recent proposals targets parts of the standard library for `constexpr`-ification. Some of them have already been adopted in C++26, others are being considered for C++29. These papers are often perceived as straightforward, since they are only sprinkling `constexpr` around the standard library. However, in practice, these papers may involve subtle tradeofs for standard libraries and their
› P4269R0 when_all Oughtn't Hallucinate set_stopped R. Leahy
Abstract
When `std::execution::when_all` is provided with multiple senders it becomes possible that:
› P4271R0 Core Language Working Group "ready" Issues for the June, 2026 meeting J. Maurer
› P4275R0 EWG presentation for P3400R4 J. Berne
› P4276R0 A Policy for Scalar Overloads in std::simd D. Towner
Abstract
`std::simd` includes scalar overloads for a few operations where variants of a function or operator accept a scalar where a `simd::vec` value would otherwise be expected. Recent papers continue this theme, with better shifts [P3793R1] and funnel shifts [P4010R0] adding scalar-operand variants. This has inadvertently created an expectation that every new operation should provide scalar overloads to
› P4279R0 No Endian Views J. Schultke
Abstract
The design direction of [[P4030R1]](https://isocpp%2eorg/files/papers/P4030R1%2ehtml) Endian Views should not be pursued.
› P4281R0 Type Aliases in Requires-Expressions H. Kang
Abstract
This paper proposes extending the syntax of `requires`-expressions to allow `using`-type aliases within the requirement body.
› P4282R0 Away From co_yield For std::execution::task R. Leahy
Abstract
The coroutine promise protocol shipped in C++20 not only banned `return_void` and `return_value` on the same promise type, but did so in an unusually restrictive manner [1]. Notably the aforementioned manner barred implementing the aforementioned mutual exclusion via mutually exclusive constraints.
› P4283R0 Requires clauses for Contract Assertions J. Berne
› P4288R0 Stop the Decay R. Leahy
Abstract
`std::execution` can be thought of as the realization of the asynchronous analogue of a synchronous function [1][2]. The sender is the function itself (with all arguments selected and applied), the receiver is the channel by which the function communicates with its caller (in the synchronous realm by returning or throwing), and the operation state is the “stack” (i.e. a collection of variables wit
› P4291R0 views::unique H. Kang
Abstract
This paper proposes a range adaptor `views::unique` that filters out consecutive equivalent elements from a range, leaving only one element from each group of consecutive equivalent elements. This adaptor complements the existing `std::unique` algorithm by providing a composable, lazy, and allocation-free view for a common filtering operation.
› P4293R0 std::execution::decay_copy R. Leahy
Abstract
* Allows for asynchronous operations which advertise ref-qualified completions, and
› P4294R0 views::take_last and views::drop_last H. Kang
Abstract
This paper proposes two new range adaptors, `views::take_last` and `views::drop_last`, that respectively produce the last *N* elements of a range and all-but-the-last *N* elements of a range. They mirror the shape of the existing `views::take` / `views::drop` adaptors and fill an obvious gap in the standard range adaptor set.
› P4295R0 Single Ends for C++ Concurrent Queues D. Vollmann
Abstract
[P0260](https://wg21.link/P0260) proposes concurent queue concepts as communication mechanism for concurrent systems. This communication is typically uni-directional, i.e. a specifc part of a system is either a producer and therefore only needs the pushing interface, or it is a consumer and only needs access to the pop interface.
› P4296R0 Default-Deny + Provable-Whitelist Invalidation G. Davidson , S. Bracco
› P4297R0 Severing P3100's Profiles Claim from Its Case-by-Case Review V. Falco , V. Voutilainen
Intent
Ask
Abstract
This paper asks EWG (the Evolution Working Group) to sever an unadopted architecture claim from the wording it is bundled with, so that the wording proceeds and the claim gets its own paper and poll.
› P4298R0 Nonthrowing Evaluation Semantics J. Berne
› P4302R0 Require One Published Mailing Before Any Poll V. Falco
Intent
Ask
Abstract
The committee takes recorded polls on paper revisions that were never published in a mailing.
› P4304R0 Zero-Copy `co_return` Y. Chen
Abstract
For a plain function, `auto v = foo();` constructs the result directly into `v`: mandatory copy elision has made the value path of ordinary calls zero-copy since C++17. The equivalent coroutine code
› P4305R0 Design problems with P2964R5 (User-defined element types in std::simd) J. Schultke
Abstract
This paper discusses some design problems in [[P2964R5]](https://isocpp%2eorg/files/papers/P2964R5%2ehtml).
› P4306R0 Configuring Runtime Checking: Profiles and Implicit Contract Assertions V. Falco , V. Voutilainen
Intent
Inform
Abstract
Measured against the committee's own criteria, none of them awards ownership of runtime-checking configuration to either proposal.
› P4308R0 Eight Responses to a Throwing Implicit Contract Assertion V. Falco , V. Voutilainen
Intent
Inform
Abstract
The response space for a throwing implicit contract assertion contains at least eight options, not the four before EWG.
› P4309R0 Constructing owning node-handles without containers M. Hava
Abstract
Whilst the existing `node-handle` API works fairly well, there is one annoyance we’ve encountered multiple times: being unable to directly create an owning `node-handle` without constructing a container. Creating a container just to emplace one element that is immediately extracted, after which the container is destroyed is silly … yet is necessary with the current API, if a separation from the ta
› P4310R0 Hasta la Vista, Undefined Behavior: Why Implicit Contract Violations Should Terminate V. Falco , V. Voutilainen
Intent
Inform
Abstract
For a detected core-language violation, the terminating response - invoke the handler, then terminate - is the default the evidence supports.
› P4311R0 Getting a const element type version of an mdspan accessor, and of an mdspan too M. Hoemmen , R. Parolin
Abstract
Given an accessor `a` of type `A`, a “const element type version of `a`” (if it exists) is an accessor `b` of a possibly different type `B`, where
› P4312R0 Effect Sets: A Composable, Generalized noexcept for C++ M. Galuszka
Abstract
For hard real-time paths, latency-critical middleware, and freestanding code, the decisive interface question is not *“what does this function compute?”* but *“which*
› P4313R0 Bitmask operations for enums I. Guterman , A. Williams
Abstract
As a developer coming from languages other than C++, I grew accustomed to using enums to represent flags. However, such behavior is noticeably absent from the C++ language.
› P4314R0 On Activating a Profile P. Bindels
Abstract
Profiles being active has a distinct effect on a translation unit being compiled. When contemplating the effect it has on a translation unit, users often perceive everything being proposed in a profile paper to be done only when the profile is active, leading to common misconceptions about what switching a profile can do. Terms I have heard from a dozen different interactions are dialecting, epoch
› P4315R0 A Profile Template P. Bindels
Abstract
Each profile is introduced with a particular goal in mind. Explain what the profile does, what goals it sets out to achieve, what kind of effect it is expected to have on existing and new code. Explain what kind of users are being considered in proposing the profile and how they are helped by this profile.
› P4316R0 A Skeleton Document for Profiles P. Bindels
Abstract
Profiles are the incremental approach to making code provide more safety guarantees, beyond what can be accomplished by modifying the base language.
› P4317R0 A Profile for Runtime-Checkable Core-Language Undefined Behavior: std::core_ub V. Falco
Intent
Propose
Abstract
The runtime-checkable cases of core-language undefined behavior can be guarded by a single standard profile, with none of the changes to the definitional machinery of the standard that a Contracts-based routing would require.
› P4318R0 Transient Benefit, Perpetual Cost: Implicit Core-Language Assertions V. Falco
Intent
Inform
Abstract
Standardizing a continuing (log-and-continue) response for implicit contract assertions on core-language undefined behavior, as a portable guarantee every implementation carries, returns less than it costs.
› P4320R0 std::execution::sequence R. Leahy
Abstract
`sequence` adapts any number of input senders into a sender which completes when all input senders have completed, with each input sender’s asynchronous operation being started only after the completion of the preceding input sender’s asynchronous operation.
