Cppfront status summary (summer 2026)

[hsutter]

I posted a shorter version of this earlier this year, in answer to the Discussion question "Is Cpp2 aiming to be a 'real thing'?"

It was just asked again on Reddit, so here's a more detailed answer:

As I said when introducing it in the 2022 talk, it's "my personal experiment ... to learn some things, prove out some concepts, share some ideas ... my hope is to start a conversation ... what could be possible within C++'s own evolution to rejuvenate C++" instead of just leaping to some incompatible other language. That talk, and followups, did emphasize that a core goal of the experiments in Cpp2/cppfront was to feed them into ISO C++ standardization (which you can do with most of them, such as metaclasses; just not the syntax-breaking ones), and indeed it has fed into many papers that I listed in my CppCon 2023 talk slide here.

Note I deliberately didn't support cppfront as a production compiler (its license prohibited commercial use for the first couple of years), and I actually didn't initially enables Issues on the repo... but then kind contributors used PRs instead to submit Issues :) so I caved and enabled them. I am glad that the Issues did lead me to try a few more experiments, write documentation, and yes fix some bugs... thanks for everyone's contributions! I don't have the bandwidth myself to support a production compiler though. But I did relax the license to as not to prevent someone from using it commercially if they wanted to (but without support).

By late 2024-ish I'd implemented most of the key experiments I had on my list so commits slowed down. Then in summer 2025 I extended the reflection implementation to also do function bodies (statements, expressions) which led to a big chunk of my most recent CppCon (2025) talk on reflection showing autodiff live demos implemented by Max Sagebaum (in cppfront because the Clang/EDG prototypes didn't support intra-function reflection yet, but I presented it explicitly as a direct proxy to show us all what future C++29/32 will be able to do in medium-term-future ISO C++).

That's the most recent experiment I pushed to try out. I'm currently caught up with the list of experiments I wanted to run, so I'm now focusing on helping many of those features come into ISO C++, including metaclasses in the medium term now that we have the basics of reflection already in ISO C++ thanks to the hard work of many people (not just P0707 and cppfront), and the safety work (which again has pointed to cppfront features such as to do bounds checking at call sites, by default (with opt-out of course); I really think that's something that could help ISO C++ too as we improve our safety story.

The above was my answer on Reddit, at the end of which I said I probably should write this longer answer in the repo... and here we are. Thanks, everyone, for all your interest in these personal experiments!

[MaxSagebaum]

Maybe a short link or comment in the Readme would clarify this for people.

[hsutter]

Thanks! Good suggestion -- done.

[Callen44]

I apologize if I'm asking a question that's really already answered above, but what is your long-term goal for the syntax breaking changes cpp front proposes? Of course, syntax breaking changes can't be easily made to the existing ecosystem, so what are you hoping to become of these changes? Are you wanting to help inspire projects that actually are separate languages (like Google's carbon), or non-breaking changes to the existing, or something else?

[hsutter]

Short answer: That's a future TBD.

Long answer: First thing is to see how much of the simplification and safety we can get incrementally in today's syntax. Then we'll have much more data about the limits of the evolutionary approach under the single syntax and be able to evaluate the additional cost/benefit of having a second compatible alternate "skin" syntax. Second, if the benefit is enough for there to be serious appetite to trying out a second syntax (litmus test: I'd be looking for at least one C++ compiler vendor express interest in implementing it themselves as an optional feature for their customers) then it could be worth the effort to propose a simpler second syntax as a non-normative white paper separate from the standard at first (so that if vendors do want to implement it they have a target and do it the same way). If all those things happened then we could see if that could consensus in the committee... so IMO there are at least three major "maybe if" steps between here and even a separate white paper. :) But note my emphasis in all of these steps is on progress within ISO C++ (WG21), not as an effort apart from WG21.

[Callen44]

I like the approach of evolving the language as it is. Cpp's syntax can be annoying, but it is not beyond reform. Earlier today I had an AI model generate a short program that demonstrated using chrono to print the formatted date. Telling the AI to rewrite it in c++23 reduced ~7 lines to 3. The greatest obstacle to a cleaner, better cpp is the slow adoption timeline of new cpp releases; we'll see how much the desirability of comp-time reflections helps version 26.