Home

Welcome to the cppfront wiki!

This wiki collects some Cpp2 language design notes, and links to related projects.

Cpp2 and cppfront documentation is available here

Design notes

These Cpp2/cppfront design notes cover things like rationale for a given design choice, and alternatives considered. They are not intended to be exhaustive, but to give a basic answer to why something is the way it is, always subject to "this is an experiment! we'll learn."

• Design note: ABI. Cpp2 is ABI-neutral, but its immunity from backward compatibility constraints presents an opportunity for link-level improvements, not just source-level improvements.
• Design note: Capture. Should the syntax be suffix $ or something else?
• Design note: const objects by default. Should objects be const? Mostly yes. function later could silently change behavior of existing call sites?
• Design note: Commas. Why are trailing commas allows in all lists?
• Design note: Cpp2 name. Why "Cpp2," instead of "C++2" or "Athena" or "Cppii" or something else?
• Design note: Defaults are one way to say the same thing. Why omitting expressive power you're not currently using is merely removing ceremony, not providing two ways to do the same thing. With specific examples from the general function syntax.
• Design note: Explicit discard. How does Cpp2 treat "ignore this value" discarding consistently across return values, arguments to inout parameters, and arguments to out parameters? Why does Cpp2 make "no-discard" mandatory, including when using UFCS to call existing APIs that do not say Cpp1 [[nodiscard]]?
• Design note: Namespaces. Should namespaces be their own standalone feature, as in Cpp1? They are now, but maybe we can merge them with partial classes.
• Design note: Postfix operators. Why are unary * and & postfix? What about ++? Why does the -> operator naturally disappear?
• Design note: Postfix unary operators vs binary operators. What about examples like a**b?
• Design note: Replacing the preprocessor with reflection and generation. How will we handle cross-platform code without the preprocessor? For example, #if WIN32 > use this, and #if LINUX > use that? We can do better using reflection and generation, specifically metaclass functions, and partial types.
• Design note: UFCS. Why does UFCS use fallback semantics (prefer a member function)? Doesn't that mean that adding a member can introduce hiding?
• Design note: Unambiguous parsing. How does Cpp2 parse things that seem ambiguous and/or challenging, like a<b>c,d>?
• Design note: unsafe code. Yes, I intend that we should be able to write very-low-level facilities in Cpp2. No, that doesn't mean a monolithic "unsafe" block... I think we can do better.

Related projects

Here are some useful projects related to cppfront. These are created and maintained by other people (thanks!), so please direct questions and bug report to the authors. If you think I'm linking to one that shouldn't be linked to, please open an issue and explain why; thanks!

• xmake support for Cpp2/cppfront. By ruki, the creator of xmake. Here is the PR that added support.
• Clang Format with Cpp2 support. By Johel Ernesto Guerrero Peña. A Clang Format fork with support for Cpp2 syntax.
• Meson support for cppfront. By Jussi Pakkanen, creator of Meson.
• /JohelEGP/jegp.cmake_modules/#jegpcpp2. By Johel Ernesto Guerrero Peña. A CMake module to build Cpp2 source files.
• Conan recipe for cppfront. By Fernando Pelliccioni. A cppfront Conan recipe/package in the Conan Center Index (the official package index for Conan). Here is a sample for using cppfront with Conan and CMake.
• /modern-cmake/cppfront. A modern CMake (3.23+) build for cppfront, complete with automatic cpp2-to-cpp1 translation. Compatible with find_package, add_subdirectory, and FetchContent.
• Sublime syntax highlighting for Cpp2. By Andrew Feldman.
• Visual Studio Code syntax highlighting for Cpp2. By Elazar Cohen. The source code is available on GitHub.