cppfront: Herb Sutter's Cpp2 to C++ Compiler, Explained

What cppfront actually solves, and for whom

C++ evolution is slow because every proposal has to be argued on paper, then implemented in a full production compiler before anyone can use it seriously. cppfront attacks that gap from the other end. It is a compiler from an experimental C++ 'syntax 2' (Cpp2) to today's 'syntax 1' (Cpp1), built, in the README's words, 'to prove out some concepts, share some ideas, and prototype features that can also be proposed for evolving today's C++.' The audience is narrow and clearly stated: people who want to experiment with proposals for future standard C++ features in a simpler compiler and syntax flavor.

The README is explicit about what the project is not. Cpp2 is not a successor language with its own ecosystem. It does not ship nonstandard modules or concepts that compete with the standard ones, it does not replace your C++ compiler, and it does not require changes to your compiler, standard library or other libraries. The framing is that Cpp2 is 'another skin for C++ itself,' a simpler and safer way to write ordinary C++ types, functions and objects. That distinction matters more than any feature list: if you want a new language with its own runtime, this is the wrong repository, and the README says so before you read anything else.

The translation model: Cpp2 in, Cpp1 out, your compiler last

cppfront is a source-to-source compiler. It reads .cpp2 files and emits ordinary C++ that an existing C++20-or-higher compiler then builds. The README states that it works with all existing C++20 (or higher) compilers, libraries and tools out of the box, with no changes required to use them, and claims zero overhead. That architecture is the whole point: the generated code is not a new dialect, it is Cpp1 that your current toolchain already accepts, so the standard library, your existing libraries and your debugger stay in play.

The repository layout supports that reading. There is a source/ directory for the compiler itself and an include/ directory, alongside regression-tests/ and passthrough-tests/. The passthrough tests are the interesting ones: they suggest a mode where Cpp1 input passes through unchanged, which is consistent with the README's claim that you can keep using all your existing C++ directly. The docs/ directory backs the published documentation site, and mkdocs.yml configures it. The README also points to a status summary discussion for summer 2026, which is where the project tracks which Cpp2 features are actually implemented rather than merely designed.

The README is equally clear about what is not implemented. The lifetime safety analysis from P1179, presented at CppCon 2015 and adopted into the C++ Core Guidelines, is described as 'not yet implemented in cppfront'; implementations ship in Visual Studio and CLion, with initial parts upstreamed in Clang. The garbage-collected memory arena prototype from 2016, published as gcpp, is also 'not yet implemented in cppfront,' and the README invites a GC expert to collaborate. Two of the most frequently cited ideas in the project's history are therefore still proposals and prototypes, not features you can use today.

Building cppfront and compiling your first .cpp2 file

The README does not inline build steps. It links to the documentation site, specifically the Installation section under the overview page, which is where the project says to get and build cppfront. The repository also contains build_h2.bat and gen_build.bat at the top level, which is what the Windows build path uses. Because the exact commands live in the documentation rather than the README, treat the linked page as the source of truth and do not improvise flags.

The typical shape of use, once the compiler is built, is a single translation step. You write Cpp2 in a .cpp2 file and run cppfront on it; the tool emits a Cpp1 file that you hand to your normal compiler. The README's documentation links to a hello-world page, which is the canonical first example for the language. The command form below reflects that flow, with the input and output names standing in for your own files.

Where cppfront is the wrong tool

The most honest limitation is stated by the project itself in its own description: it is a personal experimental compiler. That is not marketing hedging, it is a scope statement. The latest release listed is v0.8.1 from 2025-01-31, with v0.8.0 in October 2024 and v0.7.4 in August 2024. The last push to the repository was on 2026-07-17, so work is ongoing, but the release cadence and the experimental label mean you should not plan a product around it.

Second, the feature set is uneven by design. The README spends substantial space on lifetime safety and a tracing GC arena, then says plainly that neither is implemented in cppfront yet. If your interest in Cpp2 is specifically about eliminating dangling pointers by default, the thing you want is in Visual Studio, CLion and a Clang fork, not here. The README's own framing of the GC work, that it needs a real GC expert to make it a usable memory arena, tells you the project does not consider it finished.

Third, the value proposition only holds if you are already fluent in modern C++. Cpp2 is a skin over C++, so the generated code, the error messages from the backend compiler, and the libraries you link are all C++. A team looking for a language that hides C++ rather than resugars it will find the abstraction thinner than expected.

Finally, tooling beyond the compiler is thin in what the README documents. Build integration, editor support and debugging workflows are not described there; the README points to the wiki and the documentation site instead. Verify those before assuming a comfortable daily workflow.

cppfront versus Carbon and other C++ successor efforts

The comparison people search for is cppfront versus Carbon, and the README answers it without naming Carbon: cppfront aims to help evolve C++ itself, not to be a C++ successor. The difference in approach is concrete. A successor language needs its own ecosystem, or at least a credible path to interoperation with the C++ one. cppfront needs neither, because it emits Cpp1 that your existing compiler consumes. There is no separate runtime, no separate standard library, and no separate module system to maintain.

That choice buys compatibility and costs independence. A successor language can fix problems that C++ cannot fix without breaking existing code. cppfront cannot, because every Cpp2 construct has to lower to something today's C++ already supports. The README's claim of zero overhead and direct use of standard modules and concepts is only possible precisely because Cpp2 does not diverge. If you want a language that can make breaking changes, cppfront's design rules it out by construction. If you want to test whether a safer default syntax is workable on top of the C++ you already have, that constraint is the feature.

Maintenance, licensing and what to check before adopting

The repository is not archived, and the last push was on 2026-07-17, so the project is still receiving changes. The release list, however, is short and spaced: v0.7.4 in August 2024, v0.8.0 in October 2024, v0.8.1 in January 2025. Treat releases as milestones rather than a support channel. If you track main, you are tracking an experimental compiler between releases, and the README's link to a status summary discussion is the closest thing to a changelog of implemented features.

Upgrade cost is mostly the cost of recompiling your .cpp2 sources against a new cppfront and then recompiling the generated Cpp1. Since the output is ordinary C++, your existing build, test and debug tooling does not change. The risk is in the generated code shifting between versions, which is a normal hazard for a compiler at this stage.

The license field on the repository is NOASSERTION, meaning the hosting platform could not classify it automatically. The README points to a LICENSE file at the repository root. Read that file directly rather than assuming a standard license, and if the terms matter to your organization, have someone qualified review them. This article does not give legal advice.

A realistic first session

Start with the documentation site rather than the source tree. The README's Installation link is the entry point, and the hello-world page is the intended first program. Build the compiler using the steps on that page, then compile one small .cpp2 file and inspect the generated Cpp1. Reading the output is the fastest way to understand what Cpp2 actually lowers to, and it tells you immediately whether the abstraction matches your expectations.

From there, the regression-tests/ and passthrough-tests/ directories are the most useful part of the repository for a newcomer. They show the constructs the project itself exercises. The status summary discussion linked from the README tells you which of those are considered done. If a feature you care about is not in that summary, assume it is not implemented, regardless of how prominently it appears in the project's talks and papers.

One more practical note: because cppfront emits Cpp1 rather than object code, your first debugging session will involve two artifacts, the .cpp2 you wrote and the .cpp it produced. Keep both open. When a backend compiler error points at a line in the generated file, mapping it back to the Cpp2 source is the skill this workflow demands.

Editorial conclusion

cppfront is for C++ committee participants, compiler engineers and language designers who want to try proposed features in a smaller compiler, and for experienced C++ developers curious about the syntax 2 direction. It is not for production code or teams wanting a supported toolchain: the README calls it a personal experimental compiler, the last push was on 2026-07-17, and the latest release is v0.8.1 from 2025-01-31. Before committing time, read the status summary linked in the README, check the LICENSE file for the actual terms, and confirm that your C++20 or higher compiler and build system are one of the configurations covered by the CI badge workflow.

Frequently asked questions

Official sources

1. hsutter/cppfront on GitHub
2. Issues
3. README
4. Releases