Thanks to everyone who has offered bug reports and constructive suggestions for Cpp2 and cppfront.
To answer common questions I encounter repeatedly, I’ve started a wiki with “Design notes” about specific aspects of the design to answer why I’ve made them they way they currently are… basic rationale, alternatives considered, in a nutshell. There are four design notes so far… pasting from the wiki:
- Design note: UFCS Why does UFCS use fallback semantics (prefer a member function)? Doesn’t that mean that adding a member function later could silently change behavior of existing call sites?
- Design note: const objects by default Should objects be
const? Mostly yes. - 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.
- 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.
The wiki also contains links to related projects. There are two of those so far:
- /modern-cmake/cppfront: A modern CMake (3.23+) build for cppfront, complete with automatic cpp2-to-cpp1 translation. Compatible with
find_package,add_subdirectory, andFetchContent. - /JohelEGP/jegp.cmake_modules/#jegpcpp2: A CMake module to build Cpp2 source files.
Thanks again for the feedback and interest.
Sutter’s Mill 
I don’t have a link. My thought came out of my head, not from an existing implementation.
I think minimal design would be that if a method in the class is tagged ‘final’, then the compiler must not allow overloads with UFC syntax, and if a free-form function wants to extend a class, then it must be tagged with ‘override’.
I’d be happy to look at a design… is there a link to a summary of such a design in another language, to show how it’s done tastefully and hear what the field experience is?
This does sound like it overlaps with C# extension methods style, so I’ve added a section at the end of that design note about those, and why I think that design option is orthogonal to the listed options. One drawback, which I suspect the above suggestion shares (as I understand it from the description), is that it requires advance knowledge and opting in a type-specific way; see the discussion of the extension methods style for why I’d be concerned that it’s not as composable or general as we’d want.
About UFCS design note article: The five options in your blog article aren’t all of the options. Some design work should be paid to appropriately divide the control between the type author and the extension author, and a well-designed syntax which would tastefully reuse keywords ‘override’ and ‘final’ should be able to do that.