› P1040R10 std::embed and #depend J. Meneide
Abstract
> I’m very keen on std::embed. I’ve been hand-embedding data in executables for NEARLY FORTY YEARS now. — Guy "Hatcat" Davidson, June 15, 2018
› P2728R12 Unicode in the Library, Part 1: UTF Transcoding E. Nolan
› P2906R1 Structured bindings for std::extents B. Gruber , Y. Wang , M. Hoemmen
Abstract
[[P0009R18]](https://wg21.link/p0009r18) proposed `std::mdspan` , which was approved for C++23. It comes with the utility class template `std::extents` to describe the integral extents of a multidimensional index space. Practically, `std::extents` models an array of integrals, where some of the values can be specified at compile-time. However, `std::extents` behaves very little like an array. A no
› P2929R4 chunked_invoke D. Towner , R. Arutyunyan
Abstract
ISO/IEC 19570:2018 introduced data-parallel types to the C++ Extensions for Parallelism TS [P1928R15]. That paper, and several ancillary papers, do an excellent job of setting out the main features of an extension to C++ which allows generic data parallel programming on arbitrary targets. However, it is inevitable that the programmer will want to make some use of target-specific intrinsics, or cal
› P2964R4 Allowing user-defined types in std::simd D. Towner , R. Arutyunyan
Abstract
The C++ standard library includes data-parallel types in the `<simd>` header, currently restricting element types to a closed list of *built-in vectorizable* types: arithmetic types and `std::complex` specializations. This paper proposes a minimal change to the specification in which this list is extended. Firstly, `std::byte` is added to the closed list as a standard library type with fixed seman
› P3045R8 Quantities and units library M. Pusz , D. Berner , J. Peña , C. Hogg , N. Holthaus , R. Michaels , V. Reverdy
Abstract
Several groups in the ISO C++ Committee reviewed the “P1935: A C++ Approach to Physical Units” [[P1935R2]](https://wg21.link/p1935r2) proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potential standardization of such a library and encouraged further work. The authors also got valuable initial feedback that highly influenced the design of the V2 version of the [[
› P3098R2 Contracts for C++: Postcondition captures T. Doumler , G. Ažman , J. Berne
Abstract
We propose to add a new, optional syntactic construct to postcondition assertions, called *postcondition* captures. Postcondition captures are spelled in the same fashion as lambda captures. They are placed immediately after the `post` contextual keyword and before the predicate: `post [``captures``] (``predicate``)` Postcondition captures are variables constructed when the function is called. The
› P3100R6 A framework for systematically addressing undefined behaviour in the C++ Standard T. Doumler , J. Berne
Abstract
In this paper, we enumerate all cases of core language undefined behaviour explicitly specified in the C++ Standard, group them into ten categories, and classify them along a number of relevant criteria.
› P3125R5 constexpr pointer tagging H. Dusíková
Abstract
Pointer tagging is widely known and used technique ([Glasgow Haskell Compiler](https://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf), LLVM's `[PointerIntPair](https://github.com/llvm/llvm-project/blob/8e5aa538caccef167e8096b2173fdaf2be9cc129/llvm/include/llvm/ADT/PointerIntPair.h#L80)`, `[PointerUnion](https://github.com/llvm/llvm-project/blob/8e5aa538caccef167e8096b2173fdaf2be9cc12
› P3290R4 Integrating Existing Assertions With Contracts J. Berne , T. Doumler , J. Lakos
Abstract
**–** Specified use of `source_location::current()` and discussed implementation choices
› P3351R4 views::scan Y. Li
Abstract
The motivation for this view is given in [P2760R1] and quoted below for convenience:
› P3377R0 constexpr `reinterpret_cast` partial replacements H. Dusíková , G. Ažman
Abstract
| functionality | runtime only (current status) | runtime & constexpr compatible replacement | status | | --- | --- | --- | --- | | pointer ↔︎ integer | `intptr_t * iptr = reinterpret_cast<intptr_t>(ptr); auto * optr = reinterpret_cast<pointer>(iptr);` | — | not proposed | | pointer tagging | `auto tptr = reinterpret_cast<pointer>( reinterpret_cast<intptr_t>(ptr) \| 0b1u); auto tag = static_cast<b
› P3411R6 `any_view` H. Xie , S. Yilmaz , L. Dionne , P. Roberts
Abstract
This paper proposes a new type-erased view: `std::ranges::any_view`. That type-erased view allows customizing the traversal category of the view, its value type and a few other properties. For example:
› P3427R4 Hazard Pointer Synchronous Reclamation M. Michael , M. Wong , P. McKenney , M. Wever
Abstract
This paper proposes extending the C++26 hazard pointer interface to support synchronous reclamation. This revision, P3427R4, revises R3 by following LEWG Croydon 2026 feedback.
› P3642R5 Carry-less product: std::clmul J. Schultke
Abstract
[Carry-less multiplication](https://en.wikipedia.org/wiki/Carry-less_product) is a simple numerical operation on unsigned integers. It can be a seen as a regular multiplication where `xor` is being used as a reduction instead of `+`.
› P3666R4 Bit-precise integers J. Schultke
Abstract
In distant history, there have been various attempts at standardizing multi-precision integers in C++, such as [[N1692]](https://wg21%2elink/n1692) "A Proposal to add the Infinite Precision Integer to the C++ Standard Library", [[N1744]](https://wg21%2elink/n1744) "Big Integer Library Proposal for C++0x", and [[N4038]](https://wg21%2elink/n4038) "Proposal for Unbounded-Precision Integer Types", al
› P3724R4 Integer division J. Schultke
Abstract
C++ currently only offers truncating integer division in the form of the `/` operator. However, other rounding modes have various use cases too, and implementing these as the user can be surprisingly hard, especially when integer overflow needs to be avoided, and negative inputs are accepted.
› P3729R1 Aligning span and string_view M. Hava
Abstract
```cpp template<typename T, size_type E = dynamic_extent> struct span { … //runtime subsetting: constexpr span subspan(size_type pos = 0, size_type n = dynamic_extent) const; constexpr span first(size_type count) const; constexpr span last(size_type count) const; … }; template<typename charT, typename traits = char_traits<charT>> struct basic_string_view { … //in place shrinking: constexpr void re
› P3737R4 std::array is a wrapper for an array! J. Schultke
Abstract
The `std::array` class template has established itself as a de-facto replacement for "builtin arrays" or "C-style arrays" in many code bases. This also means that it is frequently taught to novice programmers, with an explanation along the lines of:
› P3738R1 Make std::make_from_tuple SFINAE friendly Y. Wang
Abstract
This paper introduce constraints for `std::make_from_tuple` to make it SFINAE friendly.
› P3818R2 constexpr exception library which is unsurprising in potentially constant initialization H. Dusíková
Abstract
To make `constexpr` exception support complete, and allow all functionality withing constant evaluation. This paper was seen in previous revision by LEWG. It didn't get consensus and most of the group prefered the conservative approach of removing `constexpr` from `std::uncaught_exception()` and `std::current_exception()`. The group asked me to revisit this again for C++29.
› P3850R0 A proposed plan for extending Contracts in C++29 T. Doumler , J. Berne
› P3852R1 constexpr `is_pointer_within` memory area H. Dusíková
Abstract
At first maybe this does seem as somehow arcane or esoteric. But this is a problem worth solving and it will make C++ a bit more expressive.
› P3933R1 constexpr `std::hive` H. Dusíková , NylteJ
Abstract
C++ users are often surprised by missing functionality available during constant evaluation, sometimes there is no real reason in the language, it's just no one wrote a paper making the thing `constexpr`. Anecdotally this is often surprise to Jason Turner's students when they start experimenting with `constexpr` code.
› P3969R1 Fixing std::bit_cast of types with padding bits J. Schultke
Abstract
> The following use of `std::bit_cast` has undefined behavior at compile time: > > ```cpp > constexpr auto x = std::bit_cast<__int128>(0.0L); // GCC accepts (x = 0), Clang rejects > ``` > > That is because an 80-bit x87 `long double` has 6 bytes of padding, and it is undefined behavior to map those padding bits onto non-padding bits in the destination type via `std::bit_cast`. [[bit.cast]](https:/
› P3971R1 Generalised type rebinding for structures of uniform elements D. Towner
Abstract
Modern C++ provides powerful facilities for generic programming, but lacks a uniform way to change the element type of containers and container-like types. Consider a simple requirement: convert a container of `float` into the corresponding container of `double`, without the caller having to know what kind of container it is.
› P3973R1 bit_cast_as: Element type reinterpretation for std::simd D. Towner
Abstract
SIMD programming frequently requires reinterpreting vector data at different element granularities—converting packed bytes to shorts, accessing the bit representation of floats, or regrouping data for different operations. While platform intrinsics have long supported this pattern naturally, with `std::simd` programmers must use `std::bit_cast` with fully-specified target types, manually computing
› P3983R2 simd object representation D. Towner , R. Arutyunyan
Abstract
The Working Draft makes `simd` types *trivially copyable types*, which allows `std::bit_cast` operations. However, the object representation is unspecified, making the results similarly unspecified.
› P4003R3 Ask: A Minimal Coroutine Execution Model V. Falco , M. Gill , S. Gerbino
Intent
Ask
Abstract
This paper asks the committee to advance the *IoAwaitable* protocol as a standard coroutine execution model.
› P4013R0 constexpr `any` of all the things H. Dusíková
Abstract
Often you just need to pass a value around, but not interact with it, for that in C++ you have multiple options: template (and keep the type information intact), inheritance (and being force to use intrusive inheritance in your types), passing allocated `(const) void *` pointer (and managing its lifetime), alternatively use `std::unique_ptr` or `std::shared_ptr` with custom deleters, or use a poly
› P4189R0 get()ing the pointer from optional N. Liber
Abstract
There is no easy, obvious way to retrieve the pointer stored in an `optional<T&>` , nor a pointer to the object in an `optional<T>` This proposal rectifies that by proposing a `.get_ptr()` method.
› P4206R0 Revert string support in std::constant_wrapper B. Revzin , Z. Laine , M. Kretz , J. Wakely , T. Kamiński
Abstract
Originally, the design of `std::constant_wrapper` [[P2781R4]](https://wg21.link/p2781r4) was :
› P4209R0 numeric_limits for std::simd D. Towner
Abstract
The SIMD working draft introduces `std::simd::basic_vec<T, Abi>` as an element-wise parallel extension of an element type `T`. A central goal is to allow the same generic numeric code to operate on scalar `T` and on `basic_vec<T, Abi>` interchangeably. Most non-trivial numeric code that aims for that behaviour would require `std::numeric_limits<V>` somewhere. For example:
› P4213R0 Minimal SI: Defining the International System of Units for the C++ Standard Library M. Pusz
Abstract
[[P3045R8]](https://wg21.link/p3045r8) supplies the type system. It does not supply the SI. A user who includes the framework gets `quantity` , `unit` , `quantity_spec` , `prefix` — but no `metre` , no `kilogram` , no `second` . The framework is deliberately content-agnostic: it supports arbitrary systems of quantities and units. Shipping the framework without SI content would be like shipping `<a
› P4216R0 Comparisons for span M. Hava
Abstract
**Design Space** **Deep value comparisons** All existing *reference types* use the same comparison model: they compare the referenced values (if any), not their identity. This model has always been in place for `string_view` and was adopted
› P4217R0 when_all() is just just() R. Leahy
Abstract
The standard currently specifies, by fiat, that `std::execution::when_all()` is ill-formed (§33.9.12.12 [exec.when.all]):
› P4220R0 Design goals for zstring_view A. Krzemieński
Abstract
During the 2025 Sofia meeting, LEWG declared consensus to spend more time on `zstring_view` ([[P3655R4]](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3655r4.html)). This paper follows the direction. We want to make sure that the design goals for `zstring_view` are clearly understood before the decision whether to even have it or not are made.
› P4225R0 2026-05 Library Evolution Polls I. Levi , F. Fracassi , A. Weis , C. Jabot
Abstract
This paper contains the decision polls that the C++ Library Evolution group will take in May 2026.
› P4227R0 What's in a cstring_view? A. Weis
Abstract
In C, a `’\0’` in a char array marks the end of the string. A C string is not just a string that has a `’\0’` at the end. It’s a string that *ends* *at* *the* *first* `’\0’` *character*.
› P4228R0 try_*_back For Other Sequence Containers N. Liber
Abstract
Now that we have `try_*_back` in `inplace_vector`, we should add it to `vector` and explore adding it to other sequence containers that provide `push_back` and `emplace_back`.
› P4230R0 Implementability of P0943's C++ stdatomic.h H. Boehm
Abstract
There has been a lot of discussion arguing that the C++23 spec essentially forces ODR violations. by implementing atomics as both a struct/class (in C++) and a scalar (in C) IMO, that depends on your perspective. If you view C code as also C++ code, then ODR violations in a combined C with C++ program make sense. This is the common view of C types in C++.
› P4231R0 Unified floating point rounding proposal H. Boehm , G. Davidson , J. Schultke
Abstract
We propose the addition of the following struct. Actual wording is still left as future work (some of which can be taken from p3864). This is basically identical to P2746, except that we constrain operations to be IEEE conformant whenever is_iec_559 is `true`.
› P4233R0 More minor additions to standard library hardening K. Varlamov
Abstract
This paper is a small followup to [P3471R4 “Standard Library Hardening”](https://wg21.link/P3471R4) and [P3697R1 “Minor additions to C++26 standard library hardening”](https://wg21.link/P3697) that proposes adding several hardened preconditions across the Library. The unifying theme is in fact a lack of a unifying theme; these are “miscellaneous” checks that don’t fit into a larger category. This
