C++20 symmetric transfer (P0913) lets await_suspend return a coroutine_handle<> so one coroutine suspends and another resumes as a tail call - constant stack space. std::execution sender algorithms create receivers that are structs, not coroutines. No coroutine_handle<> exists at any intermediate point. When a coroutine co_awaits a sender that completes synchronously, the stack grows by one frame per completion.
A proposal for a coroutine-native I/O protocol built from working code. The core is two concepts - IoAwaitable and IoRunnable - a type-erased executor, and a thread-local frame allocator. The paper argues that five C++20 coroutine properties (type erasure through coroutine_handle<>, promise customization, stackless frames, symmetric transfer, and compiler-managed state) together make coroutines the optimal basis for byte-oriented I/O.
The paper frames std::execution (P2300) as a continuation-passing-style sub-language within C++ - with its own control flow primitives, variable binding model, error handling, and iteration strategy. It maps every major C++ control flow construct to its sender equivalent, traces the theoretical roots to monads and CPS, and walks through progressively complex examples from a simple pipeline to a full retry algorithm.
The current object lifetime rules say the last update to an object must happen-before its destruction. Sounds reasonable. The problem is that a release_store to an atomic satisfies this, but fence(release) followed by a relaxed_store does not - even though the fence+relaxed pattern is intuitively at least as strong. The paper argues this is overly conservative, doesn't match any real hardware, and breaks the mental model that standalone fences are a valid alternative to integrated ordering.
The broadcast constructor in the Parallelism TS let you write vec<float>() + 1 and have it just work - the int got implicitly converted to float and broadcast across the vector. When simd merged into C++26 via P1928, the stricter value-preserving conversion rules made that expression ill-formed. This paper brings it back with a consteval constructor overload that checks at compile time whether the conversion loses precision, and rejects the program if it does.
C++ only gives you truncating / and a remainder whose sign follows the dividend. That combo is fine until you want ceiling buckets, Python-style floor division, or nearest-with-ties rules - then the Stack Overflow answers start lying, overflowing, or invoking UB on INT_MIN. Schultke proposes a full family of std::div_* and std::div_rem_* plus a dedicated std::mod for the divisor-sign remainder you want in real modular arithmetic.
Dietmar Kühl's latest tackles the messy state of affine_on in std::execution::task - the algorithm responsible for making sure your coroutine resumes on the same scheduler it was running on before a co_await. R2 addresses five NB comments at once, all stemming from concerns raised in P3796R1.
Paper proposes std::clmul and std::clmul_wide for carry-less multiplication - also known as XOR multiplication or polynomial multiplication over GF(2). It's the operation behind CRC computation, AES-GCM in cryptography, and some clever bit manipulation tricks like the simdjson JSON parser's quote-pair detection.
Ville Voutilainen drops a grenade on the C++26 contracts timeline. The proposal rewrites the contracts surface: bare pre(cond) means guaranteed enforce - no configuration can turn it off - while pre(std::pre(cond)) wraps the predicate in a library function that queries a configuration mechanism to pick between enforce, observe, quick_enforce, or ignore. The core language gets only two evaluation semantics: enforce and ignore. All the P2900 complexity moves to library functions.
The current std::simd restricts element types to arithmetic types and std::complex. This paper proposes replacing that closed list with trait-based constraints - if your type is trivially copyable, the right size (1, 2, 4, 8, or 16 bytes), and not over-aligned, it's vectorizable. That's it. Change the gatekeeper, keep everything else the same.
P2728 is the paper that's been quietly building the foundation for real Unicode support in C++. Eleven revisions in, it proposes range adaptors for transcoding between UTF-8, UTF-16, and UTF-32 - pipe-style, lazy, composable with the rest of <ranges>.
Bjarne's latest on profiles - this time with actual detail on what type-safety and resource-safety profiles would look like in practice. Four target audiences tells you the scope.
Updated pre-meeting admin telecon agenda for the March 2026 WG21 meeting, superseding N5035. Covers the usual: roll call, logistics from Jens Maurer, subgroup status reports across the entire pipeline - all 15 active study groups plus the evolution and wording groups - SC22 liaison, and a review of priorities under P1000. Telecon scheduled for March 9th, London time, via Zoom.
Jan Schultke takes on a surprisingly fundamental question: what values can a C++ floating-point type actually represent? Turns out the standard is vague on whether infinity and NaN exist from a core language perspective, whether negative zero is negative, and whether 0.0 is guaranteed to be positive zero.
Jan Schultke and Peter Bindels propose extending std::to_chars and std::from_chars to work with char8_t, char16_t, char32_t, and wchar_t - not just char. The motivation is straightforward: if you're building a JSON parser with char8_t strings, you currently can't convert numbers without going through char first. Since every digit and sign that charconv touches is Basic Latin (ASCII), supporting other character types is mechanically simple.
Now that P2996 reflection has landed in C++26, the next question is obvious: what about attributes? P3385 proposes the building blocks for reflecting on C++ attributes at compile time - query what attributes appertain to an entity, compare them, and feed them into code generation via define_aggregate.
Victor Zverovich (yes, the {fmt} guy) is proposing to rename std::runtime_format to std::dynamic_format. The motivation is straightforward: now that P3391 made std::format work in constexpr contexts, calling something runtime_format when it can be evaluated at compile time is misleading at best.
The <cctype> functions have been a quiet source of pain for decades - locale-dependent behavior, no constexpr support, UB traps with signed char, and zero support for Unicode character types. P3688R6 proposes a new <ascii> header with lightweight, locale-independent, constexpr alternatives for all the character classification and transformation functions you actually need when parsing ASCII text.
C++ currently lets you write A& operator=(const A&) && = default - an explicitly defaulted copy-assignment operator that's rvalue-ref-qualified. Nobody does this on purpose. The compiler is happy to generate it, but it makes no sense: you're asking the compiler to default-implement assignment to an rvalue. This paper proposes to make it stop.
The Transactional Memory TS is back with a version 2. N5036 replaces the original TM TS (ISO/IEC TS 19841:2015) with a slimmed-down design centered on atomic do { ... } blocks - compound statements that execute atomically with respect to other transactions. No more transaction_safe annotations on every function in the call tree.
Oliver Kowalke and Nat Goodspeed are back with R22 of the fiber proposal - the paper that has been through more revisions than most of us have had performance reviews. fiber_context proposes a minimal API for stackful context switching. No scheduler, no green threads, no opinions about how you use it. Just resume() to switch stacks and a synthesized fiber_context to switch back. Think Boost.Context, but standardized.
Guy Davidson's pre-meeting admin telecon agenda for the March 2026 WG21 meeting. Roll call, logistics, subgroup status reports from all active study groups and working groups, new business. The "meeting before the meeting" document.
Christof Meerwald is asking EWG to revisit the resolution of CWG 1395, a core defect report from 2016 that changed how variadic and non-variadic function templates get partially ordered during overload resolution. The short version: the accepted resolution fundamentally changed how function parameter packs work during partial ordering, but a decade later only EDG actually implements it that way. GCC, Clang, and MSVC all do something different - and users expect the GCC/Clang/MSVC behavior.
Matthias Kretz is back with plumbing work on std::simd. Three LWG issues - 4470, 4414, and 4518 - all touch overlapping wording in [simd], so they get fixed together in one paper.
The Directions Group has dropped a paper on how C++ should deal with AI. Six authors including Bjarne, and this one touches two completely different nerve clusters at once.
Guy Davidson and Jan Schultke propose adding five correctly rounded math functions to <cmath>: cr_add, cr_sub, cr_mul, cr_div, and cr_sqrt. These guarantee roundTiesToEven rounding regardless of the current floating-point environment state, matching what IEC 60559:2020 specifies for its basic operations.
Jan Schultke's proposal to bring C23's _BitInt to C++ as a set of fundamental types, with std::bit_int<N> and std::bit_uint<N> alias templates for the C++-friendly spelling. R3 removes std::simd and std::atomic support from the MVP scope, rebases wording on N5032, and tracks WG14's approval of _BitInt(1) via N3747.
New revision of Daniel Towner's (Intel) paper proposing mask_from_count for std::simd - a free function that generates a mask with the first N elements set to true. The primary use case is loop remainders: when your data doesn't fill an entire SIMD vector, you need a mask to process just the leftover elements. Without a standard facility, users end up writing manual mask generation that's either non-portable across SIMD targets or subtly wrong for edge cases (the paper has some good examples of how the iota-based and bit-manipulation approaches silently break).
Ville Voutilainen is back with a contracts paper that takes a different approach to guaranteed enforcement. Instead of extending P2900's contract syntax with always-enforced variants (that's P3911's lane), this paper proposes entirely new keywords: entry_cond, return_cond, and mandatory_assert. These are guaranteed to be checked - never ignored, never just observed - using either enforce or quick_enforce semantics.
Intel folks proposing simd::chunked_invoke - a utility that breaks large basic_vec values into register-sized chunks, applies a callable (typically wrapping a platform intrinsic) to each chunk, and reassembles the results via simd::cat. The paper title still says simd_invoke but the function was renamed to chunked_invoke in this revision to avoid confusion with std::invoke.
Victor Zverovich (of {fmt} fame) is back with a follow-up to P2845, which got std::filesystem::path formatting into C++26. Turns out there's one remaining gap: on Windows, paths can contain unpaired UTF-16 surrogates, and when you format them with std::format, distinct paths collapse to the same replacement character. Two different paths, same string. Not great.
Remember when N3421 gave us transparent functors for C++14 but specifically deferred << and >> as "slightly beyond completely trivial to specify"? Twelve years later, someone finally wrote the paper to fill the gap.
January 2026 LEWG e-poll results are out. Three papers forwarded to LWG:
Matthias Kretz - yes, the std::simd guy, and current Numerics SG chair - has a short paper arguing that the classic N3248 definitions of "narrow contract" and "wide contract" are broken in a post-P2900 world.
This paper identifies four structural gaps where the sender model meets coroutines: error reporting (the three-channel model can't express partial I/O results without losing data), error returns (co_yield with_error reverses six years of coroutine convention), frame allocator propagation (senders get the allocator they don't need, coroutines need the one they don't get), and symmetric transfer (sender algorithms are structs with void-returning completions - no handle to transfer to).
You know how function declarations have had noexcept(expr) since C++11? Turns out you can't do that in a compound requirement. You get bare noexcept or nothing. So if you need to conditionally check whether an expression is non-throwing - say, in a type-erased wrapper parameterized on noexcept - you have to duplicate the entire concept body with a ternary: one branch that checks noexcept, one that doesn't.
The big one. Seven authors - including Timur Doumler, Pablo Halpern, and Nevin Liber - are asking the committee to answer a question it has been dancing around since the CISA reports dropped: should C++ actually commit to becoming a memory-safe language, or keep patching around the edges?
P2996 gave us meta::info for reflection. P3372 made unordered containers constexpr. P3816 fills the gap between them: you still can't use meta::info as a key in an unordered_map because there's no hash for it.
P3411R5 - any_view
WG21
If you've ever tried to return a ranges pipeline from a function and wept at the return type, this paper is for you. P3411 proposes std::ranges::any_view - a type-erased view that lets you hide the template gore behind a clean interface, the same way std::function did for callables but for ranges.
Ever wonder why std::constructible_from<C<std::string>> gives you a different answer on every compiler? This paper looks at whether default function arguments and default member initializers should count as part of the "immediate context" for SFINAE and concept checking.