› 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
› P2034R8 Partially Mutable Lambda Captures R. McDougall , L. Garg
› 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
› P2828R3 Copy elision for direct-initialization with a conversion function (Core issue 2327) B. Bi , N. Nguyen
› 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*.
› 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:
› 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.
› 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
› 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
› 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).
› 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
› P3847R1 Lexical order for lambdas S. Herring
› 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.
› 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]):
› 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.
› P4271R0 Core Language Working Group "ready" Issues for the June, 2026 meeting J. Maurer
› 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.
