Note that Circle is not an F/OSS compiler as someone pointed out before. This however doesn't make Circle less relevant, because it is actually a testament to show that C++ could have been much better without the claimed breakage. If Circle does provide a number of desirable features and its compiler can be built by a single person, then why shouldn't the committee do the same?
> If Circle does provide a number of desirable features and its compiler can be built by a single person, then why shouldn't the committee do the same?
Well, there are downsides to taking Circle's approach which I think are worthwhile to mention. Languages are preferable to everyone creating their own custom DSL. They provide a single target that everyone is able to learn, it allows one to work in a much larger body of work without friction.
When I pull down a library or codebase, I want to be able to immediately hit the ground running instead of having to understand every aspect of how the developers have tweaked the language to suit their preferences, and how each of these tweaks interact with each other. You probably shouldn't rely on people making these choices themselves, because you don't want everyone being a language designer -- it invites a combinatorial explosion with conflicting features that don't play nicely with each other. But mostly, it's about maximizing one's ability to pull down and work in foreign codebases without having to learn a new dialect of a language.
This isn't quite a DSL approach though: the features are turned on and off locally, and don't "escape" from that local source. So provided that one knows the features that can be turned on or off they can just read the source code top to bottom without having to trace which feature was accidentally set in a different file.
Also, re:
> You probably shouldn't rely on people making these choices themselves, because you don't want everyone being a language designer
This would be true for any other language, but with C++ one already has to figure out which subset of features to use, which is basically the same type of choice as turning Circle features on or off.
ISO processes are a complex beast, you will notice that C++ is the exception of having the language author still around, all other programming languages under ISO, the authors kind of moved on after the first revision.
Note even Plan 9 and Inferno's C, isn't quite ISO C89, with Dennis Ritchie hardly taking part in meetings afterwards.
> ISO processes are a complex beast, you will notice that C++ is the exception of having the language author still around, all other programming languages under ISO, the authors kind of moved on after the first revision.
I don't see your point. What leads you to believe that Stroudtrup being involved in C++'s standardization effort is any relevant with regards to where the language is going?
Also, if a standardization process is driven by consensus, what would be the point of trying to force your personal ideas over everyone else's?
On the contrary, many people like to blame him for the direction some decisions have been made, while completely lacking the understanding that he only has one vote among about 300 something.
He has been a kind of C++ consciousness with his books and papers, but C++ isn't a language with BDFL.
HP, IBM and Dec made the point the language had to be part of ISO for industrial adoption. As most languages back then.
Maybe had the language evolved as a foundation with BDFL, many of its warts had been sorted out already.
I don't think that's a very helpful understanding of the situation. Bjarne's influence isn't limited to one of 300 votes. Some random guy from Microsoft with voting rights isn't the same in practice. As an example it seemed pretty clear to me from evidence viewed now, that ~15 years ago Bjarne undermined C++ 0x Concepts in favour of his own simpler less capable design, which C++ eventually got in C++ 20.
Circle has this feature, since Bjarne's C++ 20 feature is called concepts, Sean calls this "interfaces" instead, but it's the C++ 0x Concepts functionality.
I also don't buy the story that poor Bjarne was strong armed into his leading role on WG21 (the C++ language committee). Does Brain Kernighan play a similar role at WG14 (the C language committee)? No. He's moved on, Bjarne has not.
Are people suggesting that a BDFL would be better? I see a lot of dissatisfaction with ISO but that's not the same thing. Rust doesn't have a BDFL, and these days neither does Python. Maybe neither BDFLs nor ISO committees (well, specifically JTC1 sub-sub-committees, these are all under JTC1's SC22, a sub-committee for programming languages) are a good way to develop programming languages.
WG21's "Direction Group" is a handful of "experienced" people, by-invitation only, which has "been decided" (by itself of course, with a little help from Herb) to choose the future direction of C++. It further decided that to shape their work they should consult what was written in a book and in several papers about C++, all of them written by one of its members, Bjarne Stroustrup.
It reserves the right to chime in on absolutely everything, and has an "expectation" that everybody else (e.g. chairs of sub-committees) will take the Direction Group's advice.
> Concepts Lite is a consequence of ISO politics, it was either that or nothing all.
On the contrary, WG21 had voted in C++ 0x Concepts for the standard which would eventually become C++ 11 but after that Bjarne wrote a paper claiming that you don't need all these fancy features other people designed. You do, which is why C++ 20 Concepts achieves so little - but his paper was influential.
Over the next several months, the argument was made that C++ 0x shouldn't have this complicated C++ 0x Concepts feature which they had voted in because it wasn't implemented yet, and anyway Bjarne says it's not necessary. As JeanHeyd Meneide has observed it's weird, sometimes WG21 feels like it's absolutely crucial to have a working implementation, but then other times (cough modules) they don't see this as important at all and ship the standard with basically a TBD sticker. See if you can guess which WG21 member wanted Modules and also which WG21 member didn't want C++ 0x Concepts.
WG21 went back and ripped C++ 0x Concepts back out of the standard and then spent years more working on what would eventually become C++ 11.
> He has been a kind of C++ consciousness with his books and papers, but C++ isn't a language with BDFL.
Yeah, for a Dane he's surprisingly "Swedish" in his approach (this joke only makes sense if you've lived in Sweden and/or Denmark, but in short: Swedish decision making is extremely consensus based, whereas Denmark is more hierarchical by comparison).
> This however doesn't make Circle less relevant, because it is actually a testament to show that C++ could have been much better without the claimed breakage.
But it does break backwards compatibility, doesn't it? Meaning, if you pass Circle code to a C++ compiler, that's a no-go from the start, isn't it?
What aspect are you focusing on to argue that Circle introducss no breakage?
Every new C++ standard introduces new things that will not work under an old standard.
Not breaking backwards compatibility means that code for old standards should generally still work if recompiled.
Not breaking ABI means it should still work if not recompiled.
Circle is the "C++ Successor" language I am most excited about, after writing a fair amount of D, and trying the Carbon interpreter.
The issue with D is that while it's a great language, and it has C++ interop, it doesn't have _direct_ C++ interop. As in, "just import an existing header and it works." You have to write or try to auto-generate "extern C++" definitions.
The issue with Carbon is that it is slowly-progressing vaporware at this point with as-yet-untested C++ interop.
Circle is real, has a "Carbon" mode that makes it syntactically identical, and yet has "just import it" interop. It's not open-source yet but hey, you can't have everything at once I guess.
---
(I want to add that I think D is a great language in it's own right, just not as "C++ successor")
I had the same vibes with Herb Sutter's cppfront. It offers full source compatibility by introducing a new syntax that can be mixed freely with the traditional syntax. Seems like it's actively being worked on here https://github.com/hsutter/cppfront.
I've not looked at Circle in depth. Do you or anyone else have a perspective on how they compare?
While Herb uses modest language when describing his project, my take is that's because it's a huge effort that might fail, but it does not indicate lack of ambition. If anything, I think this is hugely ambitious. The work in the standards committee provides the necessary infrastructure to make this feasible in the first place. On his Github he lists the changes that went into C++ over the last years that enable this prototype.
It's pretty clever really, and dare I say, it seems feasible. This essentially creates syntax bubbles inside the language where there are different defaults, and then transpiles those bubbles to regular C++ while copying the rest verbatim. See this https://godbolt.org/z/nPPMYM3Yj as an example how array accesses are transpiled to do bounds checking.
In Rust each crate can be compiled with a different edition. If we had this in C++ you could compile one file/module with C++11 and another with C++20. The compiler defaults could change for new code, but be kept the same for old code. Nothing breaks. You opt-in to the new standard one file/module at the time.
> If we had this in C++ you could compile one file/module with C++11 and another with C++20.
I'm not 100% confident but I think you can do this already*. What you can't do, is compile each file with a different compiler or stdlib release.
There's just no reason to do it because C++11 and C++20 are forwards and backwards compatible, so you might as well compile everything with C++20 if you're already going to compile it all from source.
* An exception is omnibus libraries like abseil that take it upon themselves to backport stdlib features to older language versions. For example, abseil uses typedefs to define e.g. absl::optional as std::optional on newer versions or a custom implementation on older versions. If you compile abseil with C++11 and your client code with C++20, then you may end up with scary runtime errors (not compiletime, because templates are compiled in every translation unit, and not linktime, because the linker ignores types).
> There's just no reason to do it because C++11 and C++20 are forwards and backwards compatible, so you might as well compile everything with C++20 if you're already going to compile it all from source.
This isn't exactly true. The programming language version is one dimension of the problem, but there are a few other dimensions. For instance, some projects enable/disable features based on the language version, and that leads to unexpected errors. I recall that Boost caused a bunch of problems when upgrading a compiler version on a old legacy project just because the subproject enabled constexpr on C++11 which caused obscure linker errors out of nowhere.
There is far more to language version upgrades, and even compiler version upgrades, than flipping a switch.
Yep, that’s right. I would include that in the same exception that I listed, where libraries can choose to reflect on the language version that they are compiled with and expose different behavior that can cause issues.
I should mention that the pedantic reason why I have experience with this is that it is usually okay to compile and link with distribution-provided binary packages (where you don’t control the language version) as long as you use the distribution-provided toolchain, and upgrading the language version that you use for your code won’t cause any issues unless one of your dependencies is doing this kind of reflection. Some Linux distros will provide separate versions of packages for each language version in order to solve the problem for libraries like abseil and boost.
In circle the features are literally per-file. Which means you can have a source file that enables a feature and which include headers which doesn't use that feature, which in turn includes another one that includes that header etc.
At first look it seems that the problem is self inflicted and that if we got rid of headers and use modules c++ would be like rust.
But even in rust, editions can only be applied at the level of a crate. Crates are effectively the compilation units of rust
What circle does is more granular and it would be the equivalent of a rust edition per module or pet file.
Fun fact: internally it's not per crate, but per AST node. This is because macros can be imported across crates that use different editions, and still work as expected.
I agree with his approach but I'm on macOS so I don't think I can even use this currently. Anyone know if he has a plan to get this out so everyone can use it? It's not like the authors of Clang are going to implement this. Is he trying to get the C++ committee to standardize this idea? Or will he make a commercial product? If it were cross-platform I would pay for it.
I do love the co_await, co_..., saga because JS has the same issue, only worse because all JS on the web always starts as source code, at least when you're running shipped C++ it has already been compiled and hence language changes don't impact already shipped code.
For example when JSC first implemented support for `let` (apparently first or with the most effective testing?) we rapidly found site breakages. The first one I looked at was (IIRC) the Le Monde newspaper in France, which was doing some kind of parsing with a variable named `let` for the current letter. Rather than making the language more annoying to use, we updated the spec to allow let to be an identifier, which is perfectly reasonable as the let syntax is unambiguous. That's a tiny amount of complexity for the implementer to produce a much cleaner to use language for developers.
There's similar with `of` in for loops - `of` is syntactically only valid in that location, there's negligible implementation cost in not requiring it to be a keyword, but it allowed the improved iteration syntax to be introduced to the language (Obviously there are a bunch of more common syntaxes that are more consistent with other languages, but for imo stupid reasons I couldn't use any of them and had to come up with a new one :-/).
I didn’t watch the whole thing due to the audio, but what I have seen is this still not ultimately a new language? As someone else here stated, the compiler is determining if the code it sees is Circle or C++ so that means it’s handling them differently. Which means all the legacy cpp code would never touch this and people who already started cpp would need to maintain two separate flavors of the language. Maybe I am misunderstanding this project.
Don't see how that follows. Typescript treats code as either TS or JS depending on the file extension. But that doesn't mean nobody who has JavaScript code would switch to Typescript. The idea is, you migrate one file at a time. With Circle it's even more gradual, since you can migrate one file one feature at a time.
I think the idea is that you can migrate a translation unit at a time anda feature ata time while still being able to link your whole application. Not differently from the migration path between c++ revisions.
As someone with a lot of live audio background, I lament bad audio at conferences. I keep thinking that there is a product need there, but it feels too much like selling vitamins.
Note that Circle is not an F/OSS compiler as someone pointed out before. This however doesn't make Circle less relevant, because it is actually a testament to show that C++ could have been much better without the claimed breakage. If Circle does provide a number of desirable features and its compiler can be built by a single person, then why shouldn't the committee do the same?