12 ms·

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

190 points by cyber1 3y ago

darknavi 3y ago
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. A few of my friends and I did Advent of Code in cpp2 this year and it was a (very buggy) blast.
- Galanwe 3y ago
  > A few of my friends and I did Advent of Code in cpp2 this year and it was a (very buggy) blast. You mean buggy ironically because you were discovering cpp2, or because cpp2 itself was buggy?
JNRowe 3y ago
Sutter's 2022 cppcon talk¹ is a great 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. [It is probably worth watching for the Compiler Explorer interjection toward the end alone -- Matt Godbolt Appreciation Society] ¹ https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY
cies 3y ago
Like Kotlin to Java Or ReScript to OCaml Or Gleam to Erlang
- treyd 3y ago
  Kotlin is a distinct language with new features that (I'm fairly sure) make it non-isomorphic to Java code though. But I can't speak on the others.
  - simon_void 3y ago
    not sure what "(non)-isomorphic" but Kotlin code is interoperable with Java code in both directions. You can easily call Java-code from Kotlin (but I guess that's the easy direction) but you can also call Kotlin code from Java. There exist specific annotations to control how Kotlin code will be converted to bytecode and therefore be invoked from Java, e.g. a function in a Kotlin companion object would normally concerted into a function of a Singleton property called INSTANCE on the base class, but if you annotate it with @JvmStatic it will become a static method of that class in bytecode instead. This means you can write a Kotlin lib that feels very normal to call from Java. here's the relevant part of the documentation: https://kotlinlang.org/docs/java-to-kotlin-interop.html https://kotlinlang.org/docs/java-to-kotlin-interop.html So yes, Kotlin is considered to be a successor language, not just another language (also) compiling to the JVM.
    - treyd 3y ago
      An isomorphism is a structure preserving 1:1 map between two sets or some other pair of structures. While Java and Kotlin are interoperable (because they both target the JVM), they are not isomorphic for precisely the reasons you described. If it was, then you could do round trip machine translation on the syntax in either direction and have a result that's identical to the original. You can't do that because Kotlin extends Java in nontrivial semantic ways (for a concrete example, see Nothing in the article you linked). Cpp2 isn't trying to be a successor language to C++, the article states that it's trying to present an identical feature set in a new skin where the best practices of modern C++ are more ergonomic without introducing any new functionality.
      - tialaramex 3y ago
        > Cpp2 isn't trying to be a successor language to C++ Herb is trying to sell it as not a successor because for now that suits him better. Because C++ is a general purpose language Herb can deliver a "not a new feature" that is so elaborate in practice you would never write the equivalent C++ by hand, but Herb can insist that since technically it can still be transpiled to C++ it's not a different language... right up until that ceases to suit his agenda. Under this model WUFFS (a higher performance yet entirely safe language for writing stuff like codecs and compression algorithms) doesn't "introduce any new functionality" compared to C, since the present WUFFS-the-language is transpiled into C. But I think C programmers would be astonished to hear that C is now apparently higher performance than C and is able to guarantee it's entirely safe...
- Cerium 3y ago
  Or, Cfront to C? :)
- jokoon 3y ago
  or more famously, typescript to javascript, which is the example Herb uses.
- Zambyte 3y ago
  Surprised to see Gleam instead of Elixir, I haven't heard of the former before.
- zem 3y ago
  all of those compile to the respective languages' bytecodes, not to source code
superamadeus 3y ago
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. For example, string interpolation: "Hello, (msg)$!\n" Why “(msg)$” and not “$(msg)”? Surely the latter is easier to parse?
- frankjr 3y ago
  https://github.com/hsutter/cppfront/wiki/Design-note:-Capture#q-why-use-postfix--for-capture-wouldnt---be-nicer-for-string-interpolation-like-python https://github.com/hsutter/cppfront/wiki/Design-note:-Captur...
  - loeg 3y ago
    Raises more questions honestly. This looks more different from today’s C++ than Rust.
    - epage 3y ago
      I feel like consistency goes too for losing the visual parsing benefits of special syntax. Otherwise, we might as well adopt lisp's syntax.
  - breatheoften 3y ago
    What does "for later use" mean? One thing I've noticed recently is that pretty much no language has a good way to simultaneously define a nested structure and assign that structure a name "for later reuse". For example -- suppose I'm dealing with some serialized data structure that come from some external system. Very likely the data model behind this value involves "nested values" which have themselves have some type of which might be reused in multiple places by that external system. When the goal is to just solve problems -- the approach i like to take is to focus on the values i want to consume and produce -- which might themselves contain lots of nested types each with some amount of reuse ... I'd really like a language feature that supports simultaneously defining a type where it's relevant within some other data structure _and also allows_ giving that embedded thing a name for independent reuse ... I wonder if this postfix $ syntax is related to that use case at all ... (... this comment a speculation based on names of things only without even reading the whole article ...)
colonwqbang 3y ago
Most of my personal issues aren't with C++ syntax as such (although it also has many problems). My main gripes are: 1. Very slow compilation. 2. Poor encapsulation, adding private functions requires recompiling all dependents, see (1). 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. Unfortunately it doesn't seem like cppfront can fix these issues. It may still be a worthwhile effort in other respects, of course.
- ThouYS 3y ago
  under what circumstances does (2) hold? for vanilla methods it's no problem
  - loeg 3y ago
    If you touch a header, even private only, includers will rebuild. Modules might fix this.
  - phkahler 3y ago
    >>> 2. Poor encapsulation, adding private functions requires recompiling all dependents >> under what circumstances does (2) hold? To add a private member variable or function, you need to put it in the class definition in the header file. Then anything that includes the header needs to be recompiled.
    - ThouYS 3y ago
      they don't need to be. dependents will continue functioning, because ABI hasn't changed
      - jstimpfle 3y ago
        Now explain that to my build system. But even if you managed to do that, first compilation is still much slower than it should be, because anlot of headers have to be included (transitively) to allow even declaring these fields and methods.
pciexpgpu 3y ago
I wonder how this compares with Carbon -> C++ [0]. 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)? 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. Not sure how easy it is to get the cppfront-generated C++ to bridge with existing C++ code (and vice versa)? [0] https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang
- mort96 3y ago
  Carbon isn't "being adopted", it's still being developed. Making a programming language takes time. Let them at least get to a point where they release some form of public beta (i.e a few more years, at least) before talking about adoption.
  - chandlerc1024 3y ago
    +100 btw. =D
- nindalf 3y ago
  The roadmap for Carbon [0] mentions wanting to have basic, non-trivial programs written in Carbon by the end of 2024. They're aiming for a v0.1 release in 2025. If it gains traction, they're aiming for a v1.0 beyond 2027. I don't think anyone outside Google will seriously adopt this before it reaches v1.0. Even within Google, they may choose other options. [0] - https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/roadmap.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...
  - bluGill 3y ago
    Googles habit of dropping support for useful things make me not willing to trust them. I plan for my current code to be in use for at least 20 more years (i plan to retire before then), I don't want to explain to my boss either why we are maintaining a compiler or why we must rewrite working code.
suby 3y ago
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. 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. 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++.
- Kwpolska 3y ago
  There are lots of languages for mere mortals. They are not compatible with C++, but that's a feature. The next generation is largely not writing C++.
- logicchains 3y ago
  >I spent the other day writing an archetype entity component system which made heavy use of template metaprogramming. >I'm hoping cpp2 brings us someplace closer to a language that mere mortals can understand. Are you sure the problem is the language itself, and not the inherent complexity of that kind of metaprogramming? As far as I'm aware, Lisp is the language with the cleanest support for such metaprogramming, yet metaprogramming-heavy Lisp code is still quite hard to read. I'm not aware of a programming language in which a compile-time ECS would be easy to write/read.
crazypython 3y ago
What are the tradeoffs between cpp2 and Carbon?
Aardwolf 3y ago
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)
- kreco 3y ago
  Note that the "<<" operator for std::cout is not related to the language itself but related to the standard library.
  - Sharlin 3y ago
    But in a "C++ 2" helloworld one would really expect to see std::println used instead [1]. [1] https://en.cppreference.com/w/cpp/io/println https://en.cppreference.com/w/cpp/io/println
    - tialaramex 3y ago
      Cpp2 is part of the trend for would be "C++ Successor languages" from 2022. The std::println function was standardised in C++ 23, and implementations still don't all provide it in full today. So in effect Cpp2 pre-dates std::println. Herb will have been aware that it exists and is likely for C++ 23, but it doesn't make sense to ship software which requires features you suspect won't be widely available for several years. A "Hello, world" program should not be relying on bleeding edge features.
- userbinator 3y ago
  I've always thought that using "<<" in that manner was more of a way to show off the operator overloading feature than anything else.
  - OskarS 3y ago
    I think the original point was to make a typesafe printf that's still reasonably efficient without creating a bunch of small temporary strings. Like, if you printf like this: printf("Number %d, String %s", n, s); but the types of n and s aren't int and char*, all hell breaks loose and you have the origin of a million CVEs. But how do you make that function signature typesafe, without the tools of modern templates? You sort of can't. One thing you can do is do string append stuff, but the syntax then is annoying: print("Number " + to_string(n) + ", String " + s); This also creates a bunch of temporary strings, which is not ideal (and still relies on operator overloading, btw). In this world, using operators for this does make some sense: std::cout << "Number: " << n << ", String " << s; Like, seen from this perspective, it's not the worst idea in the world, it does work nicely. The syntax really isn't too bad, IMHO (the statefulness part, though, really sucks). It also allows you to add formatting for your own types: just overload operator<<! Clearly, properly type-safe std::format is vastly superior, but the C++ of the 90s simply didn't have the template machinery to make that part of the standard library.
kreco 3y ago
> 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 ++/-- 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. - Less mental overhead. - Remove an extra way of doing the same thing.
- conradev 3y ago
  That is the direction that Swift went: https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md https://github.com/apple/swift-evolution/blob/main/proposals...
  - josephg 3y ago
    Rust and Go made the same choice. In Go, I think i++ is valid - but only as a statement, not an expression. https://go.dev/doc/faq#inc_dec https://go.dev/doc/faq#inc_dec
- AnimalMuppet 3y ago
  But you would break the name! C++ would be a syntax error! I mean, there are people that already think that...
  - kevindamm 3y ago
    We could allow overloading operator++ while not defining it on anything built-in....
  - layer8 3y ago
    But it’s C++2, and that would become valid! (C + +2)
- nathanrf 3y ago
  Unfortunately, C++ uses ++ and -- for iterators, many of which cannot reasonably implement += or -=. This distinction is baked into the type system to tell whether or not an iterator supports efficient "multiple advance" (e.g. a linked list iterator doesn't have += but a pointer into a contiguous vector does). There's no way to fix this in a reverse-compatible way for existing code (which is one of the constraints of cpp2- it must work with all existing C++ so that it is possible for existing projects to migrate regardless of size).
fancyfredbot 3y ago
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. Then a few years later I read the spec for std::launder that I realised C++ was not really designed to be understood. 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.
- josephg 3y ago
  Yeah... its shocking to me how difficult it is to read the C++ standard library. Surely, the standard library is written by the authors of the language. It should be a positive example of how they hope their language is used, right? Here's the source of C++'s vector class: https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a01115_source.html https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a0111... In comparison, vec in rust. (Note you need to scroll down a few pages to start seeing non-trivial functions. There's a lot of block comments.): https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#398 https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#398 Or list in Go: https://cs.opensource.google/go/go/+/master:src/container/list/list.go https://cs.opensource.google/go/go/+/master:src/container/li... To my eye, that C++ code is by far the hardest code to read.
  - lanza 3y ago
    I work on clang and don't know go yet still find the go version easier to read.
  - jcelerier 3y ago
    > It should be a positive example of how they hope their language is used, right? should it though? there's a million ways to learn C++. Reading the std code definitely isn't one - technically the std could be entirely compiler builtins. If you want to read positive examples take A Tour of C++ 3rd edition (https://www.amazon.ca/Tour-C-Bjarne-Stroustrup/dp/0136816487 https://www.amazon.ca/Tour-C-Bjarne-Stroustrup/dp/0136816487)
dang 3y ago
Related: Cppfront, Herb Sutter's proposal for a new C++ syntax - https://news.ycombinator.com/item?id=32877814 https://news.ycombinator.com/item?id=32877814 - Sept 2022 (545 comments) and also Cppfront: Autumn Update - https://news.ycombinator.com/item?id=37719729 https://news.ycombinator.com/item?id=37719729 - Sept 2023 (8 comments)
jokoon 3y ago
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. 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. 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. 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. Cpp2 is not a new language, it is the same semantics of C++, except it has a new syntax and enforces good practices. 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.
- gumby 3y ago
  > Anyway I have no idea if cpp2 would get support from microsoft or other devs… Doesn’t he work for Microsoft?
  - dgellow 3y ago
    Yes but it’s his own personal project
- petre 3y ago
  > 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. That ship has sailed. They already have C#.
  - qalmakka 3y ago
    To be fair C# is vastly different in terms of semantics compared to C++. There's a lot of areas where it's not viable to use C#, and IMHO it also has its own share of legacy and bad decisions from its "Java clone" days that make it impossible to prefer it to C++ sometimes. Btw Microsoft is definitely interested into adopting new languages, just look all the effort they've been pouring into Rust lately.
kreco 3y ago
> // 'BufferSize' is an object defined as a synonym for the value 1'000'000 > BufferSize: i32 == 1'000'000; So "value : i32 = 10" is variable, but "value : i32 == 10" is a constant. The difference is so subtle I'm not sure I like it. 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. 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. I have to admit that everything was interesting until the "Summary of function defaults" part.
alexeiz 3y ago
[flagged]
- eddd-ddde 3y ago
  Why would you use cmake to build a single file??
  - alexeiz 3y ago
    That's the problem, it's a single cpp file because it's built manually. The source code is spread among many hpp files for no reason other than being able to include everything in that single cpp file. The project organization of cpp2 is abysmal.
FpUser 3y ago
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.
- nathanrf 3y ago
  It is a good thing that cppfront lets you do that, then! Cppfront generates #line pragmas which tell the generated .cpp file which source lines to "blame" for each piece of generated code. This isn't something new and fancy for cppfront, it's a bog-standard pragma that your debugger already understands. So it will work the exact same as your current debugging workflow even if you mix cpp and cpp2 source files.
  - wheybags 3y ago
    I'm working on a hobby project language that generates plain C as output, and debugger integration has been one of my big worries. If that works, then this is awesome, thank you!
typ 3y ago
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.
howtofly 3y ago
Any good CMake integration besides https://github.com/modern-cmake/cppfront https://github.com/modern-cmake/cppfront?
- cassepipe 3y ago
  xmake handles cppfront : https://xmake.io/#/guide/project_examples?id=cppfront-program https://xmake.io/#/guide/project_examples?id=cppfront-progra...
grumpy_coder 3y ago
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. https://github.com/hsutter/cppfront/issues/594 https://github.com/hsutter/cppfront/issues/594
- iamaredpanda 3y ago
  It's a just a transpiler to valid C++ code, so calling C++ code from cpp2 should be fine, but calling cpp2 code from C++ is an issue. There is no implementing half of a C++ compiler because it just uses clang or something after it is done transpiling.
carlsborg 3y ago
At this point the focus should be on making interop with python a first class feature.
teo_zero 3y ago
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.
dfgdfg34545456 3y ago
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.
skywal_l 3y ago
In this kind of thread I always mentionned Circle[0] from Sean Baxter. It's worth a look. [0] https://www.circle-lang.org/ https://www.circle-lang.org/
mgaunard 3y ago
I don't want bounds-checking, so lost interest immediately. This is a step in the wrong direction.
- dale_glass 3y ago
  There's barely a point in making a better C++ if you're not going to address one of the most obvious footguns.
  - mgaunard 3y ago
    The main iteration this cycle for the next C++ is contracts. Contracts are all about introducing undefined behaviour if you don't satisfy a precondition. In practice this improves software quality on many levels by clearly defining requirements on interface boundaries that would otherwise be implicit or just documented. Of course you can have special debug modes where you actually check that contracts are being satisfied.
    - tialaramex 3y ago
      > The main iteration this cycle for the next C++ is contracts. As ever the C++ train leaves on schedule with or without anything you suppose is "promised" for that standard revision. This has been the practice since 2011 and I don't expect it to stop unless ISO tells them "Enough" or the whole thing comes apart. > Contracts are all about introducing undefined behaviour if you don't satisfy a precondition. Nope. That's explicitly not what the proposal sets out to do. It is likely that, as usual, WG21 will manage to take facilities intended to be safe, file them to a sharp edge and then slit their own throats, but P2900 in its current form doesn't do so. Here's an item from the proposal's list of things they're explicitly not proposing: "The ability to assume that an unchecked contract predicate would evaluate to true, and allow the compiler to optimize based on that assumption, i.e. the assume semantic" One of the three significant implementers, Microsoft, actually strongly objects to any idea of introducing yet more Undefined Behaviour into a language that is distinctly underwater when it comes to provable correctness. Microsoft shut down previous proposals in this area, and while they might (wrongly IMO) be sold the compromise position that's advocated by some WG21 members today (some UB in some contract checks), you're asking for a lot more.
ibobev 3y ago
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.
pjmlp 3y ago
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. 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. C didn't evolve into them, they became their own ecosystem, tainted by the underlying C compatibility. The only alternative that is really a Typescript for C++, is Circle.

190 points by cyber1 3y ago

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. A few of my friends and I did Advent of Code in cpp2 this year and it was a (very buggy) blast.

Galanwe 3y ago
> A few of my friends and I did Advent of Code in cpp2 this year and it was a (very buggy) blast. You mean buggy ironically because you were discovering cpp2, or because cpp2 itself was buggy?

JNRowe 3y ago

Sutter's 2022 cppcon talk¹ is a great 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. [It is probably worth watching for the Compiler Explorer interjection toward the end alone -- Matt Godbolt Appreciation Society] ¹ https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY

cies 3y ago

Like Kotlin to Java Or ReScript to OCaml Or Gleam to Erlang

treyd 3y ago
Kotlin is a distinct language with new features that (I'm fairly sure) make it non-isomorphic to Java code though. But I can't speak on the others.
- simon_void 3y ago
  not sure what "(non)-isomorphic" but Kotlin code is interoperable with Java code in both directions. You can easily call Java-code from Kotlin (but I guess that's the easy direction) but you can also call Kotlin code from Java. There exist specific annotations to control how Kotlin code will be converted to bytecode and therefore be invoked from Java, e.g. a function in a Kotlin companion object would normally concerted into a function of a Singleton property called INSTANCE on the base class, but if you annotate it with @JvmStatic it will become a static method of that class in bytecode instead. This means you can write a Kotlin lib that feels very normal to call from Java. here's the relevant part of the documentation: https://kotlinlang.org/docs/java-to-kotlin-interop.html https://kotlinlang.org/docs/java-to-kotlin-interop.html So yes, Kotlin is considered to be a successor language, not just another language (also) compiling to the JVM.
  - treyd 3y ago
    An isomorphism is a structure preserving 1:1 map between two sets or some other pair of structures. While Java and Kotlin are interoperable (because they both target the JVM), they are not isomorphic for precisely the reasons you described. If it was, then you could do round trip machine translation on the syntax in either direction and have a result that's identical to the original. You can't do that because Kotlin extends Java in nontrivial semantic ways (for a concrete example, see Nothing in the article you linked). Cpp2 isn't trying to be a successor language to C++, the article states that it's trying to present an identical feature set in a new skin where the best practices of modern C++ are more ergonomic without introducing any new functionality.
    - tialaramex 3y ago
      > Cpp2 isn't trying to be a successor language to C++ Herb is trying to sell it as not a successor because for now that suits him better. Because C++ is a general purpose language Herb can deliver a "not a new feature" that is so elaborate in practice you would never write the equivalent C++ by hand, but Herb can insist that since technically it can still be transpiled to C++ it's not a different language... right up until that ceases to suit his agenda. Under this model WUFFS (a higher performance yet entirely safe language for writing stuff like codecs and compression algorithms) doesn't "introduce any new functionality" compared to C, since the present WUFFS-the-language is transpiled into C. But I think C programmers would be astonished to hear that C is now apparently higher performance than C and is able to guarantee it's entirely safe...
Cerium 3y ago
Or, Cfront to C? :)
jokoon 3y ago
or more famously, typescript to javascript, which is the example Herb uses.
Zambyte 3y ago
Surprised to see Gleam instead of Elixir, I haven't heard of the former before.
zem 3y ago
all of those compile to the respective languages' bytecodes, not to source code

superamadeus 3y ago

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. For example, string interpolation: "Hello, (msg)$!\n" Why “(msg)$” and not “$(msg)”? Surely the latter is easier to parse?

frankjr 3y ago
https://github.com/hsutter/cppfront/wiki/Design-note:-Capture#q-why-use-postfix--for-capture-wouldnt---be-nicer-for-string-interpolation-like-python https://github.com/hsutter/cppfront/wiki/Design-note:-Captur...
- loeg 3y ago
  Raises more questions honestly. This looks more different from today’s C++ than Rust.
  - epage 3y ago
    I feel like consistency goes too for losing the visual parsing benefits of special syntax. Otherwise, we might as well adopt lisp's syntax.
- breatheoften 3y ago
  What does "for later use" mean? One thing I've noticed recently is that pretty much no language has a good way to simultaneously define a nested structure and assign that structure a name "for later reuse". For example -- suppose I'm dealing with some serialized data structure that come from some external system. Very likely the data model behind this value involves "nested values" which have themselves have some type of which might be reused in multiple places by that external system. When the goal is to just solve problems -- the approach i like to take is to focus on the values i want to consume and produce -- which might themselves contain lots of nested types each with some amount of reuse ... I'd really like a language feature that supports simultaneously defining a type where it's relevant within some other data structure _and also allows_ giving that embedded thing a name for independent reuse ... I wonder if this postfix $ syntax is related to that use case at all ... (... this comment a speculation based on names of things only without even reading the whole article ...)

colonwqbang 3y ago

Most of my personal issues aren't with C++ syntax as such (although it also has many problems). My main gripes are: 1. Very slow compilation. 2. Poor encapsulation, adding private functions requires recompiling all dependents, see (1). 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. Unfortunately it doesn't seem like cppfront can fix these issues. It may still be a worthwhile effort in other respects, of course.

ThouYS 3y ago
under what circumstances does (2) hold? for vanilla methods it's no problem
- loeg 3y ago
  If you touch a header, even private only, includers will rebuild. Modules might fix this.
- phkahler 3y ago
  >>> 2. Poor encapsulation, adding private functions requires recompiling all dependents >> under what circumstances does (2) hold? To add a private member variable or function, you need to put it in the class definition in the header file. Then anything that includes the header needs to be recompiled.
  - ThouYS 3y ago
    they don't need to be. dependents will continue functioning, because ABI hasn't changed
    - jstimpfle 3y ago
      Now explain that to my build system. But even if you managed to do that, first compilation is still much slower than it should be, because anlot of headers have to be included (transitively) to allow even declaring these fields and methods.

pciexpgpu 3y ago

I wonder how this compares with Carbon -> C++ [0]. 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)? 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. Not sure how easy it is to get the cppfront-generated C++ to bridge with existing C++ code (and vice versa)? [0] https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang

mort96 3y ago
Carbon isn't "being adopted", it's still being developed. Making a programming language takes time. Let them at least get to a point where they release some form of public beta (i.e a few more years, at least) before talking about adoption.
- chandlerc1024 3y ago
  +100 btw. =D
nindalf 3y ago
The roadmap for Carbon [0] mentions wanting to have basic, non-trivial programs written in Carbon by the end of 2024. They're aiming for a v0.1 release in 2025. If it gains traction, they're aiming for a v1.0 beyond 2027. I don't think anyone outside Google will seriously adopt this before it reaches v1.0. Even within Google, they may choose other options. [0] - https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/roadmap.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...
- bluGill 3y ago
  Googles habit of dropping support for useful things make me not willing to trust them. I plan for my current code to be in use for at least 20 more years (i plan to retire before then), I don't want to explain to my boss either why we are maintaining a compiler or why we must rewrite working code.

suby 3y ago

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. 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. 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++.

Kwpolska 3y ago
There are lots of languages for mere mortals. They are not compatible with C++, but that's a feature. The next generation is largely not writing C++.
logicchains 3y ago
>I spent the other day writing an archetype entity component system which made heavy use of template metaprogramming. >I'm hoping cpp2 brings us someplace closer to a language that mere mortals can understand. Are you sure the problem is the language itself, and not the inherent complexity of that kind of metaprogramming? As far as I'm aware, Lisp is the language with the cleanest support for such metaprogramming, yet metaprogramming-heavy Lisp code is still quite hard to read. I'm not aware of a programming language in which a compile-time ECS would be easy to write/read.

crazypython 3y ago

What are the tradeoffs between cpp2 and Carbon?

Aardwolf 3y ago

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)

kreco 3y ago
Note that the "<<" operator for std::cout is not related to the language itself but related to the standard library.
- Sharlin 3y ago
  But in a "C++ 2" helloworld one would really expect to see std::println used instead [1]. [1] https://en.cppreference.com/w/cpp/io/println https://en.cppreference.com/w/cpp/io/println
  - tialaramex 3y ago
    Cpp2 is part of the trend for would be "C++ Successor languages" from 2022. The std::println function was standardised in C++ 23, and implementations still don't all provide it in full today. So in effect Cpp2 pre-dates std::println. Herb will have been aware that it exists and is likely for C++ 23, but it doesn't make sense to ship software which requires features you suspect won't be widely available for several years. A "Hello, world" program should not be relying on bleeding edge features.
userbinator 3y ago
I've always thought that using "<<" in that manner was more of a way to show off the operator overloading feature than anything else.
- OskarS 3y ago
  I think the original point was to make a typesafe printf that's still reasonably efficient without creating a bunch of small temporary strings. Like, if you printf like this: printf("Number %d, String %s", n, s); but the types of n and s aren't int and char*, all hell breaks loose and you have the origin of a million CVEs. But how do you make that function signature typesafe, without the tools of modern templates? You sort of can't. One thing you can do is do string append stuff, but the syntax then is annoying: print("Number " + to_string(n) + ", String " + s); This also creates a bunch of temporary strings, which is not ideal (and still relies on operator overloading, btw). In this world, using operators for this does make some sense: std::cout << "Number: " << n << ", String " << s; Like, seen from this perspective, it's not the worst idea in the world, it does work nicely. The syntax really isn't too bad, IMHO (the statefulness part, though, really sucks). It also allows you to add formatting for your own types: just overload operator<<! Clearly, properly type-safe std::format is vastly superior, but the C++ of the 90s simply didn't have the template machinery to make that part of the standard library.

kreco 3y ago

> 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 ++/-- 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. - Less mental overhead. - Remove an extra way of doing the same thing.

conradev 3y ago
That is the direction that Swift went: https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md https://github.com/apple/swift-evolution/blob/main/proposals...
- josephg 3y ago
  Rust and Go made the same choice. In Go, I think i++ is valid - but only as a statement, not an expression. https://go.dev/doc/faq#inc_dec https://go.dev/doc/faq#inc_dec
AnimalMuppet 3y ago
But you would break the name! C++ would be a syntax error! I mean, there are people that already think that...
- kevindamm 3y ago
  We could allow overloading operator++ while not defining it on anything built-in....
- layer8 3y ago
  But it’s C++2, and that would become valid! (C + +2)
nathanrf 3y ago
Unfortunately, C++ uses ++ and -- for iterators, many of which cannot reasonably implement += or -=. This distinction is baked into the type system to tell whether or not an iterator supports efficient "multiple advance" (e.g. a linked list iterator doesn't have += but a pointer into a contiguous vector does). There's no way to fix this in a reverse-compatible way for existing code (which is one of the constraints of cpp2- it must work with all existing C++ so that it is possible for existing projects to migrate regardless of size).

fancyfredbot 3y ago

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. Then a few years later I read the spec for std::launder that I realised C++ was not really designed to be understood. 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.

josephg 3y ago
Yeah... its shocking to me how difficult it is to read the C++ standard library. Surely, the standard library is written by the authors of the language. It should be a positive example of how they hope their language is used, right? Here's the source of C++'s vector class: https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a01115_source.html https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a0111... In comparison, vec in rust. (Note you need to scroll down a few pages to start seeing non-trivial functions. There's a lot of block comments.): https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#398 https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#398 Or list in Go: https://cs.opensource.google/go/go/+/master:src/container/list/list.go https://cs.opensource.google/go/go/+/master:src/container/li... To my eye, that C++ code is by far the hardest code to read.
- lanza 3y ago
  I work on clang and don't know go yet still find the go version easier to read.
- jcelerier 3y ago
  > It should be a positive example of how they hope their language is used, right? should it though? there's a million ways to learn C++. Reading the std code definitely isn't one - technically the std could be entirely compiler builtins. If you want to read positive examples take A Tour of C++ 3rd edition (https://www.amazon.ca/Tour-C-Bjarne-Stroustrup/dp/0136816487 https://www.amazon.ca/Tour-C-Bjarne-Stroustrup/dp/0136816487)

dang 3y ago

Related: Cppfront, Herb Sutter's proposal for a new C++ syntax - https://news.ycombinator.com/item?id=32877814 https://news.ycombinator.com/item?id=32877814 - Sept 2022 (545 comments) and also Cppfront: Autumn Update - https://news.ycombinator.com/item?id=37719729 https://news.ycombinator.com/item?id=37719729 - Sept 2023 (8 comments)

jokoon 3y ago

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. 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. 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. 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. Cpp2 is not a new language, it is the same semantics of C++, except it has a new syntax and enforces good practices. 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.

gumby 3y ago
> Anyway I have no idea if cpp2 would get support from microsoft or other devs… Doesn’t he work for Microsoft?
- dgellow 3y ago
  Yes but it’s his own personal project
petre 3y ago
> 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. That ship has sailed. They already have C#.
- qalmakka 3y ago
  To be fair C# is vastly different in terms of semantics compared to C++. There's a lot of areas where it's not viable to use C#, and IMHO it also has its own share of legacy and bad decisions from its "Java clone" days that make it impossible to prefer it to C++ sometimes. Btw Microsoft is definitely interested into adopting new languages, just look all the effort they've been pouring into Rust lately.

kreco 3y ago

> // 'BufferSize' is an object defined as a synonym for the value 1'000'000 > BufferSize: i32 == 1'000'000; So "value : i32 = 10" is variable, but "value : i32 == 10" is a constant. The difference is so subtle I'm not sure I like it. 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. 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. I have to admit that everything was interesting until the "Summary of function defaults" part.

alexeiz 3y ago

[flagged]

eddd-ddde 3y ago
Why would you use cmake to build a single file??
- alexeiz 3y ago
  That's the problem, it's a single cpp file because it's built manually. The source code is spread among many hpp files for no reason other than being able to include everything in that single cpp file. The project organization of cpp2 is abysmal.

FpUser 3y ago

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.

nathanrf 3y ago
It is a good thing that cppfront lets you do that, then! Cppfront generates #line pragmas which tell the generated .cpp file which source lines to "blame" for each piece of generated code. This isn't something new and fancy for cppfront, it's a bog-standard pragma that your debugger already understands. So it will work the exact same as your current debugging workflow even if you mix cpp and cpp2 source files.
- wheybags 3y ago
  I'm working on a hobby project language that generates plain C as output, and debugger integration has been one of my big worries. If that works, then this is awesome, thank you!

typ 3y ago

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.

howtofly 3y ago

Any good CMake integration besides https://github.com/modern-cmake/cppfront https://github.com/modern-cmake/cppfront?

cassepipe 3y ago
xmake handles cppfront : https://xmake.io/#/guide/project_examples?id=cppfront-program https://xmake.io/#/guide/project_examples?id=cppfront-progra...

grumpy_coder 3y ago

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. https://github.com/hsutter/cppfront/issues/594 https://github.com/hsutter/cppfront/issues/594

iamaredpanda 3y ago
It's a just a transpiler to valid C++ code, so calling C++ code from cpp2 should be fine, but calling cpp2 code from C++ is an issue. There is no implementing half of a C++ compiler because it just uses clang or something after it is done transpiling.

carlsborg 3y ago

At this point the focus should be on making interop with python a first class feature.

teo_zero 3y ago

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.

dfgdfg34545456 3y ago

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.

skywal_l 3y ago

In this kind of thread I always mentionned Circle[0] from Sean Baxter. It's worth a look. [0] https://www.circle-lang.org/ https://www.circle-lang.org/

mgaunard 3y ago

I don't want bounds-checking, so lost interest immediately. This is a step in the wrong direction.

dale_glass 3y ago
There's barely a point in making a better C++ if you're not going to address one of the most obvious footguns.
- mgaunard 3y ago
  The main iteration this cycle for the next C++ is contracts. Contracts are all about introducing undefined behaviour if you don't satisfy a precondition. In practice this improves software quality on many levels by clearly defining requirements on interface boundaries that would otherwise be implicit or just documented. Of course you can have special debug modes where you actually check that contracts are being satisfied.
  - tialaramex 3y ago
    > The main iteration this cycle for the next C++ is contracts. As ever the C++ train leaves on schedule with or without anything you suppose is "promised" for that standard revision. This has been the practice since 2011 and I don't expect it to stop unless ISO tells them "Enough" or the whole thing comes apart. > Contracts are all about introducing undefined behaviour if you don't satisfy a precondition. Nope. That's explicitly not what the proposal sets out to do. It is likely that, as usual, WG21 will manage to take facilities intended to be safe, file them to a sharp edge and then slit their own throats, but P2900 in its current form doesn't do so. Here's an item from the proposal's list of things they're explicitly not proposing: "The ability to assume that an unchecked contract predicate would evaluate to true, and allow the compiler to optimize based on that assumption, i.e. the assume semantic" One of the three significant implementers, Microsoft, actually strongly objects to any idea of introducing yet more Undefined Behaviour into a language that is distinctly underwater when it comes to provable correctness. Microsoft shut down previous proposals in this area, and while they might (wrongly IMO) be sold the compromise position that's advocated by some WG21 members today (some UB in some contract checks), you're asking for a lot more.

ibobev 3y ago

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.

pjmlp 3y ago

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. 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. C didn't evolve into them, they became their own ecosystem, tainted by the underlying C compatibility. The only alternative that is really a Typescript for C++, is Circle.