› P0876R24 fiber_context - fibers without scheduler
Oliver Kowalke
O. Kowalke
,
Nat Goodspeed
N. Goodspeed
2026-07
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
JeanHeyd Meneide
J. Meneide
2026-07
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
Ryan McDougall
R. McDougall
,
Lakshay Garg
L. Garg
2026-07
› P2434R5 Nondeterministic pointer provenance
S. Davis Herring
S. Herring
2026-07
Disposition Date
2026-06Adopted
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
Louis Dionne
L. Dionne
,
Oliver Hunt
O. Hunt
,
Vlad Serebrennikov
V. Serebrennikov
2026-07
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)
Brian Bi
B. Bi
,
Nhat Nguyen
N. Nguyen
2026-07
› P2953R5 Adding restrictions to defaulted assignment operator functions
Matthew Taylor
M. Taylor
,
Arthur O'Dwyer
A. O'Dwyer
2026-07
Disposition Date
2026-06Adopted
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
Timur Doumler
T. Doumler
,
Joshua Berne
J. Berne
,
Gašper Ažman
G. Ažman
2026-07
Disposition Date
2026-06Adopted
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
Paul E. McKenney
P. McKenney
,
Maged Michael
M. Michael
,
Jens Maurer
J. Maurer
,
Peter Sewell
P. Sewell
,
Martin Uecker
M. Uecker
,
Hans Boehm
H. Boehm
,
Hubert Tong
H. Tong
,
Niall Douglas
N. Douglas
,
Thomas Rodgers
T. Rodgers
,
Will Deacon
W. Deacon
,
Michael Wong
M. Wong
,
David Goldblatt
D. Goldblatt
,
Kostya Serebryany
K. Serebryany
,
Anthony Williams
A. Williams
,
Tom Scogland
T. Scogland
,
JF Bastien
J. Bastien
,
Jason McGuiness
J. McGuiness
,
David Tenty
D. Tenty
2026-07
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-06Adopted
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
Hana Dusíková
H. Dusíková
2026-07
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
Joshua Berne
J. Berne
,
Timur Doumler
T. Doumler
,
Jens Maurer
J. Maurer
,
Shafik Yaghmour
S. Yaghmour
2026-07
Disposition Date
2026-06Adopted
Abstract
* Removed deep dive into organization possibilities, organized by clause, made UB and IFNDR descriptions subsection-like
› P3668R4 Defaulting Postfix Increment and Decrement Operations
Matthew Taylor
M. Taylor
,
Alex (Waffl3x)
A. (Waffl3x)
2026-07
Disposition Date
2026-06Adopted
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
Corentin Jabot
C. Jabot
2026-07
Disposition Date
2026-06Adopted
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
Jarrad J Waterloo
J. Waterloo
2026-07
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. Davis Herring
S. Herring
2026-07
Disposition Date
2026-06Adopted
› P3899R3 Clarify the behavior of floating-point overflow
Jan Schultke
J. Schultke
,
Matthias Kretz
M. Kretz
2026-07
Disposition Date
2026-06Adopted
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
Robert Leahy
R. Leahy
2026-07
Disposition Date
2026-06Adopted
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
Barry Revzin
B. Revzin
,
Peter Dimov
P. Dimov
,
Daveed Vandevoorde
D. Vandevoorde
,
Dan Katz
D. Katz
2026-07
Disposition Date
2026-06Adopted
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
Jens Maurer
J. Maurer
2026-07
Disposition Date
2026-06Adopted
› P4281R0 Type Aliases in Requires-Expressions
Hewill Kang
H. Kang
2026-07
Abstract
This paper proposes extending the syntax of `requires`-expressions to allow `using`-type aliases within the requirement body.
