The work toward ISO C++26 is coming along steadily. The spring committee meeting this year was in Tokyo; from Red Hat, Jonathan Wakely and I attended remotely (from the UK and the US East Coast, respectively). He was mostly in the Library working group, and I was in Core.
Core language changes moved at this meeting
P2795R5 Erroneous behaviour for undefined reads
This paper introduces the notion of "erroneous" behavior for patterns that are considered to be bugs, such as reading from an uninitialized variable. Instead of getting an indeterminate value, the read gets an implementation-defined but consistent value, and the program is allowed to emit a diagnostic and/or terminate execution.
void f() {
int i;
int j = i; // erroneous behavior
}Implementing this in GCC will probably build on the existing -ftrivial-auto-var-init flag, which currently provides an implementation-defined value, but interferes with memory debugging tools like Valgrind; the implementation of this feature will need a way to communicate to Valgrind to still consider the memory to be uninitialized.
Programs for which the now-implied initialization carries an unacceptable performance penalty can mark variables with [[indeterminate]] to return to the C++23 semantics.
P2748R5 Disallow Binding a Returned Glvalue to a Temporary
This paper makes ill-formed returning a temporary by reference, since it immediately produces a dangling reference. GCC already warned about this with -Wreturn-local-addr, so implementing this change was trivial.
int&& f() { return 42; } // now error
P0609R3 Attributes for Structured Bindings
This paper allows applying attributes to structured bindings, e.g.
struct A { int i, j; } a { 24, 42 }; auto &[x, y [[maybe_unused]] ] = a;
This was also straightforward to implement in GCC.
P2809R3 Trivial lnfinite loops are not Undefined Behavior
This paper harmonizes C and C++ by clarifying that for e.g.
constexpr bool yes() { return true; } // ... while (yes()) /*spin*/;
the implementation may not assume that the loop will eventually terminate.
P2573R2 =delete("should have a reason")
This paper adds a user-defined message to deleted function diagnostics, much like [[deprecated]] in C++14.
P2893R3 Variadic friends
This paper allows befriending all the types in a parameter pack, e.g.
template<class... Ts> class Foo { friend Ts...; };
Core language changes almost ready
One feature was almost ready to go in, but at the last minute was pulled back for more refinement:
P3032R1 Less transient constexpr allocation
This paper proposes to allow constexpr allocation to persist past the end of a constexpr variable initialization, if it occurs in immediate function context:
consteval int f() { constexpr std::vector v = { 1, 2, 3 }; // allocates storage return v.size (); } // storage released here
This seems likely to pass at the next meeting.
Major core language features in development
Major C++26 features are also starting to move out of study groups. In particular, Reflection, Contracts, and Pattern Matching went to the Evolution Working Group (EWG) for feedback at this meeting.
P2996R2 Reflection for C++26
This paper provides compile-time reflection that can in turn be used in metaprogramming.
constexpr auto r = ^int; typename[:r:] x = 42; // Same as: int x = 42;
EWG was enthusiastic about this proposal and it seems on track for C++26.
P2900R6 Contracts for C++
This proposal provides mechanisms for optionally checking that a function's requirements for its arguments and return value do in fact hold, and calling a violation handler to report the problem.
int f(const int x) pre (x != 1) // a precondition assertion post(r : r != 2) // a postcondition assertion; r refers to the return value of f { contract_assert (x != 3); // an assertion statement return x; }
Contracts were originally planned for C++20, but were removed late in the process due to late disagreements about customizability and concerns about undefined behavior. So they went back to a study group to work on a consensus "Minimum Viable Product" version of the feature, which has seemed on track for C++26. But when it came to EWG there were again widely differing opinions on various aspects of the proposal, so the path forward is still uncertain.
P2688R1 Pattern Matching
This proposal provides a convenient syntax for handling different cases of a data structure that are too complicated for 'switch' and would therefore need a series of ifs, e.g.
// tuple p p match { [0, 0] => std::print("on origin"); [0, let y] => std::print("on y-axis at {}", y); [let x, 0] => std::print("on x-axis at {}", x); let [x, y] => std::print("at {}, {}", x, y); };
EWG was encouraging but requested more implementation experience.
The next meeting will be June 24-29 in St. Louis, MO.
