› N5048 2026-06 WG21 Admin telecon
Guy Davidson
G. Davidson
2026-07
› N5049 WG21 2026-06 Brno Admin Telecon Minutes
Braden Ganetsky
B. Ganetsky
2026-07
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++
Thomas Köppe
T. Köppe
2026-07
› N5051 Editors' Report, Programming Languages -- C++
Thomas Köppe
T. Köppe
2026-07
› N5053 WG21 2026-06 Brno Hybrid Meeting Minutes
Braden Ganetsky
B. Ganetsky
2026-07
Abstract
Nina Ranns presents. Every participant is responsible for understanding and abiding by the following:
› N5054 Working Draft, Programming Languages -- C++
Thomas Köppe
T. Köppe
2026-07
› N5055 Editors' Report, Programming Languages -- C++
Thomas Köppe
T. Köppe
2026-07
› P0260R20 C++ Concurrent Queues
Detlef Vollmann
D. Vollmann
,
Lawrence Crowl
L. Crowl
,
Chris Mysen
C. Mysen
,
Gor Nishanov
G. Nishanov
2026-07
Abstract
Queues provide a mechanism for communicating data between components of a system.
› P0870R8 A proposal for a type trait to detect narrowing conversions
Giuseppe D'Angelo
G. D'Angelo
2026-07
› 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
› P1974R1 Persistent constexpr allocation
Jeff Snyder
J. Snyder
2026-07
› P2019R9 Thread attributes
Corentin Jabot
C. Jabot
2026-07
Disposition Date
2026-06Adopted
Abstract
Most operating systems, including real-time operating systems for embedded platforms, provide a way to name threads.
› P2034R8 Partially Mutable Lambda Captures
Ryan McDougall
R. McDougall
,
Lakshay Garg
L. Garg
2026-07
› P2287R6 Designated-initializers for base classes
Barry Revzin
B. Revzin
2026-07
Disposition Date
2026-06Adopted
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
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
,
Daniel Krügler
D. Krügler
,
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 , Daniel Krügler , 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]. 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. 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
› P2721R1 Deprecating function in C++29
Michael Florian Hava
M. Hava
2026-07
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
Eddie Nolan
E. Nolan
2026-07
› P2806R4 do expressions
Barry Revzin
B. Revzin
,
Bruno Cardoso Lopez
B. Lopez
,
Zach Laine
Z. Laine
,
Michael Park
M. Park
2026-07
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
Gašper Ažman
G. Ažman
2026-07
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)
Brian Bi
B. Bi
,
Nhat Nguyen
N. Nguyen
2026-07
› P2906R2 Structured bindings for std::extents
Bernhard Manfred Gruber
B. Gruber
,
Yihan Wang
Y. Wang
,
Mark Hoemmen
M. Hoemmen
2026-07
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
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*.
› P2956R3 Add saturating library support to std::simd
Daniel Towner
D. Towner
,
Ruslan Arutyunyan
R. Arutyunyan
2026-07
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
Daniel Towner
D. Towner
,
Ruslan Arutyunyan
R. Arutyunyan
2026-07
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
Mateusz Pusz
M. Pusz
,
Dominik Berner
D. Berner
,
Johel Ernesto Guerrero Peña
J. Peña
,
Charles Hogg
C. Hogg
,
Nicolas Holthaus
N. Holthaus
,
Roth Michaels
R. Michaels
,
Vincent Reverdy
V. Reverdy
2026-07
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
Michael Florian Hava
M. Hava
2026-07
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`
Pablo Halpern
P. Halpern
2026-07
Disposition Date
2026-06Adopted
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
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:
› P3099R3 Contracts for C++: User-defined diagnostic messages
Timur Doumler
T. Doumler
,
Peter Bindels
P. Bindels
,
Joshua Berne
J. Berne
2026-07
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
Timur Doumler
T. Doumler
,
Joshua Berne
J. Berne
2026-07
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
Jan Schultke
J. Schultke
2026-07
Disposition Date
2026-06Adopted
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
Hana Dusíková
H. Dusíková
2026-07
Disposition Date
2026-06Adopted
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
Phil Ratzloff
P. Ratzloff
,
Andrew Lumsdaine
A. Lumsdaine
2026-07
› P3127R2 Graph Library: Background and Terminology
Phil Ratzloff
P. Ratzloff
,
Andrew Lumsdaine
A. Lumsdaine
2026-07
› P3128R4 Graph Library: Algorithms
Phil Ratzloff
P. Ratzloff
,
Andrew Lumsdaine
A. Lumsdaine
2026-07
› P3129R2 Graph Library: Views
Phil Ratzloff
P. Ratzloff
,
Andrew Lumsdaine
A. Lumsdaine
2026-07
› P3130R4 Graph Library: Graph Container Interface
Phil Ratzloff
P. Ratzloff
,
Andrew Lumsdaine
A. Lumsdaine
2026-07
› P3154R3 Deprecating signed character types in iostreams
Elias Kosunen
E. Kosunen
2026-07
Disposition Date
2026-06Adopted
› P3155R1 noexcept policy for SD-9 (The Lakos Rule)
Timur Doumler
T. Doumler
,
John Lakos
J. Lakos
2026-07
› P3161R6 Unified integer overflow arithmetic
Tiago Freire
T. Freire
2026-07
Abstract
Addition and uniformization of integer arithmetic functions with overflow behavior
› P3211R2 views::flat_map
Hewill Kang
H. Kang
2026-07
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
Hewill Kang
H. Kang
2026-07
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
Hewill Kang
H. Kang
2026-07
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)
Hewill Kang
H. Kang
2026-07
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
Nicolas Morales
N. Morales
,
Christian Trott
C. Trott
,
Mark Hoemmen
M. Hoemmen
,
Damien Lebrun-Grandie
D. Lebrun-Grandie
2026-07
Disposition Date
2026-06Adopted
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
Gonzalo Brito Gadeschi
G. Gadeschi
2026-07
Disposition Date
2026-06Adopted
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
Joshua Berne
J. Berne
,
Timur Doumler
T. Doumler
,
John Lakos
J. Lakos
2026-07
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
Anthony Williams
A. Williams
2026-07
› P3319R6 Add an iota object for simd (and more)
Matthias Kretz
M. Kretz
2026-07
Disposition Date
2026-06Adopted
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
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.
› P3385R8 Attributes reflection
Aurelien Cassagnes
A. Cassagnes
2026-07
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
Victor Zverovich
V. Zverovich
2026-07
Disposition Date
2026-06Adopted
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
Joshua Berne
J. Berne
2026-07
Abstract
* Major restructuring: new Introduction, Design, Glossary, expanded Standard Library Additions sections
› P3427R6 Hazard Pointer Synchronous Reclamation
Maged Michael
M. Michael
,
Michael Wong
M. Wong
,
Paul McKenney
P. McKenney
,
Mark de Wever
M. Wever
2026-07
Abstract
Hazard pointer interface from P2530R3 merged into the working draft (N5008):
› P3428R4 Hazard Pointer Batches
Maged Michael
M. Michael
,
Michael Wong
M. Wong
,
Paul McKenney
P. McKenney
2026-07
Disposition Date
2026-06Adopted
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
Victor Zverovich
V. Zverovich
,
Junekey Jeon
J. Jeon
2026-07
Disposition Date
2026-06Adopted
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
JeanHeyd Meneide
J. Meneide
2026-07
Disposition Date
2026-06Adopted
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
Joshua Berne
J. Berne
,
Iain Sandoe
I. Sandoe
2026-07
› 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
› P3642R6 Carry-less product: std::clmul
Jan Schultke
J. Schultke
2026-07
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
Peter Bindels
P. Bindels
,
Hana Dusikova
H. Dusikova
,
Jeremy Rifkin
J. Rifkin
,
Marco Foco
M. Foco
,
Alexey Shevlyakov
A. Shevlyakov
2026-07
Abstract
We propose a standard string view type that guarantees null-termination.
› 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
› P3669R4 Non-Blocking Support for `std::execution`
Detlef Vollmann
D. Vollmann
2026-07
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
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).
› P3716R1 Subsetting
Peter Bindels
P. Bindels
2026-07
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
Hewill Kang
H. Kang
2026-07
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
Hana Dusíková
H. Dusíková
2026-07
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
Jan Schultke
J. Schultke
2026-07
Disposition Date
2026-06Adopted
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
Matthew Taylor
M. Taylor
,
Alex (Waffl3x)
A. (Waffl3x)
2026-07
Disposition Date
2026-06Adopted
› P3790R2 Pointer lifetime-end zap proposed solutions: Bag-of-bits pointer class
Paul E. McKenney
P. McKenney
,
Maged Michael
M. Michael
,
Jens Maurer
J. Maurer
,
Peter Sewell
P. Sewell
,
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
,
Daniel Krügler
D. Krügler
,
David Tenty
D. Tenty
2026-07
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
Hana Dusíková
H. Dusíková
2026-07
Abstract
Algorithms `shuffle`, `sample` are useful even in compile time, same applies to random distribution types which are fully deterministic.
› P3793R2 Better shifting
Brian Bi
B. Bi
,
Jan Schultke
J. Schultke
2026-07
Disposition Date
2026-06Adopted
Abstract
C++ has built-in shift operators, `<<` and `>>`, inherited from C with semantics essentially unchanged, including the following two inconvenient properties:
› P3806R1 views::cycle
Hewill Kang
H. Kang
2026-07
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
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
› P3822R2 Conditional noexcept specifiers in compound requirements
Viacheslav Luchkin
V. Luchkin
,
Gašper Ažman
G. Ažman
2026-07
Disposition Date
2026-06Adopted
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
Ted Lyngmo
T. Lyngmo
2026-07
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
Ted Lyngmo
T. Lyngmo
2026-07
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. Davis Herring
S. Herring
2026-07
Disposition Date
2026-06Adopted
› P3850R1 A proposed plan for extending Contracts in C++29
Timur Doumler
T. Doumler
,
Joshua Berne
J. Berne
2026-07
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
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.
› P3928R1 static_sized_range
Hewill Kang
H. Kang
2026-07
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
Jan Schultke
J. Schultke
2026-07
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
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]):
› P3969R2 Fixing std::bit_cast of types with padding bits
Jan Schultke
J. Schultke
2026-07
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
Eddie Nolan
E. Nolan
2026-07
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
Aurelien Cassagnes
A. Cassagnes
2026-07
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
Jan Schultke
J. Schultke
2026-07
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
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.
› P4133R0 Should WG21 Even See This Paper? Admission Gates for Library and Language Proposals
Vinnie Falco
V. Falco
2026-07
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
Nathan Myers
N. Myers
,
Pablo Halpern
P. Halpern
2026-07
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++
Jonathan B. Coe
J. Coe
,
Hana Dusikova
H. Dusikova
,
Antony Peacock
A. Peacock
,
Philip Craig
P. Craig
,
Neelofer Banglawala
N. Banglawala
2026-07
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
Jan Schultke
J. Schultke
2026-07
Abstract
C23 now has `_BitInt` type for N-bit integers (WG14 N2763, N2775):
› P4185R1 Completing the Mathematical Model for C++ Quantities and Units
Mateusz Pusz
M. Pusz
2026-07
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++
Stephane Gros-Lemesre
S. Gros-Lemesre
2026-07
› P4217R1 when_all() is just just()
Robert Leahy
R. Leahy
2026-07
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
Andrzej Krzemieński
A. Krzemieński
2026-07
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
Maged Michael
M. Michael
,
Paul McKenney
P. McKenney
,
Michael Wong
M. Wong
2026-07
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)
Bjarne Stroustrup
B. Stroustrup
2026-07
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
Inbal Levi
I. Levi
,
Fabio Fracassi
F. Fracassi
,
Andreas Weis
A. Weis
,
Corentin Jabot
C. Jabot
2026-07
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
Matthias Wippich
M. Wippich
,
Murat Can Çağrı
M. Çağrı
2026-07
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
Hui Xie
H. Xie
,
Tristan Melen
T. Melen
2026-07
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
Robert Leahy
R. Leahy
2026-07
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
Nevin Liber
N. Liber
2026-07
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
Jonathan Wakely
J. Wakely
2026-07
Disposition Date
2026-06Adopted
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
Barry Revzin
B. Revzin
2026-07
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
Nevin Liber
N. Liber
2026-07
› P4262R0 Design Considerations for Class Invariants
Joshua Berne
J. Berne
2026-07
› P4265R0 Presentation for P3655 in Brno
Peter Bindels
P. Bindels
2026-07
› P4266R0 Presentation for P3655 in Croydon
Peter Bindels
P. Bindels
2026-07
› P4268R0 Implementation considerations of library constexpr-ification
Louis Dionne
L. Dionne
2026-07
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
Robert Leahy
R. Leahy
2026-07
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
Jens Maurer
J. Maurer
2026-07
Disposition Date
2026-06Adopted
› P4275R0 EWG presentation for P3400R4
Joshua Berne
J. Berne
2026-07
› P4276R0 A Policy for Scalar Overloads in std::simd
Daniel Towner
D. Towner
2026-07
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
Jan Schultke
J. Schultke
2026-07
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
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.
› P4282R0 Away From co_yield For std::execution::task
Robert Leahy
R. Leahy
2026-07
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
Joshua Berne
J. Berne
2026-07
› P4288R0 Stop the Decay
Robert Leahy
R. Leahy
2026-07
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
Hewill Kang
H. Kang
2026-07
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
Robert Leahy
R. Leahy
2026-07
Abstract
* Allows for asynchronous operations which advertise ref-qualified completions, and
› P4294R0 views::take_last and views::drop_last
Hewill Kang
H. Kang
2026-07
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
Detlef Vollmann
D. Vollmann
2026-07
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
Guy Davidson
G. Davidson
,
Sherry Ignatchenko; Dmytro Ivanchykhin; Marcos Bracco
S. Bracco
2026-07
› P4297R0 Severing P3100's Profiles Claim from Its Case-by-Case Review
Vinnie Falco
V. Falco
,
Ville Voutilainen
V. Voutilainen
2026-07
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
Joshua Berne
J. Berne
2026-07
› P4302R0 Require One Published Mailing Before Any Poll
Vinnie Falco
V. Falco
2026-07
Intent
Ask
Abstract
The committee takes recorded polls on paper revisions that were never published in a mailing.
› P4304R0 Zero-Copy `co_return`
Yuxuan Chen
Y. Chen
2026-07
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)
Jan Schultke
J. Schultke
2026-07
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
Vinnie Falco
V. Falco
,
Ville Voutilainen
V. Voutilainen
2026-07
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
Vinnie Falco
V. Falco
,
Ville Voutilainen
V. Voutilainen
2026-07
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
Michael Florian Hava
M. Hava
2026-07
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
Vinnie Falco
V. Falco
,
Ville Voutilainen
V. Voutilainen
2026-07
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
Mark Hoemmen
M. Hoemmen
,
Rob Parolin
R. Parolin
2026-07
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++
Michael Galuszka
M. Galuszka
2026-07
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
Iliya Guterman
I. Guterman
,
Anthony Williams
A. Williams
2026-07
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
Peter Bindels
P. Bindels
2026-07
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
Peter Bindels
P. Bindels
2026-07
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
Peter Bindels
P. Bindels
2026-07
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
Vinnie Falco
V. Falco
2026-07
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
Vinnie Falco
V. Falco
2026-07
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
Robert Leahy
R. Leahy
2026-07
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.
