Overview: What are Cpp2 and cppfront? How do I get and build cppfront? (opens in new tab)

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.

Not sure what is meant by this statement. Both cpp2 and Carbon are different languages, neither of them claim to be just C++.

Both languages will have bidirectional compatibility with C++ so that code written in C++ can be directly accessed from Carbon and code written in Carbon can be directly accessed from C++. Neither of them use an FFI for compatibility.

But you can do that with fmtlib/std::format as well when you provide formatting for custom types, that just becomes:

    fmt::println("Player is at {}", _player_pos);

And now try to do task which should be as trivial as add 1 format character: output number in hexadecimal and leave stream in same state that was before your code.

It becomes cumbersome very fast.

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

Carbon and Cpp2 are both "C++ successors," broadly speaking. However, they take different approaches in their design:

Carbon is a brand-new language that's designed to have seamless interoperability to C++.

Cpp2 is C++, just with a different syntax. (The goal is to even be able to mix Cpp2 and C++ syntax in the same source file. The initial implementation transpiles Cpp2 to C++ source code, similar to how the original C++ implementation transpiled C++ to C, rather than implementing a full compiler.)

Their overall goals appear to be different, too: The Carbon README states, "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should." With that mindset, it sounds like more of a stopgap for projects already invested in C++. In contrast, I believe that Sutter would argue that C++ still has the potential to be a viable choice for many tasks, and Cpp2 is a way to realize that.

Yes but it’s his own personal project

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.

C# is so old by now, if it would be a good replacement for C++ at MS, it would already have replaced it.

I think $() makes much more sense than ()$ in terms of parsing, when you see $ you're looking for a single word token, and $( you're parsing up to the matching )

Maybe it's not much extra workload, but ()$ requires you to pattern-match all bracketed content in a string as a possible capture, and the parser can't determine whether it's a capture or not until the $ or a matching close bracket. Consider parsing "((x)$)" would require parsing the entire string to determine the first bracket wasn't a capture, then we can treat just the first character as a literal, then we have to re-parse the rest of the string again, and can't be sure it's a capture until the $, and then we can evaluate it as a real expression and then continue with the final $.

Other interesting cases would be "(x+(x)$)" or even "((x+(x)$)$)". I'm not sure I could easily predict the parsing of latter, but prefix and permitted unbracketed single word variable names "(x+$x)" is clearer and the second would either be "(x+$(x)$)" or "($(x+$(x)))" both of which are explicit using the prefix form and could simplify to "(x+$x$)" and "($(x+$x))" where the intent seems clearer.

There's the precedent that many languages already use the prefix form which would help newcomers with familiarity, and in fact many of these languages wouldn't even need the brackets and $var would be sufficient, and I can't really see why the spec requires the brackets in the ()$ syntax in string literals but not for expressions in code.

That raises more questions though... Like, why does the capture syntax have to be attached to the captured element?

Rust for example has a single `move` syntax for all-capture vs. no-capture toggle, e.g. `|x| x + foo` (`foo` is stored as a reference) vs. `move |x| x + foo` (`foo` is moved into the closure). While I do want an additional mode for uniformly applying specific methods (typically `.clone()`) for captured elements, that is almost enough for typical closures.

Also, if my reading of the documentation is correct, `$` has to be attached to each occurrence of captured elements. Like, `:(i) = i + foo$ * (foo$ + 1)`. Doesn't that look strange? It is even possible to mix two variants of captures like `:(i) = i + foo$ * (foo&$* + 1)`, and it's not entirely obvious to me what will happen to `foo$` when `foo&$*` is updated. Treating these "upvalues" as a sort of an implicit structure (e.g. `$.foo`) is much more consistent, and a prefix form `$foo` can be regarded as its shorthand.

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

Raises more questions honestly. This looks more different from today’s C++ than Rust.

Something about foolish consistencies…

The priorities of a programming language syntax are to be readable first, consistent second.

When it comes to syntax that is used more frequently then the importance of readability increases, and the importance of consistency drops, because people will become familiar with the syntax through frequency of use, so there is no need for them to be guided by consistency. Yet they will be reading the code more often.

When it comes to syntax that is used infrequently then consistency is of more importance because you want users to be able to intuit the syntax. Since it will be infrequently used, the readability is of lesser impact.

I feel like there are more options than just the ones he listed. Like "Hello ${name}" or "Hello `name`" or "Hello {`name`}"...

Oh, fantastic. Thank you!

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.

+100 btw. =D

Making ++ or -- a statement that increment the target without returning a value should probably be enough for forward iterators.

A noncopying ++ could be spelled `+= 1` though. So some iterators would support `+= 1`, but not `+= 2`. This would be vaguely similar to how the null pointer constant was defined as an integer constant expression that evaluates to zero: Define `+= <integer constant expression that evaluates to one>` as the increment operator.

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

We could allow overloading operator++ while not defining it on anything built-in....

But it’s C++2, and that would become valid! (C + +2)

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.

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!

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 So yes, Kotlin is considered to be a successor language, not just another language (also) compiling to the JVM.

3) is forcing me to incorporate a symbol strip/upload to sentry piping at $WORK because Eigen debug symbols cause our build sizes to explode.

There isn't that much work the compiler should need to do. Ideally, a clever compiler could just update the vtables in some intermediate representation of the program and re-emit the binary. The C++ compiler today is so insanely wasteful - edit one header file and the compiler re-parses all the header files N^2 times. It should be possible to make a compiler thats way faster than any C++ compiler today.

Of course, the elephant in the room is the C++ preprocessor. I haven't looked too closely into cppfront, but if I had the chance, I'd give the C macro system a bullet.

My favorite "macro" system by far is zig's comptime, which is beautiful and elegant. Zig code can simply elect to be executed in the compiler instead of at runtime. For example, here's how the print() function compiles in zig. Its a thing of beauty:

https://ziglang.org/documentation/master/#Case-Study-print-i...

In typical c++ manner, we can’t have nice things because {obscure internal technicality that don’t impact the user in any way whatsoever}$. As a user I don’t care what a vtable is. Just make it work. Other languages don’t have this problem.

During release builds sure, optimize away with LTO and whatever is needed to make it vroom. During development, waiting several minutes for a minor private function update is just absurd.

Yes, there are solutions, and the simplest one is replace the direct vtable lookup with an indirect one where the methods are referenced not by their numeric offsets in the vtable but via their symbolic names and the offset resolution is performed via a separate lookup table – not that dissimilar from how it is done in ELF shared libraries.

All of them will result in incurring a performance penalty, either at the runtime, or at the start-up time, or in the compiler/linker, and memory blowouts. But it will solve the recompilation problem.

Um... isn't that guaranteed? What would it mean for a private function to be virtual? It can't be overridden by a different implementation in a child class...

Wait, what? Virtual methods in C++ are opt-in. You only need the 'final' keyword when you're overriding a method in a child class.

C++ build systems are typically based on file timestamps. Modifying a header file triggers recompilation of all translation units including that header.

There are workarounds like pimpl (aka. C style encapsulation). But this requires extra boilerplate and indirection. C++ modules might fix it at some point, but after 35 years of not having them in C++ most real life codebases aren't set up that way and may never be.

Adding private functions or fields requires changing the class declarations, which requires rebuilding any code that includes that class deckaration. It shouldn't be like that, especially for methods which shouldnt change anything about the class ABI.

Even worse, this dependency is transitive. Dependencies to allow defining these private methods an fields are exposed too, forcing inclusion of headers to all members of the class, even if it's only implementation details.

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

If you touch a header, even private only, includers will rebuild. Modules might fix this.

Hylo is interesting in principle for exploring this particular notion (mutable value semantics) as a way to potentially write software without the lifetime annotations Rust needs.

But I don't find it promising that after apologising in 2023 for missing their self-imposed 2022 deadline to ship something that works and other people can use, in Q2 2024 it doesn't look like their new 2023 roadmap got done either. Maybe they're going to eventually deliver this amazing thing. Maybe they're just going to learn some lessons (probably for the Swift community) and never ship Hylo per se. Certainly 2025 "Take over the world" looks... ambitious with nine months left to do all the stuff left from 2023 and all the work described for 2024 on top.

Notice that there are in practice three distinct implementations of the C++ standard library. They're all awful to read though, here's Microsoft's std::vector https://github.com/microsoft/STL/blob/main/stl/inc/vector

However you're being slightly unfair because Rust's Vec is just defined (opaquely) as a RawVec plus a length value, so let's link RawVec, https://doc.rust-lang.org/src/alloc/raw_vec.rs.html -- RawVec is the part responsible for the messy problem of how to actually implement the growable array type.

Still, the existence of three C++ libraries with slightly different (or sometimes hugely different) quality of implementation means good C++ code can't depend on much beyond what the ISO document promises, and yet it must guard against the nonsense inflicted by all three and by lacks of the larger language. In particular everything must use the reserved prefix so that it's not smashed inadvertently by a macro, and lots of weird C++ idioms that preserve performance by sacrificing clarity of implementation are needed, even where you'd ordinarily sacrifice to get the development throughput win of everybody know what's going on. For example you'll see a lot of "pair" types bought into existence which are there to squirrel away a ZST that in C++ can't exist, using the Empty Base Optimisation. In Rust the language has ZSTs so they can just write what they meant.

Part of the distinct "C++ std" style is due to naming rules and textual includes. Every name that's not part of the standardized interface starts with __ because __foo and _Foo are blanket reserved names, so a user can't complain that std:: explodes when he does "#define _Base 0".

> 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)

I work on clang and don't know go yet still find the go version easier to read.

I think the c++ version could be more understandable but it’s as if the authors intentionally made it as obtuse as possible.