In the next week, I will be giving talks on C++ reflection in Singapore (Thursday night) and Sydney (Sunday night). If you’re local, please RSVP! I look forward to seeing many of you there.

Singapore C++ Users Group November Meetup

Thursday November 20, 6:30pm to 9:30pm
Clifford Pier, Fullerton Bay Hotel
80 Collyer Quay, Singapore 049326

Citadel Securities Sydney C++ Talk

Sunday November 23, 6:00pm to 10:00pm
Museum of Contemporary Art Australia
140 George Street, The Rocks, NSW, Australia 2000

In related news, see yesterday’s Reddit post “Reflection is coming to GCC sooner than expected!” — our major compiler implementers understand the importance of reflection and are racing to implement it. Favorite quote: “This patch implements C++26 Reflection as specified by P2996R13, which allows users to perform magic.”

Finally, here’s my talk description.

Reflection — C++’s Decade-Defining Rocket Engine

In June 2025, C++ crossed a Rubicon: it handed us the keys to its own machinery. For the first time, C++ can describe itself — and generate more. The first compile-time reflection features in draft C++26 mark the most transformative turning point in our language’s history by giving us the most powerful new engine for expressing efficient abstractions that C++ has ever had, and we’ll need the next decade to discover what this rocket can do.

This talk is a high-velocity tour through what reflection enables today in C++26, and what it will enable next. The point of this talk isn’t to immediately grok any given technique or example. The takeaway is bigger: to leave all of us dizzy from the sheer volume of different examples, asking again and again, “Wait, we can do that now?!” — to fire up our imaginations to discover and develop this enormous new frontier together, and chart the strange new worlds C++ reflection has just opened for us to explore.

Reflection has arrived, more is coming, and the frontier is open. Let’s go.

On Saturday, the ISO C++ committee completed the first of two final fit-and-finish meetings for C++26, in our meeting in Kona, USA. What we have in the C++26 working draft represents exactly the set of features we have consensus on so far; the goal of these last two meetings is to fix bugs and otherwise increase consensus for the C++26 standard. We are well on track to complete our work on C++26 and set it in stone at our next meeting in March 2026.

This meeting was hosted by the Standard C++ Foundation. Our hosts arranged for high-quality facilities for our six-day meeting from Monday through Saturday. We had about 200 attendees, about half in-person and half remote via Zoom, formally representing 21 nations. At each meeting we regularly have new guest attendees who have never attended before, and this time there were 17 new guest attendees, mostly in-person, in addition to new attendees who are official national body representatives. To all of them, once again welcome!

The committee currently has 23 active subgroups, 10 of which met in 6 parallel tracks throughout the week. Some groups ran all week, and others ran for a few days or a part of a day, depending on their workloads. Unusually, there were no major evening sessions this week as we focused on completing the feature set of C++26. You can find a brief summary of ISO procedures here.

Beyond feature freeze: No new features, one removed (trivial relocatability), and many improvements

We are beyond the C++26 feature freeze deadline, so no major new features were added this time.

This week we heard and worked through concerns about several features, including comments proposing to move features like contracts and trivial relocatability out of C++26 for further work. We resolved 70% of the official international comments on C++26, which puts us well on schedule to finish at our next meeting in March, and we fixed many other issues and bugs too.

Here are a few highlights…

For contracts (pre, post, contract_assert), we spent most of Monday and Tuesday reviewing feedback. The strong consensus was to keep contracts in C++26, but to make two important bug fixes and pursue a way to specify “must enforce this assertion”:

• We discovered two bugs, and adopted fixes for those at this meeting. One was paper P3878R1 “Standard library hardening should not use the ‘observe’ semantic” by Ville Voutilainen, Jonathan Wakely, John Spicer, and Stephan T. Lavavej.
• For the next meeting in March, we are also pursuing something like the first proposed solution in P3911R0 “[basic.contract.eval] Make Contracts Reliably Non-Ignorable”by Darius Neațu, Andrei Alexandrescu, Lucian Radu Teodorescu, and Radu Nichita (though not necessarily with that particular syntax). The idea is to add an option to express in source code that a pre/post/contract_assert must be enforced, which some view as a necessary option in the initial version of contracts. A group of interested persons will work on that design over the winter, including to answer questions like “what syntax?” and “should violations call the violation handler or not?”, and bring a proposal to the March meeting.

Based on the national members’ feedback in the room, these changes appear “likely” to satisfactorily address the most serious national body contracts concerns — fingers crossed, we’ll know for sure in March.

For trivial relocatability, we found a showstopper bug that the group decided could not be fixed in time for C++26, so the strong consensus was to remove this feature from C++26.

For erroneous behavior (EB), we adopted P3684R1 “Fix erroneous behavior termination semantics for C++26” by Timur Doumler and Joshua Berne to tighten and improve its behavior.

• Recall: EB is a new C++26 concept that means “well-defined to be Just Wrong”… any code whose behavior is changed from undefined behavior (UB) to EB can no longer result in time travel optimizations or security vulnerabilities. The first place we applied EB is that in C++26 reading from an uninitialized local variable is no longer UB, but is EB instead.
• Before this meeting, C++26 said that if a program performs EB by reading from an uninitialized local variable, then the program may be terminated immediately or at any later time in the program’s execution; the latter part was problematic and a bit too loose.
• After this meeting, the program can still be terminated immediately, or “soon” thereafter when it actually tries to use the uninitialized value; it cannot just fail ‘sometime arbitrarily later’ anymore. In short, instead of “poisoning” the entire program after an uninitialized local read, C++26 now “poisons” only the specific uninitialized value that was read. This change makes EB much easier to reason about locally and is compatible with what the existing implementations in compilers and sanitizers actually do.

We adopted P1789R3 “Library Support for Expansion Statements” by Alisdair Meredith, Jeremy Rifkin, and Matthias Wippich. It makes integer_sequence support structured bindings, so that the type is easier to use with the “template for” and structured bindings pack expansion language features we added in C++26.

We also adopted P3391R2 “constexpr std::format” by Barry Revzin. This makes it easier to apply string formatting to strings that need to be used at compile time, notably so they can be passed to static_assert which can accept std::string messages in C++26.

And many more tweaks and fixes. Whew!

A new convenor team and secretary

I’ve been serving as convenor (chair) of the C++ committee since 2002 (with a brief hiatus in 2008-09 when P.J. (Bill) Plauger did it for a year, thanks again Bill!). It’s unusual for one person to serve so many terms, and I’ve been telling the committee for over a year now that it’s time to pick someone else when my current term expires on December 31. Nothing else is changing for me: I’ll continue to be participating actively in WG 21 as “convenor emeritus” and bringing evolution proposals to the committee, I’ll continue serving as chair and CEO of the Standard C++ Foundation and all roles related to that, and I’ll keep speaking and writing… including that I intend to keep writing these post-meeting trip reports. But it’s time for others to be able to step up to take on more of the committee’s organizational and administrative work, and I was glad to see we had three qualified and willing candidates!

ISO has selected Guy Davidson as the next WG 21 convenor, effective January 1. Thank you Guy for making yourself available, and thank you too to John Spicer and Jeff Garland who also volunteered themselves as convenor candidates! Prior to this new role, Guy was co-chairing the SG14 Gaming/Low-Latency subgroup. He also had other prominent C++ community leadership roles outside of WG 21, ranging from founding the #include diversity and inclusion group to being an organizer and/or track chair at multiple C++ conferences including ACCU and CppCon which I understand he will continue to do.

Realizing that being convenor of our large WG is quite a big job, Guy wisely immediately appointed two vice-convenors…

Nina Ranns is now a vice-convenor. Thank you, Nina! Nina has been serving as WG 21 secretary for many years and is chair of our SG22 C/C++ liaison subgroup. She also handles many C++ community responsibilities outside of WG 21, including being vice-chair of the Standard C++ Foundation and a compiler writer working on implementing the C++26 contracts feature in GCC.

Jeff Garland is also now a vice-convenor. Thank you, Jeff! Jeff has been serving as an assistant chair of our LWG Library Wording subgroup since 2019. In the wider C++ community, he is a longtime Boost library developer (date-time), coauthor of the original std::chrono proposal, one of the original founders of the C++Now (then BoostCon) conference. More recently, he became executive director of the Boost Foundation and was a cofounder (and now a lead) of the new Beman project dedicated to providing future standard library implementations today.

Now that Nina is moving from secretary to vice-convenor, we also need a new WG 21 secretary: Braden Ganetsky has graciously volunteered to take on that role. Thank you, Braden! Already at this meeting, Braden once again took notes for all but one session of the week-long EWG Language Evolution subgroup sessions, which is a huge job that earned him a big round of applause on Saturday. Outside WG 21, he currently works on low latency trading systems (and designs and builds cool 3D puzzles).

Thank you very much again to Guy, Nina, Jeff, Braden, and everyone who volunteers their time and skills to help organize and run the ISO C++ committee!

During the meeting, John Spicer (who has long chaired our whole-committee plenary sessions, and leads Edison Design Group, EDG) also hosted a lovely reception for the whole committee. The reception was to celebrate the occasion of the new leadership changes, but also that John too is stepping back from chairing the U.S. C++ committee and running our WG 21 plenary sessions. John is one of the C++ committee’s longest-serving members since the early 1990s, and his company EDG has been a leading producer of compilers for C++ and other languages. John recently announced that, after a successful and storied career, it’s time for EDG to wind down, and EDG plans to open-source its world-class C++ compiler front-end within the next year.

And so I want to especially call out and congratulate John Spicer and everyone at EDG (including EDG’s retired founder Steve Adamczyk, other key long-time members such as William (Mike) Miller and Daveed Vandevoorde, and everyone else who’s been part of the EDG family over the years) as role models — not only for their high quality compilers but for being high integrity people. Perhaps the best example of their integrity was what happened with the C++98 “export template” feature over two decades ago: In the mid-1990s, John was the most vocal person pointing out technical problems with the feature; the committee decided it did not agree and standardized the feature anyway over his and EDG’s sustained objections; and then instead of sitting back and saying “we told you so,” EDG ended up being the only company in the world who ever implemented the feature! To add a sense of proportion: It took the same team longer to implement just the C++98 export template feature than to implement a compiler front-end for the entire Java language. But John and EDG went and did it, to support the committee’s consensus decision… only to have the committee remove export template again a few years later, because John and EDG had been right about the feature’s problems. That’s a model of solid professional behavior. Thank you again, very much, to John, Steve, Mike, Daveed, and everyone at EDG, past and present.

What’s next

Our next meeting will be in March in Croydon, London, UK hosted by Phil Nash. There is ongoing lively debate about whether this is the “Croydon meeting” or the “London meeting,” and whether Croydon is or is not part of London (despite that it’s inside the M25 loop). I think there’s a good chance this will continue to be the biggest controversy; if so, we’re in excellent shape.

Thank you again to the about 200 experts who attended on-site and on-line at this week’s meeting, and the many hundreds more who participate in standardization through their national bodies! And thank you again to everyone reading this for your interest and support for C++ and its standardization.

I’m running this poll to gather data, both for myself and for other interested C++ committee members. I’m curious to see what you all report!

Please let us know what your current project is doing, and thank you for participating. The poll will close on Friday night.

In two weeks I’ll be giving a talk at the local C++ meetup here in peaceful, quirky, dog-walking, frisbee-throwing, family-friendly Portland, Oregon, USA.

PDXCPP – Monthly Meetup
October 21, 2025 @ 7:00pm
Location: Siemens EDA in Wilsonville

Which talk will I give? That’s a great question, and there’s a poll about that!

At CppCon last month, I gave two talks that each focused on one C++26 feature (including both its status in C++26 and also its future evolution): one on reflection, and one on contracts. I’ll give an updated version of one of them in person, and the organizers are letting you decide: If you are considering attending, please fill out the poll and let us know which talk you want me to give!

I’m looking forward to seeing many of you in person.

I usually only give one new talk a year, but this year I volunteered to give a second new talk at CppCon on a topic I haven’t spoken on before: draft C++26 contracts.

Thank you to all the experts, including the actual implementers and people who are for and against having contracts in C++26, for their time answering questions and providing papers and examples! I’ve done by best to represent the current status as I understand it, including all major positive must-knows and all major outstanding concerns and objections; any remaining errors are mine, not theirs.

I hope you find it useful!

Here is a copy of the talk abstract…

This talk is all about the C++26 contracts feature. It covers the following topics:

• Why defensive programming is a Good Thing (mainly for functional safety, but occasionally also for memory safety)
• Brief overview of C++26 contracts, and why they’re way better than C assert (spoiler: writing them on declarations, being able to use them in release builds, and language support is just way better than macros)
• The 3-page “Effective C++ Contracts book” — best practices you need to know to use them (spoiler: keep compound conditions together, don’t write side effects, understand the pros and cons of installing a throwing violation handler… that’s pretty much… it?)
• Why they’re viable, because they address the key things we need in production (which we’ll list)
• Why they’re minimal, because we actually need every part in C++26 to use them at scale (which we’ll do by systematically summarizing why each piece is necessary)
• What the future evolution of contracts holds (spoiler: virtual functions! groups/labels!)
• A review of Frequently Asked Questions

Thanks to C++ on Sea for inviting me to speak in June! The talk video is now live, linked below. It was recorded just 48 hours after the Sofia meeting ended, with key updates hot off the press.

Note: Next month at CppCon, I will be going even deeper and broader on reflection.
There, I’ll spend the full 90-minute talk surveying many different ways to use reflection, both what’s in C++26 and what we’ll add soon post-C++26. The point will be, not any one use, but the sheer number of uses, showing just how much gold lies in these new hills. The CppCon talk will include lots of new material I’ve never shown before, with live demos and hopefully (fingers crossed) a special guest on-stage to help showcase some advanced uses coming soon to a C++ compiler near you.

In the meantime, I hope you enjoy this video which includes a big section on that topic… thanks again to the C++ on Sea organizers and all the great attendees who gave me such a warm welcome in Folkestone.

A unique milestone: “Whole new language”

Today marks a turning point in C++: A few minutes ago, the C++ committee voted the first seven (7) papers for compile-time reflection into draft C++26 to several sustained rounds of applause in the room. I think Hana “Ms. Constexpr” Dusíková summarized the impact of this feature best a few days ago, in her calm deadpan way… when she was told that the reflection paper was going to make it to the Saturday adoption poll, she gave a little shrug and just quietly said: “Whole new language.”

Mic drop.

Until today, perhaps the most momentous single feature poll of C++’s history was the poll in Toronto in July 2007 to adopt Bjarne Stroustrup’s and Gabriel Dos Reis’ first “constexpr” paper into draft C++11. Looking back now, we can see what a tectonic shift that started for C++.

I’m positive that for many years to come we’ll be looking back at today, the day reflection first was adopted for standard C++, as a pivotal date in the language’s history. Reflection will fundamentally improve the way we write C++ code, expand the expressiveness of the language more than we’ve seen in at least 20 years, and lead to major simplifications in real-world C++ toolchains and environments. Even with the first partial reflection capability we have today, we will already be able to reflect on C++ types and use that information plus plain old std::cout to generate arbitrary additional C++ source code that is based on that information and that we can compile and link into the same program as it’s being built. (In the future we’ll also get token injection to generate C++ source right within the same source file.) But we can generate anything: Arbitrary binary metadata, such as a .WINMD file. Arbitrary code in other languages, such as Python or JS bindings automatically generated to wrap C++ types. All in portable standard C++.

This is a Big Hairy Deal. Look, everyone knows I’m biased toward saying nice things about C++, but I don’t go in for hyperbole and I’ve never said anything like this before. Today is legit unique: Reflection is more transformational than any 10 other major features we’ve ever voted into the standard combined, and it will dominate the next decade (and more) of C++ as we complete the feature with additional capabilities (just as we added to constexpr over time to fill that out) and learn how to use it in our programs and build environments.

We now return you to our normal trip report format…

The meeting

Today the ISO C++ committee completed the feature freeze of C++26, in our meeting in Sofia, Bulgaria. This summer, draft C++26 will be out for its international comment ballot (aka “Committee Draft” or “CD”), and C++26 final fit-and-finish is on track to be done, and C++26 set in stone, two more meetings after that in March 2026.

This meeting was hosted by Chaos and C++ Alliance. Our hosts arranged for high-quality facilities for our six-day meeting from Monday through Saturday. We had about 200 attendees, about two-thirds in-person and the others remote via Zoom, formally representing nearly 30 nations. At each meeting we regularly have new guest attendees who have never attended before, and this time there were 25 new first-time guest attendees, mostly in-person, in addition to new attendees who are official national body representatives. To all of them, once again welcome!

The committee currently has 23 active subgroups, 13 of which met in 7 parallel tracks throughout the week. Some groups ran all week, and others ran for a few days or a part of a day, depending on their workloads. Unusually, there were no major evening sessions this week as we focused on completing the feature set of C++26. You can find a brief summary of ISO procedures here.

More things adopted for C++26: Core language changes/features

Note: These links are to the most recent public version of each paper. If a paper was tweaked at the meeting before being approved, the link tracks and will automatically find the updated version as soon as it’s uploaded to the public site.

In addition to fixing a list of defect reports, the core language adopted 10 papers, including the following… the majority were about reflection:

Reflection, part 1: P2996R13 “Reflection for C++26” by Wyatt Childers, Peter Dimov, Dan Katz, Barry Revzin, Andrew Sutton, Faisal Vali, and Daveed Vandevoorde. This is the “basic foundation” – it does not include reflecting everything yet, and doesn’t include generation (code injection), but it’s a solid and very usable first step.

Reflection, part 2: P3394R4 “Annotations for reflection” by Wyatt Childers, Dan Katz, Barry Revzin, and Daveed Vandevoorde adds the ability to reflect additional attribute information, which makes reflection much more customizable and flexible. Definitely check out the examples in the paper.

Reflection, part 3: P3293R3 “Splicing a base class subobject” by Peter Dimov, Dan Katz, Barry Revzin, and Daveed Vandevoorde adds better support for treating base class subobjects uniformly with member subobjects, again making reflection more usable.

Reflection, part 4: P3491R3 “define_static_{string,object,array}” by Wyatt Childers, Peter Dimov, Barry Revzin, and Daveed Vandevoorde adds functions that were split off from the main reflection paper P2996, which make it easier to convert reflected data to run-time data.

Reflection, part 5 (notice a theme yet?): P1306R5 “Expansion statements” by Dan Katz, Andrew Sutton, Sam Goodrick, Daveed Vandevoorde, and Barry Revzin adds “template for” to make it easy to loop over reflection data at compile time.

Reflection, part 6 (but wait there’s more): P3096R12 “Function parameter reflection in reflection for C++26”[sic] by Adam Lach, Dan Katz, and Walter Genovese adds support for, you guessed it, reflecting function parameters.

We also added a couple of other things, including that virtual inheritance is now allowed in constexpr compile-time code, and removed undefined behavior from the preprocessor as part of the current wave-in-progress of attacking and resolving undefined behavior in C++.

Interlude: A strong recommendation

You’ll notice that this time I didn’t cut-and-paste a few illustrative code examples for each paper. That’s because I strongly recommend you make time to read all the motivating code examples in all the above-linked reflection papers, to get a sense of just how game-changing this feature is, even in its current very-initial state. And those examples are just scratching the surface of what even this first step toward general reflection makes possible.

Thank you, very much, to everyone who worked so hard to bring reflection into the standard!

More things adopted for C++26: Standard library changes/features

Not to be outdone by the core language, in addition to fixing a list of defect reports, the standard library adopted a whopping 34 papers, including the following…

P3179R9 “C++ parallel range algorithms” by Ruslan Arutyunyan, Alexey Kukanov, and Bryce Adelstein Lelbach adds what it says on the tin: parallel algorithms for the C++ Ranges library.

P2830R10 “Standardized constexpr type ordering” by Nate Nichols and Gašper Ažman makes it possible for portable C++ code to sort types at compile time.

P3149R11 “async_scope – Creating scopes for non-sequential concurrency” by Ian Petersen, Jessica Wong, and a long list of additional contributors is about enabling RAII styles to work in code that isn’t sequential and stack-based, which makes resource handling much more convenient and robust even in a heavily async world using sender/receiver, C++26’s new async model.

P2079R10 “Parallel scheduler” by Lucian Radu Teodorescu, Ruslan Arutyunyan, Lee Howes, and Michael Voss provides a standard async execution context that portably guarantees forward progress, aka an interface for thread pools.

Reflection, part 7 (you didn’t think we were done yet, did you?): P3560R2 “Error handling in reflection” by Peter Dimov and Barry Revzin enables compile-time exception handling as the error handling model for reflection code.

P3552R3 “Add a coroutine task type” by Dietmar Kühl and Maikel Nadolski provides a task type to integrate coroutines with sender/receiver, C++26’s new async model.

And much more, including constexpr shared_ptr, a bunch of std::simd extensions including enabling it to be used with ranges, and lots of other nuggets and goodies. Whew!

What’s next

Thank you to all the experts who worked all week in all the subgroups to achieve so much this week!

Our next meeting will be this November in Kona, HI, USA hosted by Standard C++ Foundation.

Thank you again to the about 200 experts who attended on-site and on-line at this week’s meeting, and the many more who participate in standardization through their national bodies!

I’ll repeat what I said last time: Don’t think C++“26” sounds very far away, because it sure isn’t… the C++26 feature freeze is past, and even before that compilers have already been aggressively implementing C++26, with GCC and Clang having already implemented about two-thirds of C++26’s language features adopted so far! C++ is a living language and moving fast. Thank you again to everyone reading this for your interest and support for C++ and its standardization.