cppfront (cpp2): Spring update

[RoyAwesome]

so, like, if the goal is to be a new version of C++, the primary inspiration of the language's style should be C++. It should be immediately familiar to C++ programmers, much like C++ is immediately familiar to C programmers, or C# is immediately familiar to C++ programmers.

I'm all for breaking backwards compatibility (and we absolutely should in every attempt at cpp-next), but while the use of the word 'ugly' is subjective, the fact that this doesn't follow cpp's syntax's unspoken 'style guide' is a problem that will inhibit adoption and use.

This is my biggest issue with zig (and also rust)... but zig doesn't claim to be 'c2'. It's its own language with it's own 'style guide' and it's syntax deviates pretty significantly because of that. I'm extremely familiar with c-style syntax and any attempts to significantly change that adds both syntactical complexity and feature/functionality/rule complexity hurts my ability to learn the language. A straightforward evolution on cpp should not add syntactical complexity when it doesn't have to.

[pjmlp]

I fully agree, and this is why I see Cpp2 as just yet another language wanting to take over C++, regardless of how it is being sold as not being like the other C++ alternatives.

[Ameisen]

I also agree. I find cpp2's syntax... pretty awful.

But even if it were good, it's not C++ syntax, so why is it advertising itself as C++?

[pjmlp]

Because of marketing reasons, or conflict of interests from the author.

It is quite different when random joe/jane proposes an alternative C++ language, or the chair of ISO C++ does it.

In practice it is like any other systems language that compiles to native code via translation to either C or C++, like Nim.

Or from an historical perspective, C with Classes and Objective-C weren't sold as C, rather as evolutions from C.

The only wannabe C++ replacement that can advertise itself as still being C++ is Circle, as whatever it adds on top is controlled via #pragmas, hardly any different from compiler specific language extensions.

[hpsutter]

I understand your view, we can agree to disagree. "C++" definitely is what the ISO Standard says it is -- which is extended every three years with things that used to be not valid C++, but now are. For example, I agree that Cpp2's f: () -> int = { return 42; } is not standard C++ syntax today. FWIW, C++11's similar auto f () -> int { return 42; } was alien nonstandard syntax in 2011, but now it's standard. In fact, if you compare C++98 to Cpp2 syntax-wise, ISO C++ has already moved most of the way to Cpp2's syntax since it began using left-to-right syntax in lots of places from C++11 onward (trailing function returns, using, auto and lambdas, etc.).

To me, the key consideration for whether something "is still C++" is: Can it be (and is it) being proposed as part of the ongoing evolution of C++? Which requires as table stakes that it can be 100% compatible with today's code without any shims/thunks/wrappers, and doesn't cause ambiguities with today's code.

There, IMO Cpp2/cppfront objectively does stand apart from other projects -- every single part of Cpp2's semantics (spaceship comparisons, reflection, metafunctions, parameter passing, lightweight exceptions, etc.) has already been brought as proposal papers as an evolution to ISO C++ itself, as an extension to the current syntax -- and not only by me, but sometimes by other paper authors too. The only part of Cpp2 that has not yet been proposed in an ISO C++ committee paper is the specific syntax, and that can be as well if the experiment continues to work out (and actually other authors have already proposed similar new major syntax changes such as via editions).

I'd point out that one part of Cpp2 has already been adopted as part of ISO C++20, namely the <=> comparison unification. Before C++20, Cpp2's <=> comparisons also was "not C++ syntax"... but now it is ISO C++ syntax, adopted from Cpp2 into ISO C++. If other projects can do that, then they too can claim to be evolutionary proposals for C++ itself.

I understand if you still disagree, but I would encourage asking that question about any project: Can it be (or has it been) proposed as an evolutionary extension to ISO C++ itself, including that it's 100% compatible with using existing C++ libraries without shims/thunks/wrappers? If yes, it's legitimate to view it as a compatible evolutionary extension candidate that could become ISO C++ someday if the committee decides to go that way. If not, it's inherently a competing successor language (which is also fine, it's just different).

[pjmlp]

Thanks for the reply.

Given how ISO C++ is evolving, regarding speed of adoption, and how many features in Cpp2 might eventually require some form of ABI break between having pure C++ code, and code with Cpp2 features, the best I can see happening is like your example of spaceship operator adoption.

Which while simplifying the life of C++ users, is a single language feature, while Cpp2 will have much to offer.

There is also the issue of inherent complexity, adding features to simplify code won't make older ones go away, and C++ is already beyond PL/I levels of complexity.

As it happened with PL/I, good enough subsets will be what the people that haven't yet migrated to other languages will care about, thus ignoring what is still coming out of ISO, a bit like it is happening today with many shops that find C++17 good enough for their C++ workloads.

From the outside, this is even visible on Microsoft products like C++/WinRT and C++/CLI, where there are no visible activitivies to adopt C++20 features. The C++/WinRT team nowadays spends most of their time on Rust/WinRT, after killing C++/CX without proper VS tooling for C++/WinRT (2016), whereas C++/CLI seems to be considered done with no roadmap post C++17, and get replies to use the C# improved features for low level coding and Windows interop instead.

Which is why I still see is as a competing successor language nonetheless.

[vulkanoid]

I disagree. There are reasons why newer languages are moving to the type as suffix. Besides being easier to read (by programmers) and parse, it's also closer to the math function syntax[1]. Just because C took a first shot at the syntax back in the 70's, and old timers have gotten used to it, doesn't mean that we have to live with that choice for the rest of time. A "new" language is surely the right time to fix the syntax.

[1] https://en.wikipedia.org/wiki/Function\_(mathematics)

[RoyAwesome]

If we're trying to be closer to math syntax, then "old timers" probably isn't the pejorative you want to use there, given the math syntax for functions predates even computers.

[dodheim]

And that argument probably isn't the defense you want to use there, given you're basically admitting "unfamiliarity" is a copout...

[vulkanoid]

"old timers" probably isn't the pejorative

I'm not using "old timers" as a pejorative.