› P1040R9 std::embed and #depend J. Meneide
Intent
Proposal
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
› P1130R2 Module Resource Requirement Propagation J. Meneide
Intent
Proposal
Abstract
The only way to declare a dependency in C++ currently is to use a `#include` statement. With Modules coming to C++, dependency information was greatly enhanced by preambles and globule module fragments which allow for both the compiler and build system to understand physical and semantic layout of code. However, there is still a problem area that C++ has not addressed that people in the brave new
› P2034R6 Partially Mutable Lambda Captures R. McDougall , L. Garg
Intent
Proposal
Abstract
Type erased callables like `std::move_only_function` are the backbone of most asynchronous systems. Users of such systems close their operations in lambdas and place them in a concurrent queue to be processed elsewhere. Performance is often key in such systems, and such operations may want its own local reusable scratch memory. Or perhaps an accumulator for hysteresis over multiple calls.
› P3384R1 __COUNTER__ J. Rifkin
Intent
Proposal
Abstract
The `__COUNTER__` predefined macro is a common language extension for C and C++ which expands to an integer literal that starts at `0` and increments by `1` every time it is expanded in a translation unit. This is useful for generating unique identifiers, generating unique indices, and other preprocessor metaprogramming uses.
› P3598R0 CWG3158 - `const`-ification of Splice Expressions J. Berne
Intent
Proposal
Disposition Date
2026-03Adopted
› P3846R1 C++26 Contracts, reasserted T. Doumler , J. Berne
Intent
Proposal
Abstract
[P3835R0], [US 25-052], [FI-071], and [RO 2-056] characterise P2900 as being ‘not safe’ and diminishing the overall ‘safety’ of C++. A central concern is that P2900 provides no method to guarantee *in* *code* that a particular assertion, or all assertions in a given ‘component of a program’, will always be checked. In addition, [RO 2-056] suggests that being able to alter the evaluation semantics
› P3899R2 Clarify the behavior of floating-point overflow J. Schultke , M. Kretz
Intent
Proposal
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.
› P3951R1 String Interpolation Objects B. Revzin
Intent
Proposal
Abstract
The `std::format` approach to formatting offers many significant benefits over the prior `<iostream>`s approach that need not be revisited here. However, `<iostream>` does still have one significant advantage: ordering. It is easy to see at a glance with a long `std::cout` statement which pieces are to be formatted in which order. With `std::format`, as the amount of replacement fields increases,
› P4019R1 constant_assert J. Persson
› P4021R2 compile_assert - an assert that evaluates at compile time J. Grant
Intent
Proposal
Abstract
`compile_assert()` provides a way to specify constraint predicates that are validated at compile time and reported to the user via a diagnostic. This proposal specifies the syntax but not the method used to determine a constraint failure.
› P4032R1 Strong ordering for meta::info L. Szolnoki
Intent
Proposal
Abstract
Being able to compare `meta::info` directly makes metaprogramming that needs to sort types, functions, etc... into some canonical order with standard algorithms more convenient.
› P4043R0 Are C++ Contracts Ready to Ship in C++26? D. Neațu
Intent
Proposal
Abstract
The C++ Contracts facility introduced by P2900 represents a major addition to the C++ language, intended to support specification of program correctness through preconditions, postconditions, and assertions.
› P4044R0 Just `pre!`. Mandatory precondition for contracts. L. Teodorescu
Intent
Proposal
Abstract
C++26 contracts support a wide range of uses, but they currently cannot reliably enforce *UB-safety*. Because preconditions may be evaluated with *ignore* semantics, a library that relies on contract preconditions to prevent undefined behavior cannot guarantee that those checks will execute.
› P4101R0 Consteval-only Values for C++26 B. Revzin , P. Dimov , D. Vandevoorde , D. Katz
Intent
Proposal
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.
› P4135R0 Consteval-only Types W. Childers
Intent
Proposal
Abstract
If we take a step back and talk about types, a fundamental tenet is that types have invariants. These invariants are ultimately what drive many of the semantics of a C++ program. C++ would not be where it is today without RAII and RAII could not exist without a notion of invariants.
› P4136R0 #line is not in line with existing practices C. Jabot
Intent
Proposal
Abstract
line-directive: # line pp-tokens new-line The string-literal of a #line directive, if present, shall be a character string literal. The line number of the current source line is the line number of the current physical source line, i.e., it is one greater than the number of new-line characters read or introduced in translation phase 1[lex.phases] while processing the source file to the current prep
› P4138R2 CWG3103 “Corresponding members and by-value object parameters” V. Serebrennikov
Intent
Proposal
Abstract
While looking at [CWG3103](https://cplusplus.github.io/CWG/issues/3103.html), I got interested how we arrived at status quo, specifically how [[basic.scope.scope]/3.1](https://wg21.link/basic.scope.scope#3.1) came to be, and this is what I found. One of the conclusions I arrived at is that it doesn’t make much sense to overload member functions with explicit object parameter of non-reference type
› P4142R0 Consteval Only Types Slides W. Childers
› P4149R1 Define "immediate context" A. Krzemieński , B. Bi
Intent
Proposal
Disposition Date
2026-03Adopted
› P4155R0 Responding to type erasure requirements for trivial relocation O. Hunt
Intent
Proposal
Abstract
P3937 presents a discussion of the type erasure requirements for any future trivial relocation feature in C++. This paper is a very short response to that paper addressing various issue in the presented requirements, and erroneous technical arguments.
› P4158R0 Subsetting and restricting C++ for memory safety O. Hunt
› P4175R0 Lift some arbitrary CTAD restrictions M. Izvekov
Intent
Proposal
Abstract
This paper proposes to relax some Class Template Argument deduction (CTAD) restrictions which were originally put in place for no well motivated reason other than simplicity and being conservative.
› P4197R0 Design questions for trivial relocation in C++29 G. D'Angelo
Intent
Proposal
Abstract
Trivial relocation has been a long-standing goal for C++. Multiple proposals have been put forward over the years, most notably [P1144R12] and [P2786R13], each with a different design and different tradeoffs. In the C++26 cycle, [P2786R13] was adopted in Hagenberg, but was ultimately removed from the C++26 Working Draft in Kona due to a number of unresolved design concerns.
