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) vec^.push_back(x); unsafe printf("%d\n", x); } }
$ circle iter3.cxx safety: iter3.cxx:10:10 vec^.push_back(x); ^ 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):
- Carbon: an entirely new language which compiles straight to LLVM, but still strives to be highly interoperable with C++. Its goal is to add "modern" features: new syntax, parametric polymorphism, as well as removing C++'s backwards-compatibility quirks.
- It has a section on memory safety which mentions a "safe Carbon subset". But this is a longer-term goal, whereas it's the main goal of Circle.
- Cpp2: an alternate syntax for C++. It compiles to C++, but makes new features such as modules and concepts less verbose, while hiding or removing backwards-compatibility quirks (e.g. lists are
std::array
and string literals arestd::string
).- 100% memory safety is a non-goal: AFAIK it doesn't do static analysis and syntactic rewrites alone aren't powerful enough to enforce it.
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.
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.
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.
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.