Circle C++: C++ superset to add Memory Safety based on Rust's borrow checking (
from to on 03 Jun 06:00

From the page:

My aim is to produce a superset of C++ that has a rigorously safe subset. Start a new project, or take an existing one, and write safe code in C++. Code written in the safety context exhibits the same strong safety guarantees as safe code programmed in Rust. Indeed, lifetime safety is enforced statically with borrow checking, the signature safety technology first introduced in Rust

What properties characterize Safe C++?

  • A superset of C++ with a safe subset. Undefined behavior is prohibited from originating in the safe subset.
  • The safe and unsafe parts of the language are clearly delineated, and users must explicitly leave the safe context to use unsafe operations.
  • The safe subset must remain useful. If we get rid of a crucial unsafe technology, like unions or pointers, we should supply a safe alternative, like choice types or borrows. A perfectly safe language is not useful if it’s so inexpressive you can’t get your work done.
  • The new system can’t break existing code. If you point a Safe C++ compiler at existing C++ code, that code must compile normally. Users opt into the new safety mechanisms. Safe C++ is an extension of C++. It’s not a new language.
#feature on safety
#include "std2.h"

int main() safe {
  std2::vector<int> vec { 11, 15, 20 };

  for(int x : vec) {
    // Ill-formed. mutate of vec invalidates iterator in ranged-for.
    if(x % 2)

    unsafe printf("%d\n", x);
$ circle iter3.cxx
safety: iter3.cxx:10:10
mutable borrow of vec between its shared borrow and its use
loan created at iter3.cxx:7:15
  for(int x : vec) {

A couple other languages aiming to create a “C++ successor” which is fully interoperable with C++ (analogous to TypeScript and JavaScript):

Compared to the other languages, Circle remains closest to C++. The other languages try to fix other C++ “problems”; Circle’s only goal is to fix memory unsafety, and otherwise keep syntax and semantics the same for maximum interoperability.


threaded - newest on 03 Jun 06:51 next collapse

<img alt="" src="">

Gotta start somewhere though. on 03 Jun 07:43 collapse

I feel like this is one of those XKCDs that automatically opts you out of sensible debate if you post it. on 03 Jun 10:15 collapse

That’s why I keep this image in my back pocket:

<img alt="" src="">

It may not directly create sensible debate, but it conters the thought terminating effect of the xkcd.

Edit: new link to the image on 03 Jun 11:41 next collapse

I’m going to steal this. on 03 Jun 23:20 collapse

What’s the image? I just get an error message. on 04 Jun 00:54 next collapse

Now I’m just curious if that was intentional. on 04 Jun 08:01 collapse

No, my instance was down. on 04 Jun 07:58 collapse

It’s the “We Should Improve Society Somewhat” meme with society replaced with technology and the answer replaced with the xkcd.…/2705714-we-should-improve-soci… on 03 Jun 09:04 next collapse

Circle is a bit weird, since instead of being a new language, it’s (or at least was when I last checked it out) technically a conforming C+±compiler, just with a lot of extensions. If we had interest, a lot of the stuff there could be standardised. on 03 Jun 21:46 collapse

FWIW, cppfront would be the same, IMHO. It allows C++ syntax, and it just passes it through verbatim. Only transforms “syntax 2” into today’s C++. And Herb Sutter very much says that what it does is based on the papers that he’s presented for standardization, and that he’d like this approach (new syntax) land into today’s C++ compilers and the standard.

cppfront is the only one that I thought had a chance till recently. The presentations from Sean Baxter seem to finally make the community see it on a positive light (I’ve seen posts on Reddit being removed on the premise of not being C++, which I think it’s a bit unfair), so that’s good. on 04 Jun 05:03 collapse

I do not really agree with cppfront being the same, given that it basically needs a full transpiler in front. A lot of the stuff there though is something that could be standardised though (and some of it absolutely shouldn’t, I’m looking at you UFCS), but I don’t think there’s much support for changing any of the core syntax.

I kinda understand the r/cpp stance, because it’s a bit difficult to draw the line there, but yeah, it feels a bit unfair. I think the first step of getting circle-like stuff into the language would be to standardise the #feature somehow. on 04 Jun 10:28 collapse

Note that the scope of “New Circle” is much bigger than “just” memory safety: choice types, pattern matching, …