circle VS papers

Sean Baxter created a front end c++ compiler by himself, using llvm for the back end and the gcc or clang stl. I think it took him a couple of years. https://www.circle-lang.org/. Before this happened I heard a couple of different people claiming that there would never be a totally new compiler as it was too much work.

The real Typescript for C++ is Circle.

https://www.circle-lang.org/

Just like Typescript to JavaScript, the syntax is an evolution of what already exists, not a completely different syntax.

Sean Baxter's Circle [1] is arguably the spiritual successor to MOP.

[1] https://www.circle-lang.org/

Context: https://github.com/seanbaxter/circle/blob/master/new-circle/...

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?

From all wannabe C++ replacements candidates, the only language that is really a TypeScript for C++, is Circle.

For whatever reason, Herb Sutter decided to ignore this language on the presentation.

https://www.circle-lang.org/

This is the only one with the syntax based on C++, incrementally changing the features via #pragma settings.

"Circle Fixes Defects, Makes C++ Language Safer & More Productive"

https://www.youtube.com/watch?v=x7fxeNqSK2k

"Circle Evolves C++"

https://www.youtube.com/watch?v=P1ZDOGDMNLM

The second someone makes a successor language that seamlessly/directly interops with C++ _AND_ has the level of build/IDE tooling that C++/Rust have, I'm on board.

The closest thing right now is Sean Baxter's "Circle" compiler in "Carbon" mode IMO:

https://github.com/seanbaxter/circle/blob/master/new-circle/...

Unfortunately, Circle is closed-source and there's no LSP or other tooling to make the authoring experience nice.

I read through the whole of https://github.com/seanbaxter/circle/blob/master/new-circle/README.md and man, I'm drooling. Awesome work, kudos.

Have a look at Circle from Sean Baxter [0]. It's pretty impressive.

[0]: https://github.com/seanbaxter/circle/blob/master/new-circle/...

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884

Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

> The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code).

Additionally,

> Another problem is formatting of Unicode text:

> std::cout << "Привет, κόσμος!";

> If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake despite the fact that the system is fully capable of printing Unicode

See https://github.com/cplusplus/papers/issues/557

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

GitHub would not be relevant in this respect because:

* It's owned by a (single) commercial corporation, Microsoft.

* There is censorship both by content and in some respects by country of origin.

* The code is closed.

but otherwise it's an interesting idea.

The C++ standardization committee uses GitHub to track papers submitted to them, see:

https://github.com/cplusplus/papers

There was no non-approval. The facility needs more work, and the authors (and the committee) were focusing on getting print/format done first. I hope that the paper will be worked on again in the future. We will be happy to review it once there is a revision (see github for history)

For more details on what we did at the 2023-06 Varna meeting, the [GitHub issue](https://github.com/cplusplus/papers/issues/328) associated with the paper has a summary.

You subscribe to the Github issue of the proposal: https://github.com/cplusplus/papers/issues