Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

Overall reaction

• Many are excited by cpp2/cppfront as a pragmatic way to modernize C++ while keeping existing code and tooling.
• Others are skeptical it can address core C++ pain points or gain enough momentum, especially if tied to the standardization process.
• Some tried cpp2 (e.g., Advent of Code) and found it fun but still buggy and experimental.

Is cpp2 a C++ successor?

• cpp2 is described as “not a new language” but a new syntax for the same C++ semantics, aiming to enforce better practices and avoid most legacy traps.
• Several commenters argue this is functionally a successor language (like early Cfront, Objective‑C, or Kotlin), regardless of how it’s marketed, and that it could drift away over time.
• Others see this “non-successor” positioning as necessary given the author’s standards‑committee role.

Syntax and language design debates

• String interpolation syntax (... )$ drew criticism; some prefer $() / ${} or more conventional forms, and question the parsing rationale.
• The capture and postfix $ design is considered by some to be hard to read and over‑optimized for consistency rather than readability.
• Some like enforced braces and safer defaults; others dislike subtle distinctions like = vs == for variables vs constants.
• There’s recurring sentiment that removing legacy operators (like ++/-- as expressions) and avoiding << I/O would be cleaner.

Interop, tooling, and debugging

• cppfront is a source‑to‑source transpiler to C++, so calling C++ from cpp2 should be straightforward.
• Calling cpp2 from C++ is less clear long‑term; full bidirectional, module‑level interop is seen as an open design/implementation problem.
• Use of #line pragmas means debuggers can step through original cpp2 source, which reassures some skeptical of transpilers.
• Basic build integration exists (e.g., CMake modules, xmake support), but ecosystem maturity is still early.

C++ pain points cpp2 may or may not solve

• Major complaints about C++ include: slow compilation, header‑based encapsulation issues, fragile ABI/vtables, enormous debug symbols, and unreadable standard library implementations.
• Commenters generally agree cpp2’s new syntax alone cannot fix compilation model, ABI, or symbol size; modules and deeper toolchain changes would be needed.
• Some see cpp2 as a way to later build a “cpp2‑only” compiler that could be faster and simpler because cpp2 is a stricter subset.

Comparisons to other “C++ successors” and languages

• Frequently compared to TypeScript→JavaScript, Kotlin→Java, Gleam/ReScript→their hosts, and Cfront→C.
• Carbon is mentioned as another C++‑successor effort with different goals: a new language with C++ interop rather than a new C++ surface syntax.
• Some argue that if you don’t like C++, there are already many alternative systems languages (Rust, Zig, D, Go, etc.), and changing C++ syntax doesn’t fix semantic unsafety.

Safety, bounds checking, and undefined behavior

• Automatic bounds checking in cpp2 examples is praised by some as addressing a key C++ footgun; others reject bounds checks as a performance or control loss.
• Broader debates around contracts and undefined behavior in C++ surface: some see contracts (with UB on violation) as essential; others see more UB as harmful and politically driven in the committee.
• A recurring undercurrent: many want a language with C++’s power but without the sharp edges, lifetime complexity, and template metaprogramming pain; cpp2 is seen as a possible but not guaranteed path toward that.