› P2806R5 do expressions B. Revzin , B. Lopez , Z. Laine , M. Park
2026-08-13
Doc Date
2026-08-13
Abstract
We propose the addition of a new kind of expression, called a `do` expression. In its simplest form:
› P3100R8 A framework for systematically addressing undefined behaviour in the C++ Standard T. Doumler , J. Berne
2026-08-14
Doc Date
2026-08-14
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.
› P3589R3 C++ Profiles: The Framework G. Reis
2026-07-21
› P3817R0 Structured Binding Assignments Y. yonisimian@gmail.com , R. regev.ran@gmail.com
2026-07-28
Doc Date
2026-07-28
Abstract
This proposal introduces an extension to C++ structured bindings, allowing assignment to existing variables.
› P4222R2 An initialization profile (R1) B. Stroustrup
2026-08-14
Doc Date
2026-08-14
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
› P4277R0 Overview and Implementation Report for P3100 J. Berne
2026-08-13
› P4297R1 Severing P3100's Profiles Claim from Its Case-by-Case Review V. Falco , V. Voutilainen
2026-08-14
Intent
Ask
Doc Date
2026-08-14
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.
› P4323R0 Do do_return! J. Schultke
2026-08-11
Doc Date
2026-08-11
Abstract
[[P2806R4]](https://wg21%2elink/p2806r4) proposed to let the user omit the last semicolon in a `do` expression to yield a result. This paper argues against that feature for a variety of reasons.
› P4324R0 Exploration of a more library-oriented approach to contracts V. Voutilainen , V. Voutilainen
2026-08-14
Doc Date
2026-08-14
Abstract
This paper supplies a design and implementation exploration for a more library-oriented approach to contracts.
› P4327R0 Direct-list-initialization syntax for default function arguments U. Radu-Andrei
2026-08-10
Doc Date
2026-08-10
Abstract
A parameter declaration may contain a braced-init-list immediately following the `declarator`.
› P4332R0 Contracts are inappropriate for undefined behavior checks J. Spicer , V. Voutilainen , B. Stroustrup , V. Falco , J. Sanchez
2026-07-31
Doc Date
2026-07-31
Abstract
This document makes one narrow claim: that the mechanism P2900 defines for contract assertions is the wrong mechanism for checks whose purpose is to detect or mitigate core-language undefined behavior, as proposed by P3100. The claim does not depend on any hostile reading of contracts. It follows from what the contracts proposal says about itself: P3846R1 concedes that guaranteed enforcement is a
› P4340R0 Extending constant template parameter support by customizing std::meta::reflect_constant B. Revzin
2026-08-13
Doc Date
2026-08-13
Abstract
This is a follow-up to [[P2484R0] (Extending class types as non-type template parameters)](https://wg21.link/p2484r0) and [[P3380R1] (Extending support for class types as non-type template parameters)](https://wg21.link/p3380r1) (the latter of which starts with a useful reading list), and is a new solution to that problem building upon three insights:
› P4347R0 How to decouple UB-checks from Contracts V. Voutilainen
2026-08-14
Doc Date
2026-08-14
Abstract
This paper explains how to decouple UB-checks from Contracts. Because multiple people have expressed a desire to look at that. Further, this paper explains how to do that without redefining Undefined Behavior. This paper focuses on *how*. This paper doesn't focus on *why*.
› P4348R0 Types and Attributes B. Stroustrup
2026-08-14
Doc Date
2026-08-14
Abstract
```cpp The most important examples involve function calls that pass a pointer to initialized or uninitialized memory. Marking an argument with [[ref_to_uninit]] means that that argument must refer to uninitialized memory. If not, the initialization profile requires that that an argument refers to an initialized object. Consider int x [[uninit]]; using T = decltype(x); // does T accept a pointer to
