Unfortunately the first example already re-uses one of the less good parts of C++, the "<<" operator for std::cout, which always was a bit of a hack (including strange order of operations since << normally is left shift)
Someone on reddit said that the cpp2 repo was a bit old, and that is true, although he may have started this as an experiment influenced by typescript and left it on the side at some times.<p>Anyway I have no idea if cpp2 would get support from microsoft or other devs, but cpp2 seems like the most humble and "least risky" solution for the future of C++, and I really want it to be.<p>What I remember the most that Herb Sutter said in his cpp2 talk, is that it aims to avoid 95% of bad coding practices that C++ allows today.<p>It's safe to say that beyond the valid criticism of C++, that it quite a good goal and it would improve C++, without using a new language, and that's good, because a new language causes problems: new toolchains, new semantics, new specifics, no experience on a new language.<p>Cpp2 is not a new language, it is the same semantics of C++, except it has a new syntax and enforces good practices.<p>One very interesting point: in the future, cpp2 allows a cpp2-only compiler to be born, and it would still live next to C++ binaries without problem. That cpp2 compiler might probably be much faster since the cpp2 is a smaller stricter subset.
Is there any discussion or in-depth explanation of the syntax choices? I understand that a goal was context free unambiguous parsing. But there are some things that surprise me.<p>For example, string interpolation:<p><pre><code> "Hello, (msg)$!\n"
</code></pre>
Why “(msg)$” and not “$(msg)”? Surely the latter is easier to parse?
> // 'BufferSize' is an object defined as a synonym for the value 1'000'000<p>> BufferSize: i32 == 1'000'000;<p>So "value : i32 = 10" is variable, but "value : i32 == 10" is a constant.<p>The difference is so subtle I'm not sure I like it.<p>Later in the documentation you can find "equals: (a, b) a == b;" which is a function but it feels like I need to decipher it because "==" is not for alias in this case.<p>Retaking the example of "equals: (a, b) a == b;" it feels also odd to omit the braces because they are even enforced for if/else branches.<p>I have to admit that everything was interesting until the "Summary of function defaults" part.
Sutter's 2022 cppcon talk¹ is a <i>great</i> introduction to the topic, both the problems it attempts to solve and solutions it was/is settling on. One of those few talks that left me genuinely enthused about the topic.<p>[It is probably worth watching for the Compiler Explorer interjection toward the end alone -- Matt Godbolt Appreciation Society]<p>¹ <a href="https://www.youtube.com/watch?v=ELeZAKCN4tY" rel="nofollow">https://www.youtube.com/watch?v=ELeZAKCN4tY</a>
It's a nice idea, but not clear that it can truly interoperate with vanilla C++ libs which I think is required.
Seems to be waiting for modules to be finalized, but whether cpp2 can call cpp, and cpp can call cpp2 without implementing half of a C++ compiler isn't obvious.
<a href="https://github.com/hsutter/cppfront/issues/594">https://github.com/hsutter/cppfront/issues/594</a>
Looks neat and convincing. But I think the goal (and effort) to make it into the C++ standard would hinder the momentum of adoption. I suspect it would have to go through a lot of politics and bikesheding before making any real-world impact.
Imagine that if Typescript had insisted to get accepted into the Emca standard before widespread adoption and promotion by Microsoft; it would probably still stay in the 'experimental' stage.
I wonder how this compares with Carbon -> C++ [0].<p>Carbon is (was?) a fantastic proposal, but not sure if it has lost steam since it was introduced or how well it is being adopted (be it inside Google or outside)?<p>Being able to incrementally/interchangeably use/call existing C++ code (and vice versa) seems like a great design choice (in Carbon) without having to introspect the actual generated code.<p>Not sure how easy it is to get the cppfront-generated C++ to bridge with existing C++ code (and vice versa)?<p>[0] <a href="https://github.com/carbon-language/carbon-lang">https://github.com/carbon-language/carbon-lang</a>
Related:<p><i>Cppfront, Herb Sutter's proposal for a new C++ syntax</i> - <a href="https://news.ycombinator.com/item?id=32877814">https://news.ycombinator.com/item?id=32877814</a> - Sept 2022 (545 comments)<p>and also <i>Cppfront: Autumn Update</i> - <a href="https://news.ycombinator.com/item?id=37719729">https://news.ycombinator.com/item?id=37719729</a> - Sept 2023 (8 comments)
> Because ++ and -- always have in-place update semantics, we never need to remember "use prefix ++/-- unless you need a copy of the old value." If you do need a copy of the old value, just take the copy before calling ++/--<p>I actually wish ++ and -- operators were removed.
This would simplify everything, nothing to remember whether it's prefix or postfix operator, whether it copies something or not, you would just do "value += 1" and be done with it.<p>- Less mental overhead.<p>- Remove an extra way of doing the same thing.
I know some of the arguments around C++/cpp2 are flawed, but I do love C++ and a project to move it forward with a step-change is exciting to me.<p>A few of my friends and I did Advent of Code in cpp2 this year and it was a (very buggy) blast.
I spent the other day writing an archetype entity component system which made heavy use of template metaprogramming. I try to avoid this if possible, but it was an exercise in seeing how performant I could make it, and so I wanted to offload as much work as I could manage to compile time and avoid things like virtual dispatch. API similar to the basic parts of entt.<p>My take away from the exercise is that this is not a language for human beings. I was successful in writing it, but it was extremely difficult and frustrating. Part of the frustration is because conceptually what I wanted to accomplish was not difficult, but figuring out how to express it was a nightmare. I am not new to the language, I've been writing C++ since 2009, it was the first language I learned and I've spent nearly every day of my life since then writing at least some C++ code. Even so, I can't say that I truly understand this shit.<p>I'm hoping cpp2 brings us someplace closer to a language that mere mortals can understand. I don't want the next generation writing C++.
In this kind of thread I always mentionned Circle[0] from Sean Baxter. It's worth a look.<p>[0] <a href="https://www.circle-lang.org/" rel="nofollow">https://www.circle-lang.org/</a>
Great new idea in cpp. Automated bounds checking in the hello world example sold me straight away. Try and do that as tersely Haskellers. I hope this project gets momentum.
Any good CMake integration besides <a href="https://github.com/modern-cmake/cppfront">https://github.com/modern-cmake/cppfront</a>?
I like the idea, although many choices are arguable. For example, having to introduce mandatory/prohibited white space around binary/postfix operators (like "&") completely spoils the goal of having a more rational syntax.
The whole story about what cpp2 tries to be, distancing itself from other C++ wannabe replacements is only due to be coming from WG21 chair, which naturally can't talk about a C++ replacement as per conflict of interests.<p>Cpp2 isn't an alternative syntax to C++, as much as C++ and Objective-C aren't alternative syntaxes for C, even though they support a subset of it, and were born exactly the same way, code translators into C.<p>C didn't evolve into them, they became their own ecosystem, tainted by the underlying C compatibility.<p>The only alternative that is really a Typescript for C++, is Circle.
I do not understand why there is a push to change the C++ syntax. There are plenty of new natively compiled languages like D, Go, Rust, Zig, Nim, Odin, Crystal, and so on. If you do not like C++ you always can use some of them instead. The problems that make C++ unsafe are semantic and not syntactic ones.
Unless I can step through original source code in debugger, watch variables etc. etc. I could not accept any source to source translator in my practice.
Most of my personal issues aren't with C++ syntax as such (although it also has many problems). My main gripes are:<p>1. Very slow compilation.<p>2. Poor encapsulation, adding private functions requires recompiling all dependents, see (1).<p>3. Comically huge symbols make debugging much harder than it needs to be -- today gdb OOM'd my 16GB laptop when trying to form a backtrace of a typical QT application coredump.<p>Unfortunately it doesn't seem like cppfront can fix these issues. It may still be a worthwhile effort in other respects, of course.
It was when debugging a memory leak which occurred because I forgot to declare the base class destructor as virtual that I started to think C++ was a rather unfriendly language and not really designed to be easy to use.<p>Then a few years later I read the spec for std::launder that I realised C++ was not really designed to be understood.<p>It's a shame because it's actually a rather nice language in some ways. Here's hoping that this project or something similar takes off and separates the good bits from the bad.