HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
hsutter
cppfront
C++2022–2026
hsutter / cppfront

cppfront

A personal experimental C++ Syntax 2 -> Syntax 1 compiler

52Distinct people
55Mentions
1Explicit recommenders
6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A personal experimental C++ Syntax 2 -> Syntax 1 compiler

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Regarding the addition to libxx: I’m not fond of adding an increasing number of specific compiler options which need to be turned on for memory-safety. It should be default…

ho_schi used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year55 dated mentions

Observed mentions: 2022-09-17 01:20:16 UTC to 2026-09-10 19:38:46 UTC.

051015202022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 21 mentions; 0 submissions, 21 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 12 mentions; 4 submissions, 8 comments20242025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC1028
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC21021
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC1248
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC606
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC606

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
cppfront Copyright (c) Herb Sutter • See License Cppfront is a compiler from an experimental C++ 'syntax 2' (Cpp2) to today's 'syntax 1' (Cpp1), to prove out some concepts, share some ideas, and prototype features that can also be proposed for evolving today's C++. You can find the current status summary here: Cppfront status summary (summer 2026) Documentation: available here Installation What's different about this project? In short, it aims to help evolve C++ itself, not to be a "C++ successor." What it isn't. Cpp2 is not a successor or alternate language with its own divergent or incompatible ecosystem. For example, it does not have its own nonstandard incompatible modules/concepts/etc. that compete with the Standard C++ features; it does not replace your Standard C++ compiler or other tools; and it does not require any changes to your Standard C++ compiler or standard library or other libraries or tools to keep fully using all of them. What it is. Cpp2 aims to be another "skin" for C++ itself, just a simpler and safer way to write ordinary C++ types/functions/objects, and a faster way to experiment with proposals for future new Standard C++ features in a simpler compiler and syntax flavor. It seamlessly uses Standard C++ modules, concept requirements, and other features. It also works with all existing C++20 (or higher) compilers, libraries, and tools right out of the box with no changes required to use them all seamlessly and directly, with zero overhead. For more, see What is Cpp2?. Acknowledgments Scores of people have given valuable feedback and many are listed below, but I especially want to thank Joe Duffy, Anders Hejlsberg, Bjarne Stroustrup, Andrew Sutton, Tim Sweeney, and Mads Torgersen for their insights and valuable feedback on this work over the years — especially when they disagreed with me. I'd also like to thank Dave Abrahams, Andrei Alexandrescu, Walter Bright, Lee Howes, Chris McKinsey, Scott Meyers, Gor Nishanov, Andrew Pardoe, Sean Parent, Jared Parsons, David Sankel, Nathan Sidwell, JC van Winkel, and Ville Voutilainen for broad feedback on the design. Many more people are listed below for their help with specific parts of the design and those proposals/prototypes. I apologize for the names I have forgotten. Further information To learn more, please see: 👀 The documentation 👀 My CppCon 2022 talk, "Can C++ be 10x simpler and safer ...?" My CppCon 2023 talk, "Cooperative C++ Evolution: Toward a TypeScript for C++" Update on cppfront at ACCU 2024 This repo's wiki The list of papers and talks below Papers and talks derived from this work (presented in current syntax as contributions toward ISO C++'s evolution itself) Here are the ISO C++ papers and CppCon conference talks I've given since 2015 that have been derived from this work, in the order that I brought each piece forward. Most of the details in the materials below are still current with only incremental updates, apart from the specific syntax of course. 2015: Lifetime safety CppCon 2015: "Writing good C++14... by default" particularly from 29:00 onward shows the Lifetime analysis with live demos in a Visual Studio prototype. CppCon 2018: "Thoughts on a more powerful and simpler C++ (#5 of N): The section starting at 18:00 is an update on the Lifetime status with live demos in a Clang prototype. The final part starting at 1:28:00 shows the Lifetime and Metaclasses proposals working hand-in-hand. This is one of the few places before cppfront where the same compiler has contained prototypes of multiple 'syntax 2'-derived features so I could show how they build on each other when used together. C++ Core Guidelines: Lifetime safety profile is this static analysis adopted by the C++ Core Guidelines. P1179: Lifetime Safety: Preventing common dangling is the same analysis in the WG 21 paper list. This is not yet implemented in cppfront. Implementations are shipping in Visual Studio and in CLion, and initial parts have been upstreamed in Clang. I want to especially thank Matthias Gehre, Gabor Horvath, Neil MacIntosh, and Kyle Reed for their help in implementing the Lifetime static analysis design in Visual Studio and a Clang fork. Thanks also to the following for their input and feedback on the specification: Andrei Alexandrescu, Steve Carroll, Pavel Curtis, Gabriel Dos Reis, Joe Duffy, Daniel Frampton, Anna Gringauze, Chris Hawblitzel, Nicolai Josuttis, Ellie Kornstaedt, Aaron Lahman, Ryan McDougall, Nathan Myers, Gor Nishanov, Andrew Pardoe, Jared Parsons, Dave Sielaff, Richard Smith, Jim Springfield, and Bjarne Stroustrup. 2016: Garbage-collected memory arena CppCon 2016: "Leak-freedom in C++... by default" particularly from 59:00 onward where I show the strawman prototype I wrote of a tracing garbage-collection memory arena. Github.com/hsutter/gcpp: "gcpp: Deferred and unordered destruction" is the GitHub prototype I wrote. This is not yet implemented in cppfront. I welcome a real GC expert to collaborate with on bringing this forward to become a "real" usable tracing GC memory arena that C++ code can opt into, with real C++ zero-overhead costing (don't pay anything if you don't do a gc.new, and if you do use it then have the costs be proportional to the number of gc.new allocations). 2017: Spaceship operator for comparisons, <=> CppCon 2017 (just the intro, first 6 minutes): "Meta: Thoughts on generative C++". P0515: Consistent comparison is the proposal in today's syntax that I proposed, and was adopted, for C++20. This is part of ISO C++20 and C++23, except only for chained comparisons which is implemented in cppfront. Thank you again to everyone who helped land this in the Standard in C++20 and improve it in C++23, including especially Walter Brown, Lawrence Crowl, Cameron DaCamara, Gabriel Dos Reis, Jens Maurer, Barry Revzin, Richard Smith, and David Stone. 2017: Reflection, generation, and metaclasses ACCU 2017: "Thoughts on metaclasses" is the first talk I gave about this. CppCon 2017: "Met
Read the full README on GitHub

What Hacker News says

10 sources
From TFA, the goal is to "explore whether there's a way we can evolve C++ itself to become 10x simpler, safer, and more toolable". First let's look at "toolable": My big issue with Modern C++ these days is not just that it's complex to write, but that it also takes a long time to compile, what with all the template/compiler magic going on in the background. Long compile times break concentration, which I don't like. C++2 is not going to improve compilation times, because it's going to be compiled to C++, and then undergo another compilation step. If I combine C++'s slow compile times, two compilers, and all the dumb bugs that I can create and have to debug+fix, I get ....... (pls wait compiling) .......... Let's switch context and look at "simpler": Yay functions look more like JS lambdas or whatever. Fine. Let's look for the pointer-y st
Read the rest
uff. Like [1] -- in C or "normal" aka "pre-modern" "C++1" you'd have: int x = 42; int *p; p = &x; func(*p); In the "simpler" "C++2" you have: x: int = 42; p: *int; p = x&; func(p*); I sure hope the changed syntax helps with parsing complexity or whatever, because it's not any different for me. Seems like C++2 got jealous of Rust and wanted to remind everyone "hello fellow kids, C++ is also cool pls". Note that even Rust and Go follow the C-style "*p" pointer deref syntax instead of "p*". What happens if I combine "C++1" and "C++2" syntax in the same file? I'm not as smart as Herb Sutter -- Is "p**x" a pointer deref then a mul? Which variable is being dereferenced? Perhaps it is a double deref, or ...? So much for simpler. (also note I haven't talked about template magicks here) What do we have left ... "safer"? sighs Okay, C is unsafe. Yes, C++ has to carry that baggage. Yes, memory corruption is horrible. Yes, buffer overflow errors lost lots of money, and have caused lots of wailing and gnashing of teeth. Yes, Modern C++ alleviates some of that unsafety with templates and a smart compiler. Yes, Rust has a smarter compiler with better static analysis that helps write safer code. But all this statically analyzed safe code still has to provide C wrappers if it's a shared object, or use the C wrappers provided by whichever kernel it's running on. So somewhere underneath all this safety lurk the familiar monsters, and someone's going to reach for them in the name of performance (remember Actix?). What about all the other issues that you can have unrelated to buffer overflows (log4j)? Will C++2 protect me from my own foolishness? Perhaps that's why its so complicated -- all my C++2 code is safe, because I will write no C++2 code. And another thing: why not just do the Raku or Kotlin thing and call it by a different name, and have it be a separate language compiling to C++? Why "C++2"? Calling it C++2 vs C++ makes me think of Python 3 vs Python 2, and oh man that is not a good connection to hint at when claiming full backwards compatibility. Python 3 also got quite complicated compared to Python 2, so that doesn't give me hope either. Now that I think about it, shouldn't this be called C+=2? TL;DR: - C++2 is not going to be more toolable because ultimately you're still compiling template-heavy C++ - C++2 is not going to be more simpler because unusual pointer syntax, confusion when mixing C++1, template magicks still have to exist - C++2 is not safer because you can/have to still write or interface with C/C++ and the footguns therein. - C++2 should not be called C++2, pls let's find a Raku/Kotlin. Let C++ be the complexity monster it is. That's the tradeoff we make when we have to write it. If safety is the issue, can't we just use a sandbox or something? Is C++2 really the better option? [1]: https://github.com/hsutter/cppfront/blob/main/regression-tes...
In Cppfront, Herb Sutter's proposal for a new C++ syntax

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.