Circle Evolves C++ [video]
youtube.com
youtube.com
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?
"simpler by disabling features ..."
"By construction, the resulting edition is fully compatible with existing C++ code."
I do not understand how "disabling features" can be "compatible with existing C++ code".
Since existing code contains no Circle pragmas, it's compiled by the Circle compiler as "standard" C++.
I urge you to try it -- there's binaries and Docker containers available. Takes two seconds.
No, I don't. Some compilers support that, though, namely MSVC, but those practices are a huge code smell that are heavily discouraged for decades.
Wrong "you". They were describing how Circle implements C++ compatibility, not how you personally use non-Circle compilers.
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.
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?
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.
Concepts Lite is a consequence of ISO politics, it was either that or nothing all.
Not sure why he should be to blame for trying to find a subset to make them happen in a way they could be voted in.
I am happy to have a better alternative than enable_if or tag dispatch.
Are you also going to blame Bjarne for how contracts went down?
As for Rust, well, the last couple of months were also relatively interesting in project management misteps.
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.
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).
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.
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.
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?
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.
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'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.
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).
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.
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.
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 :-/).